<?xml version="1.0" encoding="utf-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: The Quest for Python 3</title>
	<atom:link href="http://www.j5live.com/2010/02/03/the-quest-for-python-3/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.j5live.com/2010/02/03/the-quest-for-python-3/</link>
	<description>Where the urethane hits the pavement</description>
	<lastBuildDate>Fri, 27 Aug 2010 16:17:13 -0400</lastBuildDate>
	<generator>http://wordpress.org/?v=2.8.4</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Dave Malcolm</title>
		<link>http://www.j5live.com/2010/02/03/the-quest-for-python-3/comment-page-1/#comment-20613</link>
		<dc:creator>Dave Malcolm</dc:creator>
		<pubDate>Thu, 18 Feb 2010 20:52:34 +0000</pubDate>
		<guid isPermaLink="false">http://www.j5live.com/?p=730#comment-20613</guid>
		<description>&gt; good start though. One of the things that
&gt; would be nice is if it put comments on code
&gt; that needs to be looked at by the programmer.
John: interesting; what kind of thing could it detect - string handling uncertainty?  Can you file an RFE with some ideas on this in the tracker here:
https://fedorahosted.org/2to3c/
Thanks!</description>
		<content:encoded><![CDATA[<p>&gt; good start though. One of the things that<br />
&gt; would be nice is if it put comments on code<br />
&gt; that needs to be looked at by the programmer.<br />
John: interesting; what kind of thing could it detect &#8211; string handling uncertainty?  Can you file an RFE with some ideas on this in the tracker here:<br />
<a href="https://fedorahosted.org/2to3c/" rel="nofollow">https://fedorahosted.org/2to3c/</a><br />
Thanks!</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: J5</title>
		<link>http://www.j5live.com/2010/02/03/the-quest-for-python-3/comment-page-1/#comment-20607</link>
		<dc:creator>J5</dc:creator>
		<pubDate>Fri, 05 Feb 2010 17:23:57 +0000</pubDate>
		<guid isPermaLink="false">http://www.j5live.com/?p=730#comment-20607</guid>
		<description>@James,

Ya, David&#039;s 2to3c code just hits the most common conversions.  He leaves the string handling to the module programmer.  2to3c is a good start though.  One of the things that would be nice is if it put comments on code that needs to be looked at by the programmer.</description>
		<content:encoded><![CDATA[<p>@James,</p>
<p>Ya, David&#8217;s 2to3c code just hits the most common conversions.  He leaves the string handling to the module programmer.  2to3c is a good start though.  One of the things that would be nice is if it put comments on code that needs to be looked at by the programmer.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: James Henstridge</title>
		<link>http://www.j5live.com/2010/02/03/the-quest-for-python-3/comment-page-1/#comment-20605</link>
		<dc:creator>James Henstridge</dc:creator>
		<pubDate>Fri, 05 Feb 2010 03:57:05 +0000</pubDate>
		<guid isPermaLink="false">http://www.j5live.com/?p=730#comment-20605</guid>
		<description>The biggest issue I found when porting an extension over to Python 3 was string handling, and I&#039;m not sure automated tools would have helped.

The particular extension I was working on was a binding for GPG and had been using 8 bit strings for UTF-8 encoded data (e.g. the user names on keys), ASCII representations of binary data (e.g. key fingerprints) and actual binary data (e.g. the data being encrypted).

This is the sort of problem that the Python level 2to3 translator has problems with, and the solution was similar too: convert human readable data to the unicode API (or PyUnicode_* in this case), and anything that needs to be binary to the by tes API (or PyBytes_*, which is aliased to PyString_* for 2.x).</description>
		<content:encoded><![CDATA[<p>The biggest issue I found when porting an extension over to Python 3 was string handling, and I&#8217;m not sure automated tools would have helped.</p>
<p>The particular extension I was working on was a binding for GPG and had been using 8 bit strings for UTF-8 encoded data (e.g. the user names on keys), ASCII representations of binary data (e.g. key fingerprints) and actual binary data (e.g. the data being encrypted).</p>
<p>This is the sort of problem that the Python level 2to3 translator has problems with, and the solution was similar too: convert human readable data to the unicode API (or PyUnicode_* in this case), and anything that needs to be binary to the by tes API (or PyBytes_*, which is aliased to PyString_* for 2.x).</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: J5</title>
		<link>http://www.j5live.com/2010/02/03/the-quest-for-python-3/comment-page-1/#comment-20604</link>
		<dc:creator>J5</dc:creator>
		<pubDate>Thu, 04 Feb 2010 17:13:23 +0000</pubDate>
		<guid isPermaLink="false">http://www.j5live.com/?p=730#comment-20604</guid>
		<description>So I stand corrected - here is the progress for PyGtk 

https://bugzilla.gnome.org/show_bug.cgi?id=566641</description>
		<content:encoded><![CDATA[<p>So I stand corrected &#8211; here is the progress for PyGtk </p>
<p><a href="https://bugzilla.gnome.org/show_bug.cgi?id=566641" rel="nofollow">https://bugzilla.gnome.org/show_bug.cgi?id=566641</a></p>
]]></content:encoded>
	</item>
	<item>
		<title>By: ulrik</title>
		<link>http://www.j5live.com/2010/02/03/the-quest-for-python-3/comment-page-1/#comment-20603</link>
		<dc:creator>ulrik</dc:creator>
		<pubDate>Thu, 04 Feb 2010 08:20:59 +0000</pubDate>
		<guid isPermaLink="false">http://www.j5live.com/?p=730#comment-20603</guid>
		<description>Like the Python 3 porting guidelines says, it would be nice if the gtk bindings would be ported to Py 3 without API break. This is explicitly mentioned in the porting guidelines since it&#039;s unworkable if everyone decides to ship API changes together with the forward-port of python version -- it makes the task must harder for all applications using pygtk.</description>
		<content:encoded><![CDATA[<p>Like the Python 3 porting guidelines says, it would be nice if the gtk bindings would be ported to Py 3 without API break. This is explicitly mentioned in the porting guidelines since it&#8217;s unworkable if everyone decides to ship API changes together with the forward-port of python version &#8212; it makes the task must harder for all applications using pygtk.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: J5</title>
		<link>http://www.j5live.com/2010/02/03/the-quest-for-python-3/comment-page-1/#comment-20602</link>
		<dc:creator>J5</dc:creator>
		<pubDate>Thu, 04 Feb 2010 00:56:16 +0000</pubDate>
		<guid isPermaLink="false">http://www.j5live.com/?p=730#comment-20602</guid>
		<description>David Malcolm just moved over to the Fedora Team inside Red Hat and is working to get Fedora Python 3 ready by F13.  I&#039;m not sure it is going to happen that soon but there should be a parallel installable environment by then.  Once the distros start shipping Python 3 modules should move over more quickly.  The issue is it isn&#039;t an easy fix and since Python 2.x is such a great piece of software, there is no real rush to move.

I think with GTK+ we are more focused with GNOME 3 right now.  My best guess is GTK+ for Python 3 will follow the JavaScript bindings and be generated mostly from the introspection data.  I&#039;ll have to follow up with Johan Dalin to see what his thoughts are there.</description>
		<content:encoded><![CDATA[<p>David Malcolm just moved over to the Fedora Team inside Red Hat and is working to get Fedora Python 3 ready by F13.  I&#8217;m not sure it is going to happen that soon but there should be a parallel installable environment by then.  Once the distros start shipping Python 3 modules should move over more quickly.  The issue is it isn&#8217;t an easy fix and since Python 2.x is such a great piece of software, there is no real rush to move.</p>
<p>I think with GTK+ we are more focused with GNOME 3 right now.  My best guess is GTK+ for Python 3 will follow the JavaScript bindings and be generated mostly from the introspection data.  I&#8217;ll have to follow up with Johan Dalin to see what his thoughts are there.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Simon</title>
		<link>http://www.j5live.com/2010/02/03/the-quest-for-python-3/comment-page-1/#comment-20601</link>
		<dc:creator>Simon</dc:creator>
		<pubDate>Thu, 04 Feb 2010 00:42:37 +0000</pubDate>
		<guid isPermaLink="false">http://www.j5live.com/?p=730#comment-20601</guid>
		<description>Good to see - it&#039;s been frustrating how little adoption of Python3 there&#039;s been among open-source projects. It&#039;s been out over a year, yet there are still no Gtk+ bindings, nor even a hint that they&#039;re being worked on...</description>
		<content:encoded><![CDATA[<p>Good to see &#8211; it&#8217;s been frustrating how little adoption of Python3 there&#8217;s been among open-source projects. It&#8217;s been out over a year, yet there are still no Gtk+ bindings, nor even a hint that they&#8217;re being worked on&#8230;</p>
]]></content:encoded>
	</item>
</channel>
</rss>
