Steve Holden | 1 Jul 01:04 2010
Picon
Picon

Re: OS X buildbots: why am I skipping these tests?

Brett Cannon wrote:
> On Wed, Jun 30, 2010 at 15:01, "Martin v. Löwis" <martin <at> v.loewis.de>
> wrote:
>>>> When Tim Peters added it, he wanted it to tell him whether he
>>>> did the Windows build correctly, INCLUDING ALL OPTIONAL
>>>> PACKAGES that can possibly work on Windows. If you try to
>>>> generalize this beyond Windows, then the only skips that are
>>>> expected are the ones for tests that absolutely cannot work on
>>>> the platform - i.e. Unix tests on Windows, and Windows tests on
>>>> Unix. Otherwise, if you can get it to pass by installing
>>>> additional software, Tim did *not* mean this to be an expected
>>>> skip.
>>> Interesting. Do you use it that way when you make the Windows
>>> build?
>> You want a honest answer?
> 
> Of course. You're amongst friends. =)
> 
>> I usually don't run the test suite on Windows, and trust that the
>> packaging will tell me if an extension module failed to build (and
>> otherwise trust that if the setup worked for the release candidate,
>> it will also work for the final release).
> 
> Seems reasonable.
> 
>> Independent of that, I also decided to entirely ignore the notion
>> of expected skipped test (so even if I would run the test suite, I
>> wouldn't bother if one was reported as skipped).
> 
> Yeah, I remember you bringing this up years ago. I think that 
(Continue reading)

Dan Buch | 1 Jul 02:01 2010
Picon

Re: Taking over the Mercurial Migration

/me throws hat into ring.  I'm in the middle of migrating fairly
large chunks of an overgrown codebase from Subversion to Mercurial,
so I might actually have worthwhile input :)

-- 
~Dan

On Wed, Jun 30, 2010 at 10:41:51AM +0200, Georg Brandl wrote:
> Am 30.06.2010 07:37, schrieb "Martin v. Löwis":
> > It seems that both Dirkjan and Brett are very caught up
> > with real life for the coming months. So I suggest that
> > some other committer who favors the Mercurial transition
> > steps forward and takes over this project.
> > 
> > If nobody volunteers, I propose that we release 3.2
> > from Subversion, and reconsider Mercurial migration
> > next year.
> 
> IIUC, Dirkjan is only caught up for another month.  I have
> no problems with releasing a first 3.2 alpha from SVN and
> then switching, so I propose that we target the migration
> for August -- I can help in the second half of August if
> needed.
> 
> Georg
> 
> _______________________________________________
> Python-Dev mailing list
> Python-Dev <at> python.org
> http://mail.python.org/mailman/listinfo/python-dev
(Continue reading)

David Cournapeau | 1 Jul 04:11 2010
Picon

How are the bdist_wininst binaries built ?

Hi,

I would like to modify the code of the bdist installers, but I don't
see any VS project for VS 9.0. How are the wininst-9.0*exe built ?

thanks,

David
"Martin v. Löwis" | 1 Jul 06:22 2010
Picon

Re: How are the bdist_wininst binaries built ?

> I would like to modify the code of the bdist installers, but I don't
> see any VS project for VS 9.0. How are the wininst-9.0*exe built ?

See PC/bdist_wininst.

HTH,
Martin
"Martin v. Löwis" | 1 Jul 06:37 2010
Picon

Re: Taking over the Mercurial Migration

Am 01.07.2010 02:01, schrieb Dan Buch:
> /me throws hat into ring.  I'm in the middle of migrating fairly
> large chunks of an overgrown codebase from Subversion to Mercurial,
> so I might actually have worthwhile input :)

To all the volunteers: an issue that apparently requires immediate
attention is that r21112 fails to convert. For details, see

http://mail.python.org/pipermail/python-committers/2010-June/000977.html

So somebody please reproduce the problem, propose a patch, and get in
contact with Dirkjan to integrate it.

Regards,
Martin
David Cournapeau | 1 Jul 06:53 2010
Picon

Re: How are the bdist_wininst binaries built ?

On Thu, Jul 1, 2010 at 1:22 PM, "Martin v. Löwis" <martin <at> v.loewis.de> wrote:
>> I would like to modify the code of the bdist installers, but I don't
>> see any VS project for VS 9.0. How are the wininst-9.0*exe built ?
>
> See PC/bdist_wininst.

Hm, my question may not have been clear: *how* is the wininst-9.0
built from the bdist_wininst sources ? I see 6, 7.0, 7.1 and 8.0
versions of the visual studio build scripts, but nothing for VS 9.0.

cheers,

David
_______________________________________________
Python-Dev mailing list
Python-Dev <at> python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org
"Martin v. Löwis" | 1 Jul 07:00 2010
Picon

Re: How are the bdist_wininst binaries built ?

>> See PC/bdist_wininst.
> 
> Hm, my question may not have been clear: *how* is the wininst-9.0
> built from the bdist_wininst sources ? I see 6, 7.0, 7.1 and 8.0
> versions of the visual studio build scripts, but nothing for VS 9.0.

Ah. See PCbuild/bdist_wininst.vcproj.

Regards,
Martin
Éric Araujo | 1 Jul 07:41 2010

Re: OS X buildbots: why am I skipping these tests?

[Barry Warsaw]
> As an aside, I wonder if it would make sense to create an Ubuntu/Debian
> package that essentially just depended on all those -dev packages.  That way
> you could install this python-uber-dev package and get everything you needed
> to build a sumo Python.

I don’t know. Any Debian advanced user wanting to build a package can
just run “aptitude build-dep python2.6”. Aptitude has the nice property
of asking for a confirmation, so it’s even possible to cherry-pick from
the lists of deps (press “e” at the confirmation prompt). E.g., I choose
readline but not tk. So it seems to me that the information and the
command are already here.

_______________________________________________
Python-Dev mailing list
Python-Dev <at> python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org
Anders Sandvig | 1 Jul 10:33 2010
Picon

Regarding socket timeouts in httplib

Consider the following code for retreieving a web page using httplib:

   def get_url(hostname, port, url, timeout=5):
       con = httplib.HTTPConnection(hostname, port, timeout)
       con.request("GET", url)
       res = con.getresponse()
       data = res.read()
       return res, data

As expected, this will raise a socket.error if the client is unable to
connect before the timeout has expired. However, once the connection
has been made, the timeout parameter no longer has any effect and
con.getresponse() will block forever if the server does not send any
data.

I think the reason for this is that the socket object created in
HTTPConnection.connect() has a default timeout of 0 (i.e. it is never
set explicitly):

   def connect(self):
       """Connect to the host and port specified in __init__."""
       self.sock = socket.create_connection((self.host,self.port),
                                            self.timeout)

For now I have been able to work around this by manually setting the
timeout of the (private) socket object after calling con.request(),
like this:

       ...
       con.request("GET", url)
(Continue reading)

Simon Cross | 1 Jul 10:51 2010
Picon

Re: Regarding socket timeouts in httplib

On Thu, Jul 1, 2010 at 10:33 AM, Anders Sandvig
<anders.sandvig <at> gmail.com> wrote:
> 2) Modify HTTPConnection.connect() to set the timeout on the socket
> object after it has been  created (using the same timeout as given on
> the HTTPConnection constructor).

It looks like urllib2 in trunk and urllib.request in py3k are also
affected by this oddity. My vote is for option 2 -- i.e. consider it a
bug that the timeout wasn't consistently applied.

Schiavo
Simon
_______________________________________________
Python-Dev mailing list
Python-Dev <at> python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org

Gmane