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
On Thu, Jul 1, 2010 at 10:33 AM, Anders Sandvig
anders.sand...@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
On Wed, Jun 30, 2010 at 3:24 PM, Phyo Arkar phyo.arkarl...@gmail.com wrote:
So far , python-mysql still not working..
Anyone had sucessfully got it work?
Hey.
I'm not aware of anyone who had any success. You can come to #pypy on
irc.freenode.net and we can see how to solve the problem.
On
On 6/30/2010 2:53 PM, Barry Warsaw wrote:
It might be amazing, but it's still a significant overhead. As I've
described, multiply that by all the py files in all the distro packages
containing Python source code, and then still try to fit it on a CDROM.
I decided to prove to myself that it
On Thu, Jul 01, 2010 at 06:37:22AM +0200, Martin v. Löwis wrote:
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
On Thu, 01 Jul 2010 10:33:30 +0200, Anders Sandvig anders.sand...@gmail.com
wrote:
From the top of my head, I can come up with three (four) ways of
properly solving the issue:
1) Documenting the timeout behavior and describing the above hack in
the httplib documentation.
2) Modify
On Thu, Jul 1, 2010 at 14:09, Dan Buch daniel.b...@gmail.com wrote:
Does anybody know if there's already an issue tracking the failure
so that volunteers can better reproduce the issue? Is a full checkout
of /projects/python via hgsubversion all that's required, perhaps?
I work from a full
After reading PEP 384 and PEP 385 (finally) I got a strong impression
that they are not ready for the change (read below the line for
details), because they do not propose any workflow. So, instead of
rushing with migration I'd like to propose incremental change rather
than revolutionary that will
Dirkjan,
I assume having such a tarball available would be a good thing, but what
do I know!? :)
Are your steps for reproducing the referenced problem with
cvs2svn-generated revs available on an issue, wiki page or PEP?
--
~Dan
On Thu, Jul 01, 2010 at 02:19:06PM +0200, Dirkjan Ochtman wrote:
On Thu, Jul 1, 2010 at 15:23, Dan Buch daniel.b...@gmail.com wrote:
I assume having such a tarball available would be a good thing, but what
do I know!? :)
I'm putting one up. I'll email you the address privately in order to
preserve some bandwidth. Anyone else who wants a copy: just email me.
Excellent! Much thanks, Dirkjan.
--
~Dan
On Thu, Jul 01, 2010 at 04:14:16PM +0200, Dirkjan Ochtman wrote:
On Thu, Jul 1, 2010 at 15:23, Dan Buch daniel.b...@gmail.com wrote:
I assume having such a tarball available would be a good thing, but what
do I know!? :)
I'm putting one up. I'll
On Thu, Jul 1, 2010 at 7:52 AM, anatoly techtonik techto...@gmail.comwrote:
4. Even if I make patch in my Mercurial clone - you still can't pull
it and I have to attach it to tracker. No gain.
Was there ever any discussion about hosting the central repository on a site
such as bitbucket or
On Thu, 01 Jul 2010 15:51:06 +0200, Dirkjan Ochtman dirk...@ochtman.nl wrote:
On Thu, Jul 1, 2010 at 14:52, anatoly techtonik techto...@gmail.com wrote:
Primary concern is that will happen with central Subversion
repository. There are a plenty of private tools and automated scripts
that
On Thu, Jul 1, 2010 at 16:31, Daniel Stutzbach
dan...@stutzbachenterprises.com wrote:
The hg-git tool allows Mercurial and git to interoperate, so that's not as
much of an issue as it once was. It's geared toward using a Mercurial
client to talk to a git server, but I'm told it can work the
On Thu, Jul 1, 2010 at 16:31, Daniel Stutzbach
dan...@stutzbachenterprises.com wrote:
Was there ever any discussion about hosting the central repository on a site
such as bitbucket or github? I tried searching the python-dev archives but
was unable to find much.
Anyway... assuming there's a
On Thu, Jul 01, 2010 at 09:31:13AM -0500, Daniel Stutzbach wrote:
On Thu, Jul 1, 2010 at 7:52 AM, anatoly techtonik techto...@gmail.comwrote:
4. Even if I make patch in my Mercurial clone - you still can't pull
it and I have to attach it to tracker. No gain.
Was there ever any
On Thu, Jul 1, 2010 at 8:52 AM, anatoly techtonik techto...@gmail.com wrote:
After reading PEP 384 and PEP 385 (finally) I got a strong impression
that they are not ready for the change (read below the line for
details), because they do not propose any workflow. So, instead of
rushing with
On Thu, Jul 1, 2010 at 2:00 PM, Martin v. Löwis mar...@v.loewis.de wrote:
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
On Thu, Jul 1, 2010 at 07:31, R. David Murray rdmur...@bitdance.com wrote:
On Thu, 01 Jul 2010 15:51:06 +0200, Dirkjan Ochtman dirk...@ochtman.nl
wrote:
On Thu, Jul 1, 2010 at 14:52, anatoly techtonik techto...@gmail.com wrote:
Primary concern is that will happen with central Subversion
The workflow described by Brett looks like a patch-and-email one. It’s
used by the Mercurial team itself, and has the advantage of not
cluttering the history with lots of changes, since you only apply one
patch in the end. However, in the not-so-long run I feel that a simpler
and more mercurialic
On Jul 1, 2010, at 10:31 AM, Daniel Stutzbach wrote:
On Thu, Jul 1, 2010 at 7:52 AM, anatoly techtonik
techto...@gmail.com wrote:
4. Even if I make patch in my Mercurial clone - you still can't pull
it and I have to attach it to tracker. No gain.
Was there ever any discussion about hosting
On 1 July 2010 20:58, Brett Cannon br...@python.org wrote:
Here is a *really* quick-and-dirty approach for non-committers to
create a patch they can submit. This is not extensively tested so some
other Hg expert should back me up on this before telling anyone that
this is the simplest way. I
On Jul 01, 2010, at 10:57 PM, Paul Moore wrote:
On 1 July 2010 20:58, Brett Cannon br...@python.org wrote:
Here is a *really* quick-and-dirty approach for non-committers to
create a patch they can submit. This is not extensively tested so
some other Hg expert should back me up on this before
Am 01.07.2010 23:57, schrieb Paul Moore:
will Roundup extract an attachment from an email and add
it to the issue as a file? That would be particularly neat...
It actually does. Feel free to try it out on the life system
(i.e. not worrying about bogus issues - we have several test issues
On Thu, Jul 1, 2010 at 15:07, Barry Warsaw ba...@python.org wrote:
On Jul 01, 2010, at 10:57 PM, Paul Moore wrote:
On 1 July 2010 20:58, Brett Cannon br...@python.org wrote:
Here is a *really* quick-and-dirty approach for non-committers to
create a patch they can submit. This is not
On Thu, 1 Jul 2010 15:26:12 -0700
Brett Cannon br...@python.org wrote:
As I said, quick-and-dirty. It will take discussion to decide what we
want to ask non-committers to do,
I don't think we have to ask them to do anything special, as long as
they can submit their contributions under the
On 2 July 2010 08:07, Barry Warsaw ba...@python.org wrote:
Other than that, while I sometimes review patches in email, I do not think
patches in a tracker are the best way to manage these. A dvcs's biggest
strength is in branches, so we should use those as much as possible.
I changed my
On 2 July 2010 09:08, Tim Delaney timothy.c.dela...@gmail.com wrote:
On 2 July 2010 08:07, Barry Warsaw ba...@python.org wrote:
Other than that, while I sometimes review patches in email, I do not think
patches in a tracker are the best way to manage these. A dvcs's biggest
strength is in
On Jul 01, 2010, at 03:26 PM, Brett Cannon wrote:
On Thu, Jul 1, 2010 at 15:07, Barry Warsaw ba...@python.org wrote:
Other than that, while I sometimes review patches in email, I do not
think patches in a tracker are the best way to manage these. A
dvcs's biggest strength is in branches, so
anatoly techtonik writes:
After reading PEP 384 and PEP 385 (finally) I got a strong impression
that they are not ready for the change (read below the line for
details), because they do not propose any workflow.
This was deliberate. There are a lot of different workflows, and we
are not
Wouldn't it be cool if we could hook this up to Rietveld?
I can also highly recommend ReviewBoard_ since it already speaks
Mercurial. My company has been using it since Dec. 2009 as an
invaluable addition to in-person code reviews for both Subversion and
Mercurial repos.
FWIW, I've got an
This question was inspired by something asked on #python today. Consider
it a hypothetical, not a serious proposal.
We know that many semantic errors in Python lead to runtime errors, e.g.
1 + 1. If an implementation rejected them at compile time, would it
still be Python? E.g. if the keyhole
We know that many semantic errors in Python lead to runtime errors, e.g.
1 + 1. If an implementation rejected them at compile time, would it
still be Python? E.g. if the keyhole optimizer raised SyntaxError (or
some other exception) on seeing this:
def f():
return 1 + 1
instead
On Jul 2, 2010, at 12:28 AM, Steven D'Aprano wrote:
This question was inspired by something asked on #python today. Consider
it a hypothetical, not a serious proposal.
We know that many semantic errors in Python lead to runtime errors, e.g.
1 + 1. If an implementation rejected them at
34 matches
Mail list logo
