<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://purl.org/rss/1.0/" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:syn="http://purl.org/rss/1.0/modules/syndication/" xmlns:admin="http://webns.net/mvcb/">
  <channel rdf:about="http://blog.gmane.org/gmane.comp.python.devel">
    <title>gmane.comp.python.devel</title>
    <link>http://blog.gmane.org/gmane.comp.python.devel</link>
    <description/>
    <syn:updatePeriod>hourly</syn:updatePeriod>
    <syn:updateFrequency>1</syn:updateFrequency>
    <syn:updateBase>1901-01-01T00:00+00:00</syn:updateBase>
    <items>
      <rdf:Seq>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.python.devel/139634"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.python.devel/139627"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.python.devel/139620"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.python.devel/139616"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.python.devel/139561"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.python.devel/139548"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.python.devel/139524"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.python.devel/139517"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.python.devel/139500"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.python.devel/139479"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.python.devel/139461"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.python.devel/139457"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.python.devel/139449"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.python.devel/139419"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.python.devel/139413"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.python.devel/139389"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.python.devel/139385"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.python.devel/139348"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.python.devel/139335"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.python.devel/139326"/>
      </rdf:Seq>
    </items>
    <image rdf:resource="http://gmane.org/img/gmane-25t.png"/>
    <textinput rdf:resource=""/>
  </channel>
  <image rdf:about="http://gmane.org/img/gmane-25t.png">
    <title>Gmane</title>
    <url>http://gmane.org/img/gmane-25t.png</url>
    <link>http://gmane.org</link>
  </image>
  <item rdf:about="http://comments.gmane.org/gmane.comp.python.devel/139634">
    <title>_PyString_InsertThousandsGrouping()</title>
    <link>http://comments.gmane.org/gmane.comp.python.devel/139634</link>
    <description>&lt;pre&gt;Hi guys!

Can someone explain to me where in the CPython 2.7.5 source code is _PyString_InsertThousandsGrouping() implemented?

I've found the following declaration in 'Objects/stringobject.c' but it just defines _Py_InsertThousandsGrouping() as _PyString_InsertThousandsGrouping():

"#define _Py_InsertThousandsGrouping _PyString_InsertThousandsGrouping"

I'm looking for the opposite!

I don't even know how that doesn't cause an error! What's the trick?

Besides that I've found a lot of code inside some header files, such as 'Objects/stringlib/formatter.h'.

Why did you chose that way?

Thanks in advance.

Carlos       
&lt;/pre&gt;</description>
    <dc:creator>Carlos Nepomuceno</dc:creator>
    <dc:date>2013-05-23T03:53:11</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.python.devel/139627">
    <title>PEP 443 - Single-dispatch generic functions</title>
    <link>http://comments.gmane.org/gmane.comp.python.devel/139627</link>
    <description>&lt;pre&gt;Hello,
I would like to submit the following PEP for discussion and evaluation.


PEP: 443
Title: Single-dispatch generic functions
Version: $Revision$
Last-Modified: $Date$
Author: Łukasz Langa &amp;lt;lukasz&amp;lt; at &amp;gt;langa.pl&amp;gt;
Discussions-To: Python-Dev &amp;lt;python-dev&amp;lt; at &amp;gt;python.org&amp;gt;
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 22-May-2013
Post-History: 22-May-2013
Replaces: 245, 246, 3124


Abstract
========

This PEP proposes a new mechanism in the ``functools`` standard library
module that provides a simple form of generic programming known as
single-dispatch generic functions.

A **generic function** is composed of multiple functions sharing the
same name. Which form should be used during a call is determined by the
dispatch algorithm. When the implementation is chosen based on the type
of a single argument, this is known as **single dispatch**.


Rationale and Goals
===================

Python has always provided a variety of built-in and standard-library
generic functions, such as ``len()``, ``iter&lt;/pre&gt;</description>
    <dc:creator>Łukasz Langa</dc:creator>
    <dc:date>2013-05-22T22:33:35</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.python.devel/139620">
    <title>Is thread-safe smtpd desired/possible?</title>
    <link>http://comments.gmane.org/gmane.comp.python.devel/139620</link>
    <description>&lt;pre&gt;Hi,

