HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
nascheme
ppython
Python2016–2018
nascheme / ppython

ppython

Pragmatic Python

2Distinct people
7Mentions
0Explicit recommenders
0GitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

Pragmatic Python

GitHub

Where it is used

No documented product use has been verified yet.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 12:54:37 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by month7 dated mentions

Observed mentions: 2016-07-08 18:39:01 UTC to 2018-01-07 18:00:01 UTC.

01232016-07-01 00:00:00 UTC to 2016-08-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 commentsJul 20162016-08-01 00:00:00 UTC to 2016-09-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2016-09-01 00:00:00 UTC to 2016-10-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2016-10-01 00:00:00 UTC to 2016-11-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2016-11-01 00:00:00 UTC to 2016-12-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2016-12-01 00:00:00 UTC to 2017-01-01 00:00:00 UTC (exclusive): 1 mentions; 1 submissions, 0 comments2017-01-01 00:00:00 UTC to 2017-02-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2017-02-01 00:00:00 UTC to 2017-03-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2017-03-01 00:00:00 UTC to 2017-04-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2017-04-01 00:00:00 UTC to 2017-05-01 00:00:00 UTC (exclusive): 3 mentions; 0 submissions, 3 commentsApr 20172017-05-01 00:00:00 UTC to 2017-06-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2017-06-01 00:00:00 UTC to 2017-07-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2017-07-01 00:00:00 UTC to 2017-08-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2017-08-01 00:00:00 UTC to 2017-09-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2017-09-01 00:00:00 UTC to 2017-10-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2017-10-01 00:00:00 UTC to 2017-11-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2017-11-01 00:00:00 UTC to 2017-12-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2017-12-01 00:00:00 UTC to 2018-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2018-01-01 00:00:00 UTC to 2018-02-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 commentsJan 2018

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
Jul 20162016-07-01 00:00:00 UTC2016-08-01 00:00:00 UTC101
Aug 20162016-08-01 00:00:00 UTC2016-09-01 00:00:00 UTC000
Sep 20162016-09-01 00:00:00 UTC2016-10-01 00:00:00 UTC000
Oct 20162016-10-01 00:00:00 UTC2016-11-01 00:00:00 UTC000
Nov 20162016-11-01 00:00:00 UTC2016-12-01 00:00:00 UTC101
Dec 20162016-12-01 00:00:00 UTC2017-01-01 00:00:00 UTC110
Jan 20172017-01-01 00:00:00 UTC2017-02-01 00:00:00 UTC000
Feb 20172017-02-01 00:00:00 UTC2017-03-01 00:00:00 UTC000
Mar 20172017-03-01 00:00:00 UTC2017-04-01 00:00:00 UTC000
Apr 20172017-04-01 00:00:00 UTC2017-05-01 00:00:00 UTC303
May 20172017-05-01 00:00:00 UTC2017-06-01 00:00:00 UTC000
Jun 20172017-06-01 00:00:00 UTC2017-07-01 00:00:00 UTC000
Jul 20172017-07-01 00:00:00 UTC2017-08-01 00:00:00 UTC000
Aug 20172017-08-01 00:00:00 UTC2017-09-01 00:00:00 UTC000
Sep 20172017-09-01 00:00:00 UTC2017-10-01 00:00:00 UTC000
Oct 20172017-10-01 00:00:00 UTC2017-11-01 00:00:00 UTC000
Nov 20172017-11-01 00:00:00 UTC2017-12-01 00:00:00 UTC000
Dec 20172017-12-01 00:00:00 UTC2018-01-01 00:00:00 UTC000
Jan 20182018-01-01 00:00:00 UTC2018-02-01 00:00:00 UTC101

What Hacker News says