I am posting this here since I could find no active maintainer of the smtpd module.

In my work as a test engineer for Axis (www.axis.com) I encountered the need of having thread-safe SMTP servers. I know the use case of several SMTP servers running in concurrent threads might seem odd, but it can actually be quite useful for testing purposes.

I have implemented (for my own use) a possible solution which basically means that every SMTP channel has its own socket map, instead of using asyncore's global socket map. It would not involve any change in asyncore.

Looking at the disucssion from http://bugs.python.org/issue11959 it seems to me that such a solution would not be accepted. Do you think that modifying asyncore is more feasible? If not, is this something that might be looked at?

I can provide code if needed, but I would first like to know your thoughts about this.

Best regards,
Sorin
&lt;/pre&gt;</description>
    <dc:creator>Sorin Stelian</dc:creator>
    <dc:date>2013-05-21T16:50:23</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.python.devel/139616">
    <title>PEP 442 delegate</title>
    <link>http://comments.gmane.org/gmane.comp.python.devel/139616</link>
    <description>&lt;pre&gt;
Hello,

I would like to nominate Benjamin as BDFL-Delegate for PEP 442.
Please tell me if you would like to object :)

Regards

Antoine.


&lt;/pre&gt;</description>
    <dc:creator>Antoine Pitrou</dc:creator>
    <dc:date>2013-05-21T15:57:39</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.python.devel/139561">
    <title>PEP 409 and the stdlib</title>
    <link>http://comments.gmane.org/gmane.comp.python.devel/139561</link>
    <description>&lt;pre&gt;As a quick reminder, PEP 409 allows this:

     try:
         ...
     except AnError:
         raise SomeOtherError from None

so that if the exception is not caught, we get the traditional single exception traceback, instead of the new:

     During handling of the above exception, another exception occurred


My question:

How do we go about putting this in the stdlib?  Is this one of the occasions where we don't do it unless we're modifying 
a module already for some other reason?

For that matter, should we?

Pros:  Makes tracebacks much less confusing, especially coming from a library

Cons:  Could hide bugs unrelated to what is being caught and transformed

--
~Ethan~
&lt;/pre&gt;</description>
    <dc:creator>Ethan Furman</dc:creator>
    <dc:date>2013-05-20T13:12:41</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.python.devel/139548">
    <title>What if we didn't have repr?</title>
    <link>http://comments.gmane.org/gmane.comp.python.devel/139548</link>
    <description>&lt;pre&gt;
I have pondered it many times, although usually in the form "Why do we
need both str and repr?"

Unfortunately I always come back to the same issue: I really want
print() of a string to write just the characters of the string
(without quotes), but I also really want the &amp;gt;&amp;gt;&amp;gt; prompt to write the
string with quotes (and escapes). Moreover, these are just two
examples of the different use cases -- repr() is more useful whenever
you are writing a value for a debugging purpose (e.g. when logging),
and str() is more useful when writing a value as "output" of a
program.

One could argume that the only type for which it makes sense to
distinguish between the two is str itself -- indeed I rarely define
different __repr__ and __str__ functions for new classes I create (but
I do note that PEP 435 does define them differently for enum members).
But for the str type, it's pretty important to have str(s) equal to s,
and it's also pretty important to have a way to produce a string
literal from a string value. And it would &lt;/pre&gt;</description>
    <dc:creator>Guido van Rossum</dc:creator>
    <dc:date>2013-05-20T01:46:40</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.python.devel/139524">
    <title>Why is documentation not inline?</title>
    <link>http://comments.gmane.org/gmane.comp.python.devel/139524</link>
    <description>&lt;pre&gt;This is more out of curiosity than to spark change (although I
wouldn't argue against it): Does anyone know why it was decided to
document external to source files rather than inline?

When rapidly digging through source, it would be much more helpful to
see parameter docs than to either have to find source lines (that can
easily be missed) to figure out the intention. Case in point, I've
been digging through cookiejar.py and request.py to figure out their
interactions. When reading through build_opener, it took me a few
minutes to figure out that each element of *handlers can be either an
instance /or/ a class definition (I was looking at how to define a
custom cookiejar for an HTTPCookieProcessor). Yes, I'm (now) aware
that there's some documentation at the top of request.py, but it would
have been helpful to have it right in the definition of build_opener.

It seems like external docs is standard throughout the stdlib. Is
there an actual reason for this?

Thanks,

--
Demian Brecht
http://demianbrecht.gith&lt;/pre&gt;</description>
    <dc:creator>Demian Brecht</dc:creator>
    <dc:date>2013-05-19T22:29:37</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.python.devel/139517">
    <title>Async subprocesses on Windows with tulip</title>
    <link>http://comments.gmane.org/gmane.comp.python.devel/139517</link>
    <description>&lt;pre&gt;Attached is a pretty trivial example of asynchronous interaction with a 
python subprocess using tulip on Windows.  It does not use transports or 
protocols -- instead sock_recv() and sock_sendall() are used inside tasks.

I am not sure what the plan is for dealing with subprocesses currently. 
  Shall I just add this to the examples folder for now?

&lt;/pre&gt;</description>
    <dc:creator>Richard Oudkerk</dc:creator>
    <dc:date>2013-05-19T15:59:52</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.python.devel/139500">
    <title>Ordering keyword dicts</title>
    <link>http://comments.gmane.org/gmane.comp.python.devel/139500</link>
    <description>&lt;pre&gt;On Sat, May 18, 2013 at 10:27 PM, Raymond Hettinger
&amp;lt;raymond.hettinger&amp;lt; at &amp;gt;gmail.com&amp;gt; wrote:

I'm slow at warming up to the idea. My main concern is speed -- since
most code doesn't need it and function calls are already slow (and
obviously very common :-) it would be a shame if this slowed down
function calls that don't need it noticeably.

An observation is that it's only necessary to preserve order if the
function definition uses **kwds. AFAIK we currently don't know if this
is the case when the call is made though, but perhaps the information
could be made available to the call site somehow.

There are also many special cases to consider; e.g. using **kwds in
the call where kwds is an unordered dict, or calls from C, or calls to
C.

But maybe someone considers this a challenge and comes up with a
patch? The benefits to *some* use cases would be obvious.

&lt;/pre&gt;</description>
    <dc:creator>Guido van Rossum</dc:creator>
    <dc:date>2013-05-19T05:47:35</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.python.devel/139479">
    <title>PEP 442: Safe object finalization</title>
    <link>http://comments.gmane.org/gmane.comp.python.devel/139479</link>
    <description>&lt;pre&gt;
Hello,

I would like to submit the following PEP for discussion and evaluation.

Regards

Antoine.



PEP: 442
Title: Safe object finalization
Version: $Revision$
Last-Modified: $Date$
Author: Antoine Pitrou &amp;lt;solipsis&amp;lt; at &amp;gt;pitrou.net&amp;gt;
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 2013-05-18
Python-Version: 3.4
Post-History:
Resolution: TBD


Abstract
========

This PEP proposes to deal with the current limitations of object
finalization.  The goal is to be able to define and run finalizers
for any object, regardless of their position in the object graph.

This PEP doesn't call for any change in Python code.  Objects
with existing finalizers will benefit automatically.


Definitions
===========

Reference
    A directional link from an object to another.  The target of the
    reference is kept alive by the reference, as long as the source is
    itself alive and the reference isn't cleared.

Weak reference
    A directional link from an object to another, which doesn't keep
    alive its &lt;/pre&gt;</description>
    <dc:creator>Antoine Pitrou</dc:creator>
    <dc:date>2013-05-18T08:59:10</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.python.devel/139461">
    <title>Summary of Python tracker Issues</title>
    <link>http://comments.gmane.org/gmane.comp.python.devel/139461</link>
    <description>&lt;pre&gt;