7 sources
For those still running 2.7 because migrating is too hard, consider using my "ppython" version (https://github.com/nascheme/ppython). It is a modified version of 3.6 with extra backwards compatibility features. After running your code through 2to3, it should mostly work with ppython. After fixing all the runtime warnings, your code should work with regular 3.6.
In Python 2.7 Countdown
The implicit coercion between bytes and unicode was one of the biggest hurtles I ran into when porting a relatively large (30k+ lines) code base from Python 2 to 3. Also challenging was the change in comparisons (None no longer smaller than all types, TypeError when trying to order disjoint types). While this looks like an interesting hack, I can't see anyone seriously using it to backport code to Python 2.7. As I mentioned elsewhere, I created "ppython" to handle these two porting problems. The source code is on github: https://github.com/nascheme/ppython . If someone needs a Windows binary, I could build it if you ask politely. ;-) For my project, it has been a useful tool to speed up porting. Porting code is not trivial and there is huge amount of Python 2 out there. I wish more effort had been spent building tools to help portin
Read the rest
g of code. Even simple things like disallowing the 'u' prefix on strings in Python 3 was a big mistake. Mostly those things have been corrected but it is still going to take a very long time to move the majority of the community to Python 3. There will be Python 2 running for the next 50 years easily, I'm sure, maybe 100 years. At least Python is open source and you will not be stranded like VB developers where when MS drastically changed Visual Basic.
In Show HN: Python-to-Python compiler for some 3.6 features in older versions
nas·Dec 10, 2016Submission

Show HN: Python 3 with backwards compatibility features

Porting Python code from version 2.x to 3.x is not a simple task. To help, I built a version of Python 3.6 that includes backwards compatibility features. Most important is the mixing of bytes and str objects and comparisons. For example, in vanilla Python 3: >>> b'foo' + 'bar' Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: can't concat bytes to str >>> None < 'hi' Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: unorderable types: NoneType() < str() In my Python 3: >>> b'foo' + 'bar' sys:1: DeprecationWarning: encoding bytes to str 'foobar' >>> None < 'hi' __main__:1: DeprecationWarning: default compare is depreciated True Certain changes are easy to fix with code converters like 2to3. For example, changing print statements into fun
Read the rest
ctions is trivial. I don't bother trying to handle those. There is still a lot of things that could be added. However, when porting a large code base to Python 3, I found it useful. I hope other people might use it and submit improvements. If someone need pre-built binaries (e.g. Windows), I would be willing to do it. https://github.com/nascheme/ppython
7 points · Open discussion
> what's happening to Python? Great things, IMHO. Now that the painful changes of 2 to 3 are done (or nearly so), recent releases have focused on incremental and steady progress. Take a look at the "What's New" documents: https://docs.python.org/3.6/whatsnew/3.6.html https://docs.python.org/3/whatsnew/3.5.html There is a lot of great stuff there without ripping up the world and breaking all your programs. For example, the new compact dict implementation in 3.6 is a great improvement. All Python programs can potentially benefit from the memory use reduction. Bug fixes and improvements to library code are great. The transition from 2.x to 3.x was not handled well. The core Python team should have focused much more on making transitioning code easier. Allowing code that can easily run in both 2.x and 3.x (with suitable shims like 'si
Read the rest
x') should have been a focus early on. Disallowing 'u' prefix on strings in 3.x is an example of a serious mistake. The argument of keeping 3.x pure was wrong. It is much more important to make transition easier rather than making 3.x extremely pure. That's something that C++ has got right, although maybe they went too far the other way. My small contribution to transitioning 2.x to 3.x is "ppython". See my github repo: https://github.com/nascheme/ppython Now that I've been programming in Python 3 for a few months, I find it pleasant. Writing programs that handle Unicode text correctly is easier. For small programs, it is easy to make them run under either Python 2 or 3.
In The Case Against Python 3
The unicode/bytes change it the most time consuming in my experience. Second comes the fact that you can't sort arbitrary types anymore and that None is no longer smaller than any other value. In order to ease porting, I've created a modified Python 3.6 interpreter that generates warnings in a lot of the cases that real Python 3 would generate an exception. See https://github.com/nascheme/ppython . The goal is to have a 2to3 script that generates something that will run, with warnings, under me modified Python. Once you fix all the warnings, your code should run correctly in Python 3.
In Release of IPython 5.0

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.