ACTIVITY SUMMARY (2013-05-10 - 2013-05-17)
Python tracker at http://bugs.python.org/

To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.

Issues counts and deltas:
  open    3966 ( +3)
  closed 25805 (+47)
  total  29771 (+50)

Open issues with patches: 1776 


Issues opened (32)
==================

#17487: wave.Wave_read.getparams should be more user friendly
http://bugs.python.org/issue17487  reopened by Claudiu.Popa

#17807: Generator cleanup without tp_del
http://bugs.python.org/issue17807  reopened by pitrou

#17905: Add check for locale.h
http://bugs.python.org/issue17905  reopened by pitrou

#17951: TypeError during gdb backtracing
http://bugs.python.org/issue17951  opened by Catalin.Patulea

#17953: sys.modules cannot be reassigned
http://bugs.python.org/issue17953  opened by Valentin.Lorentz

#17955: Minor updates to Functional HOWTO
http://bugs.python.org/issue17955  opened by akuchling

#17956: add ScheduledExecutor
http://bugs.python.org/iss&lt;/pre&gt;</description>
    <dc:creator>Python tracker</dc:creator>
    <dc:date>2013-05-17T16:07:32</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.python.devel/139457">
    <title>HAVE_FSTAT?</title>
    <link>http://comments.gmane.org/gmane.comp.python.devel/139457</link>
    <description>&lt;pre&gt;
Hello,

Some pieces of code are still guarded by:
#ifdef HAVE_FSTAT
  ...
#endif

I would expect all systems to have fstat() these days. It's pretty
basic POSIX, and even Windows has had it for ages. Shouldn't we simply
make those code blocks unconditional? It would avoid having to maintain
unused fallback paths.

Regards

Antoine.


&lt;/pre&gt;</description>
    <dc:creator>Antoine Pitrou</dc:creator>
    <dc:date>2013-05-17T13:01:19</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.python.devel/139449">
    <title>Why is nb_inplace_add copied to sq_inplace_concat?</title>
    <link>http://comments.gmane.org/gmane.comp.python.devel/139449</link>
    <description>&lt;pre&gt;
I have encountered what I believe to be a bug but I'm sure there is some 
reason things are done as they are and I am hoping someone can shed some light 
or confirm it is indeed a bug.

As a bit of background I have a c++ class that I use sip to generate python 
bindings.  The potential python bug manifests itself as:

NotImplemented

The bindings fill in nb_inplace_add which appears to be implemented properly, 
returning a new reference to Py_NotImplemented if the right hand argument is 
not as expected.

Where things appear to go wrong is that PyNumber_InPlaceAdd, after getting a 
NotImplemented return value from nb_inplace_add, then attempts to call 
sq_inplace_concat.  From reading the code it appears that sq_inplace_concat is 
not supposed to return NotImplemented, instead it should set an exception and 
return null if the right hand arg is not supported.  In my case 
sq_inplace_concat ends up being the same function as nb_inplace_add, which 
results in the buggy behavior.

When I figured this out I tr&lt;/pre&gt;</description>
    <dc:creator>Matt Newell</dc:creator>
    <dc:date>2013-05-16T23:17:20</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.python.devel/139419">
    <title>[RELEASED] Python 2.7.5</title>
    <link>http://comments.gmane.org/gmane.comp.python.devel/139419</link>
    <description>&lt;pre&gt;It is my greatest pleasure to announce the release of Python 2.7.5.

2.7.5 is the latest maintenance release in the Python 2.7 series. You may be
surprised to hear from me so soon, as Python 2.7.4 was released slightly more
than a month ago. As it turns out, 2.7.4 had several regressions and
incompatibilities with 2.7.3. Among them were regressions in the zipfile, gzip,
and logging modules. 2.7.5 fixes these. In addition, a data file for testing in
the 2.7.4 tarballs and binaries aroused the suspicion of some virus
checkers. The 2.7.5 release removes this file to resolve that issue.

For details, see the Misc/NEWS file in the distribution or view it at

    http://hg.python.org/cpython/file/ab05e7dd2788/Misc/NEWS

Downloads are at

    http://python.org/download/releases/2.7.5/

As always, please report bugs to

    http://bugs.python.org/

(Thank you to those who reported these bugs in 2.7.4.)

This is a production release.

Happy May,
Benjamin Peterson
2.7 Release Manager
(on behalf of all of Python 2.7's &lt;/pre&gt;</description>
    <dc:creator>Benjamin Peterson</dc:creator>
    <dc:date>2013-05-16T04:19:06</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.python.devel/139413">
    <title>Mysterious Python pyc file corruption problems</title>
    <link>http://comments.gmane.org/gmane.comp.python.devel/139413</link>
    <description>&lt;pre&gt;I am looking into a particularly vexing Python problem on Ubuntu that
manifests in several different ways.  I think the problem is the same one
described in http://bugs.python.org/issue13146 and I sent a message on the
subject to the ubuntu-devel list:
https://lists.ubuntu.com/archives/ubuntu-devel/2013-May/037129.html

I don't know what's causing the problem and have no way to reproduce it, but
all the clues point to corrupt pyc files in Pythons &amp;lt; 3.3.

The common way this manifests is a traceback on an import statement.  The
actual error can be a "ValueError: bad marshal data (unknown type code)" such
as in http://pad.lv/1010077 or an "EOFError: EOF read where not expected" as
in http://pad.lv/1060842.  We have many more instances of both of these.

Since both error messages come from marshal.c when trying to read the pyc for
a module being imported, I suspect that something is causing the pyc files to
get partially overwritten or corrupted.  The workaround is always to
essentially blow away the .pyc file &lt;/pre&gt;</description>
    <dc:creator>Barry Warsaw</dc:creator>
    <dc:date>2013-05-15T20:58:08</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.python.devel/139389">
    <title>First post</title>
    <link>http://comments.gmane.org/gmane.comp.python.devel/139389</link>
    <description>&lt;pre&gt;Hi guys! This is my first post on this list.

I'd like have your opinion on how to safely implement WSGI on a production server.

My benchmarks show no performance differences between our PHP and Python environments. I'm using mod_wsgi v3.4 with Apache 2.4.

Is that ok or can it get faster?

Thanks in advance.

Regards,

Carlos       
&lt;/pre&gt;</description>
    <dc:creator>Carlos Nepomuceno</dc:creator>
    <dc:date>2013-05-14T15:22:05</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.python.devel/139385">
    <title>How to debug python crashes</title>
    <link>http://comments.gmane.org/gmane.comp.python.devel/139385</link>
    <description>&lt;pre&gt;Hi,

I have a reproducable crash on Windows XP with Python 2.7 which I would
like to investigate. I have Visual Studio 2008 installed and I
downloaded the pdb files. However I could not find any instructions on
how to use them and was unsuccessful at getting anything out of it.

I checked the developer guide but could not find anything on debugging
crashes. On internet, this seems to be also an underdocumented topic.

So, a few questions :
- is there some documentation to help debugging crashes ?
- are the pdb files released along python usable with Visual Studio and
stock Python ? Or do you need a hand-compiled version ?

cheers,

Philippe

&lt;/pre&gt;</description>
    <dc:creator>Philippe Fremy</dc:creator>
    <dc:date>2013-05-14T12:32:27</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.python.devel/139348">
    <title>weak refs in descriptors(http://bugs.python.org/issue17950)</title>
    <link>http://comments.gmane.org/gmane.comp.python.devel/139348</link>
    <description>&lt;pre&gt;Hello python-dev.
I'm working on a patch to remove reference cycles from heap-allocated classes:  http://bugs.python.org/issue17950
Part of the patch involves making sure that descriptors in the class dictionary don't contain strong references to the class itself.
This is item 2) in the defect description.
I have implemented this via weak references and hit no issues at all when running the test suite.
But I'd like to ask the oracle if there is anything I may be overlooking with this approach?  Any hidden problems we might encounter?

K

&lt;/pre&gt;</description>
    <dc:creator>Kristján Valur Jónsson</dc:creator>
    <dc:date>2013-05-13T11:49:29</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.python.devel/139335">
    <title>Best practices for Enum</title>
    <link>http://comments.gmane.org/gmane.comp.python.devel/139335</link>
    <description>&lt;pre&gt;After the long design effort for the enum module,
I'm sure there will be a forthcoming effort to apply
them pervasively throughout the standard library.

I would like to ask for a little restraint and for there to 
be individual cost/benefit evaluations for each case.

On the plus-side, the new integer-enums have a better
repr than plain integers.

For internal constants such as those in idlelib and regex,
the user won't see any benefit at all.  But there will be
a cost in terms of code churn, risk of introducing errors
in stable code, modestly slowing-down the code, making
it more difficult to apply bug fixes across multiple versions
of Python, and increased code verbosity (i.e. changing
"if direction=LEFT: ..."  to "if direction is Direction.LEFT: ...")

For external constants, some thought needs to be given to:
* is the current API working just fine (i.e. decimal's ROUND_DOWN)
* will enums break doctests or any existing user code
* will it complicate users converting from Python 2
* do users now have to l&lt;/pre&gt;</description>
    <dc:creator>Raymond Hettinger</dc:creator>
    <dc:date>2013-05-12T23:49:44</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.python.devel/139326">
    <title>2.7.5 baking</title>
    <link>http://comments.gmane.org/gmane.comp.python.devel/139326</link>
    <description>&lt;pre&gt;The long anticipated "emergency" 2.7.5 release has now been tagged. It
will be publicly announced as binaries arrive.

Originally, I was just going to cherrypick regression fixes onto the
2.7.4 release and release those as 2.7.5. I started to this but ran
into some conflicts. Since we don't have buildbot testing of release
branches, I decided it would be best to just cut from the maintenance
branch.

--
Regards,
Benjamin
&lt;/pre&gt;</description>
    <dc:creator>Benjamin Peterson</dc:creator>
    <dc:date>2013-05-12T04:03:18</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.python.devel/139311">
    <title>make a Windows installation package (.msi) for Python3.3</title>
    <link>http://comments.gmane.org/gmane.comp.python.devel/139311</link>
    <description>&lt;pre&gt;To Python Windows Release Managers:

My name is Jianfeng Mao and I am a software developer at the U2 group in Rocket Software (http://u2.rocketsoftware.com/).   I am currently working on a project to embed a slightly customized Python interpreter in our product. For easy installation and setup,  we hope to be able to do the standard Python installation during the installation of our software.  Basically I want to create a .msi file that can be called to install the full Python if the user needs this new feature. Brian Curtin (brian&amp;lt; at &amp;gt;python.org&amp;lt;mailto:brian&amp;lt; at &amp;gt;python.org&amp;gt;)  pointed me to Tools/msi/msi.py for the Windows MSI builder. I tried to follow  the instructions in the README but couldn't make it to work after a few twists and turns.  Brian mentioned that few people needs to do this and only release managers handle the packaging of Python.  I have listed the steps I have done in my attempt to create the .msi file. Please let me know if I have missed anything  or done anything wrong.



1.       hg clone htt&lt;/pre&gt;</description>
    <dc:creator>Jianfeng Mao</dc:creator>
    <dc:date>2013-05-10T17:31:39</dc:date>
  </item>
  <textinput rdf:about="http://search.gmane.org/?group=$group=gmane.comp.python.devel">
    <title>Search Engine</title>
    <description>Search the mailing list at Gmane</description>
    <name>query</name>
    <link>http://search.gmane.org/?group=$group=gmane.comp.python.devel</link>
  </textinput>
</rdf:RDF>
