[Python-Dev] Regarding socket timeouts in httplib

2010-07-01 Thread Anders Sandvig 
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)
       con.sock.settimeout(timeout)
       res = con.getresponse()
       ...

However, I don't think this is a very good solution as it relies on
knowledge about the inner workings of httplib (and I had to read the
library source code to come up with it).

>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 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).

3) Adding (optional) timeout parameters to
HTTPConnection.getresponse() and HTTPResponse.read() (and possibly
other functions with the same problem).

4) A combination of 2) and 3).

Any thoughts on this?

BTW: Once I figure out how, I wouldn't mind submitting a patch for
either 2), 3) or 4), but personally I don't like 1).


Anders
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Regarding socket timeouts in httplib

2010-07-01 Thread Simon Cross 
On Thu, Jul 1, 2010 at 10:33 AM, Anders Sandvig
 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
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [pypy-dev] PyPy 1.3 released

2010-07-01 Thread Maciej Fijalkowski 
On Wed, Jun 30, 2010 at 3:24 PM, Phyo Arkar  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 Fri, Jun 25, 2010 at 11:27 PM, Maciej Fijalkowski 
> wrote:
>>
>> ===
>> PyPy 1.3: Stabilization
>> ===
>>
>> Hello.
>>
>> We're please to announce release of PyPy 1.3. This release has two major
>> improvements. First of all, we stabilized the JIT compiler since 1.2
>> release,
>> answered user issues, fixed bugs, and generally improved speed.
>>
>> We're also pleased to announce alpha support for loading CPython extension
>> modules written in C. While the main purpose of this release is increased
>> stability, this feature is in alpha stage and it is not yet suited for
>> production environments.
>>
>> Highlights of this release
>> ==
>>
>> * We introduced support for CPython extension modules written in C. As of
>> now,
>>  this support is in alpha, and it's very unlikely unaltered C extensions
>> will
>>  work out of the box, due to missing functions or refcounting details. The
>>  support is disable by default, so you have to do::
>>
>>   import cpyext
>>
>>  before trying to import any .so file. Also, libraries are
>> source-compatible
>>  and not binary-compatible. That means you need to recompile binaries,
>> using
>>  for example::
>>
>>   python setup.py build
>>
>>  Details may vary, depending on your build system. Make sure you include
>>  the above line at the beginning of setup.py or put it in your
>> PYTHONSTARTUP.
>>
>>  This is alpha feature. It'll likely segfault. You have been warned!
>>
>> * JIT bugfixes. A lot of bugs reported for the JIT have been fixed, and
>> its
>>  stability greatly improved since 1.2 release.
>>
>> * Various small improvements have been added to the JIT code, as well as a
>> great
>>  speedup of compiling time.
>>
>> Cheers,
>> Maciej Fijalkowski, Armin Rigo, Alex Gaynor, Amaury Forgeot d'Arc and
>> the PyPy team
>> ___
>> [email protected]
>> http://codespeak.net/mailman/listinfo/pypy-dev
>
>
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] versioned .so files for Python 3.2

2010-07-01 Thread Scott Dial 
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 was not a significant issue to have
parallel directory structures in a .tar.bz2, and I was surprised to find
it much worse at that then I had imagined. For example,

# cd /usr/lib/python2.6/site-packages
# tar --exclude="*.pyc" --exclude="*.pyo" \
  -cjf mercurial.tar.bz2 mercurial
# du -h mercurial.tar.bz2
640Kmercurial.tar.bz2

# cp -a mercurial mercurial2
# tar --exclude="*.pyc" --exclude="*.pyo" \
  -cjf mercurial2.tar.bz2 mercurial mercurial2
# du -h mercurial.tar.bz2
1.3Mmercurial2.tar.bz2

So, I was definitely wrong in saying that you do better than doubling.

>> What happens to the distro packaging if a python package splits the
>> codebase between 2.x and 3.x (meaning they have distinct .py files)?
> 
> The Debian/Ubuntu approach to Python 2/3 support is to provide them in
> separate distro packages.  E.g. for Python package foo, you would have Debuntu
> package python-foo (for the Python 2.x version) and python3-foo.  We do not
> share source between Python 2 and 3 versions, at least not yet .

I had asked this question to point out that you will still need to
accommodate some form of version-specific packages (I am not a debuntu
expert by any means). And, I think your response is an acknowledgment of
that fact, however it's certainly true that there are few examples, as
you said.

I appreciate all your replies. I am not sure a PEP is really needed
here, but to having had all of this discussed and explained on the
mailing list is certainly useful. I trust that yourself and the debuntu
python group will end up chasing down and taking care of any quirks that
this change might cause, so I am not worried about it. :D

-- 
Scott Dial
[email protected]
[email protected]
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Taking over the Mercurial Migration

2010-07-01 Thread Dan Buch 
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 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.

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?

-- 
~Dan

> 
> Regards,
> Martin
> ___
> Python-Dev mailing list
> [email protected]
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> http://mail.python.org/mailman/options/python-dev/daniel.buch%40gmail.com


pgp6rBL7CvtWt.pgp
Description: PGP signature
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Regarding socket timeouts in httplib

2010-07-01 Thread R. David Murray 
On Thu, 01 Jul 2010 10:33:30 +0200, Anders Sandvig  
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 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).
> 
> 3) Adding (optional) timeout parameters to
> HTTPConnection.getresponse() and HTTPResponse.read() (and possibly
> other functions with the same problem).
> 
> 4) A combination of 2) and 3).
> 
> Any thoughts on this?
> 
> BTW: Once I figure out how, I wouldn't mind submitting a patch for
> either 2), 3) or 4), but personally I don't like 1).

FYI there's an open bug about this (or at least related to it):

http://bugs.python.org/issue8595

--
R. David Murray  www.bitdance.com
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Taking over the Mercurial Migration

2010-07-01 Thread Dirkjan Ochtman 
On Thu, Jul 1, 2010 at 14:09, Dan Buch  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 svnsync of the projects repo (including python). I
can probably put up a tarball somewhere.

Cheers,

Dirkjan
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Mercurial migration readiness (was: Taking over the Mercurial Migration)

2010-07-01 Thread anatoly techtonik 
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 allow people to taste what it like to
work with Mercurial and update all relevant papers on the website.

I propose to setup workflow that will include pulling changes to
Mercurial master clone from current Subversion repository and pushing
them back to Subversion using Mercurial. This will be similar to
http://mercurial.selenic.com/wiki/DeveloperRepos scheme, but with
hg-stable replaced with svn.

I am willing to collaborate for getting this system in place before
EuroPython even if I won't find a chance to get there.


--- the line ---

I didn' t have time to follow Mercurial discussion, so I expected PEP
384 and PEP 385 to be exhaustive reference on both the migration and
workflow before and after the switch. Unfortunately, both are too
vague in this respect and my opinion that migration now will do more
harm than good.


Primary concern is that will happen with central Subversion
repository. There are a plenty of private tools and automated scripts
that were written to work with central Subversion repository, so it is
important that central Subversion repository continue to operate and
be synchronized.

However, PEP 385 "The Future of Subversion" [1] does not propose any
way to keep Subversion repository in sync. "it will probably live on
for a bit" phrase looks like Subversion will be immediately dead after
switching.


The second concern is workflow. Even after getting my hands dirty I
still can't find the best solution for working with Mercurial copy of
Python. In Subversion I do shallow checkouts of interesting features
when I run into one bug or another. Not all patches are ready, so they
stay in those checkouts as uncommitted diffs. To be prepared for
conflicts I review code with `svn log -vr base:head` before updating.
But with Mercurial I see two major problems with my workflow (which I
am unlikely to change for the next few weeks due to heavy automation):
1. No shallow checkouts - that means that I have to copy 200Mb+ for
every patch I have
2. No `hg log` command to see changes in my branch from remote
repository before fetching them
(I used to invoke `hg incoming`, but ended up with fetching everything
with `hg pull` and then using `hg log -vr .:tip`, because `hg inc`
didn't show changes that were already pulled, but not updated in wc,
and `hg log` could not show incoming)
3. There is no clear branch separation in my working copy. I don't
know how to diff files in different branches without copying 200Mb+
clone. I don't know how to diff my files with remote repository
without pulling it.
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.

So from these PEPs I can't really see how Mercurial solves problems
with development. I can feel that it doesn't solve my problems, but I
see no way where I can submit my user story.


I would put accent on keeping mirror of Subversion as easy way to
contribute for those who are not yet ready for DVCS. Subversion also
provides greater interoperability. Assuming that any modern DVCS tool
may act as Subversion client, we will gain more contributors if we
won't try to force people use Python and Mercurial.

[1] http://www.python.org/dev/peps/pep-0385/#the-future-of-subversion
-- 
anatoly t.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Taking over the Mercurial Migration

2010-07-01 Thread Dan Buch 
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 14:09, Dan Buch  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 svnsync of the projects repo (including python). I
> can probably put up a tarball somewhere.
> 
> Cheers,
> 
> Dirkjan
> ___
> Python-Dev mailing list
> [email protected]
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> http://mail.python.org/mailman/options/python-dev/daniel.buch%40gmail.com


pgpAat6gvdPXk.pgp
Description: PGP signature
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Mercurial migration readiness (was: Taking over the Mercurial Migration)

2010-07-01 Thread Dirkjan Ochtman 
On Thu, Jul 1, 2010 at 14:52, anatoly techtonik  wrote:
> Primary concern is that will happen with central Subversion
> repository. There are a plenty of private tools and automated scripts
> that were written to work with central Subversion repository, so it is
> important that central Subversion repository continue to operate and
> be synchronized.
>
> However, PEP 385 "The Future of Subversion" [1] does not propose any
> way to keep Subversion repository in sync. "it will probably live on
> for a bit" phrase looks like Subversion will be immediately dead after
> switching.

It would certainly be possible to have snapshots of the hg repo be
committed into SVN, but I think people will actually notice sooner
that it's dead if we don't update it at all anymore.

> The second concern is workflow. Even after getting my hands dirty I
> still can't find the best solution for working with Mercurial copy of
> Python.

Mercurial is relatively flexible in that there are lots of ways you
can do this, and so I find that, certainly for the local parts of the
workflow (e.g. those that don't directly affect the repo that everyone
sees), I don't want to mandate a certain workflow. On the other hand,
there will certainly be documentation on a very basic workflow to get
people started. Inevitably, in order to get the most out of the tool,
people will have to investigate some different ways of doing things
(e.g., mq, which is one of my favorite workflows -- I'd probably
include a basic description of it in the docs for python-dev).

Cheers,

Dirkjan
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Taking over the Mercurial Migration

2010-07-01 Thread Dirkjan Ochtman 
On Thu, Jul 1, 2010 at 15:23, Dan Buch  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.

> Are your steps for reproducing the referenced problem with
> cvs2svn-generated revs available on an issue, wiki page or PEP?

Install hgsubversion (tip) and get the pymigr repo, then just run this:

$ hg clone -A pymigr/author-map --branchmap pymigr/branchmap
file:///path/to/svn-repo/python

Cheers,

Dirkjan
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Taking over the Mercurial Migration

2010-07-01 Thread Dan Buch 
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  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.
> 
> > Are your steps for reproducing the referenced problem with
> > cvs2svn-generated revs available on an issue, wiki page or PEP?
> 
> Install hgsubversion (tip) and get the pymigr repo, then just run this:
> 
> $ hg clone -A pymigr/author-map --branchmap pymigr/branchmap
> file:///path/to/svn-repo/python
> 
> Cheers,
> 
> Dirkjan


pgp8nbt25CE7o.pgp
Description: PGP signature
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Mercurial migration readiness (was: Taking over the Mercurial Migration)

2010-07-01 Thread Daniel Stutzbach 
On Thu, Jul 1, 2010 at 7:52 AM, anatoly techtonik 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 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 at least a clone of the central repository on
one of those sites, you can fork it and work on your patch there.  A core
developer can then pull your patch to their local repository, tweak it as
needed, then commit it to the central repository.


> I would put accent on keeping mirror of Subversion as easy way to
> contribute for those who are not yet ready for DVCS. Subversion also
> provides greater interoperability. Assuming that any modern DVCS tool
> may act as Subversion client, we will gain more contributors if we
> won't try to force people use Python and Mercurial.
>

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 other way
around with a bit of work.
--
Daniel Stutzbach, Ph.D.
President, Stutzbach Enterprises, LLC 
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Mercurial migration readiness (was: Taking over the Mercurial Migration)

2010-07-01 Thread R. David Murray 
On Thu, 01 Jul 2010 15:51:06 +0200, Dirkjan Ochtman  wrote:
> On Thu, Jul 1, 2010 at 14:52, anatoly techtonik  wrote:
> > Primary concern is that will happen with central Subversion
> > repository. There are a plenty of private tools and automated scripts
> > that were written to work with central Subversion repository, so it is
> > important that central Subversion repository continue to operate and
> > be synchronized.
> >
> > However, PEP 385 "The Future of Subversion" [1] does not propose any
> > way to keep Subversion repository in sync. "it will probably live on
> > for a bit" phrase looks like Subversion will be immediately dead after
> > switching.
> 
> It would certainly be possible to have snapshots of the hg repo be
> committed into SVN, but I think people will actually notice sooner
> that it's dead if we don't update it at all anymore.

I remember the decision as being that SVN would be read-only after the
switch.  Which will cause some pain, yes, but probably not as much
pain as trying to keep both workflows available would.

> > The second concern is workflow. Even after getting my hands dirty I
> > still can't find the best solution for working with Mercurial copy of
> > Python.
> 
> Mercurial is relatively flexible in that there are lots of ways you
> can do this, and so I find that, certainly for the local parts of the
> workflow (e.g. those that don't directly affect the repo that everyone
> sees), I don't want to mandate a certain workflow. On the other hand,

And this is the reason that Martin says that a *working* (final
configuration) repo must be available for some time before the transition
takes place, so that we can all experiment and figure out what external
workflow is needed, and document what people find to be useful internal
workflows.

I think someone needs to say, "OK, what's up is how it is going to be,
you've got X weeks to make sure you can work with it and then we cut
over" before the balance of the dev community is going to actually try
working with it.  But one or more volunteers could make the first cut
at the workflow docs right now, I would think, and that would be a big
help for this process

I know I would have preferred to have such docs before I gave it a
try...but I need to be able to talk intelligently about HG at PyOhio,
so I need to start learning it this week.

--
R. David Murray  www.bitdance.com
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Mercurial migration readiness (was: Taking over the Mercurial Migration)

2010-07-01 Thread Dirkjan Ochtman 
On Thu, Jul 1, 2010 at 16:31, Daniel Stutzbach
 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 other way
> around with a bit of work.

There's also heechee, which could be interesting for those who really love SVN.

http://bitbucket.org/andrewgodwin/heechee

Cheers,

Dirkjan
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Mercurial migration readiness (was: Taking over the Mercurial Migration)

2010-07-01 Thread Dirkjan Ochtman 
On Thu, Jul 1, 2010 at 16:31, Daniel Stutzbach
 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 at least a clone of the central repository on
> one of those sites, you can fork it and work on your patch there.  A core
> developer can then pull your patch to their local repository, tweak it as
> needed, then commit it to the central repository.

I'm pretty sure bitbucket will do a mirror once hg is up and running.

Cheers,

Dirkjan
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Mercurial migration readiness (was: Taking over the Mercurial Migration)

2010-07-01 Thread C. Titus Brown 
On Thu, Jul 01, 2010 at 09:31:13AM -0500, Daniel Stutzbach wrote:
> On Thu, Jul 1, 2010 at 7:52 AM, anatoly techtonik 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 the central repository on a site
> such as bitbucket or github?  I tried searching the python-dev archives but
> was unable to find much.

We discussed this briefly at the Python language summit at PyCon '10, the
discussion intersected and/or merged with the whole infrastructure discussion,
got borg-ified by that, and I think discussions continue(d) on pydotorg-www in
general.

Personally I think it makes a great deal of sense to pay someone to manage
this for us, but there were concerns about customizability and control that
warrant further investigation.  Since it's DVCS, it's much easier to change
the "official" repo, but it still incurs costs in terms of documentation,
workflow changes, etc.

cheers,
--titus
-- 
C. Titus Brown, [email protected]
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Mercurial migration readiness (was: Taking over the Mercurial Migration)

2010-07-01 Thread Jesse Noller 
On Thu, Jul 1, 2010 at 8:52 AM, anatoly techtonik  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 migration I'd like to propose incremental change rather
> than revolutionary that will allow people to taste what it like to
> work with Mercurial and update all relevant papers on the website.
>

This migration is far from "rushed". Workflow will need to be
documented and we need a working hg setup a little while before the
official migration. Both of those said, I personally think this has
dragged on long enough.

jesse
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] How are the bdist_wininst binaries built ?

2010-07-01 Thread David Cournapeau 
On Thu, Jul 1, 2010 at 2:00 PM, "Martin v. Löwis"  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 9.0.
>
> Ah. See PCbuild/bdist_wininst.vcproj.

I thought I checked there, but I obviously missed it. thanks,

David
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Mercurial migration readiness (was: Taking over the Mercurial Migration)

2010-07-01 Thread Brett Cannon 
On Thu, Jul 1, 2010 at 07:31, R. David Murray  wrote:
> On Thu, 01 Jul 2010 15:51:06 +0200, Dirkjan Ochtman  
> wrote:
>> On Thu, Jul 1, 2010 at 14:52, anatoly techtonik  wrote:
>> > Primary concern is that will happen with central Subversion
>> > repository. There are a plenty of private tools and automated scripts
>> > that were written to work with central Subversion repository, so it is
>> > important that central Subversion repository continue to operate and
>> > be synchronized.
>> >
>> > However, PEP 385 "The Future of Subversion" [1] does not propose any
>> > way to keep Subversion repository in sync. "it will probably live on
>> > for a bit" phrase looks like Subversion will be immediately dead after
>> > switching.
>>
>> It would certainly be possible to have snapshots of the hg repo be
>> committed into SVN, but I think people will actually notice sooner
>> that it's dead if we don't update it at all anymore.
>
> I remember the decision as being that SVN would be read-only after the
> switch.  Which will cause some pain, yes, but probably not as much
> pain as trying to keep both workflows available would.
>
>> > The second concern is workflow. Even after getting my hands dirty I
>> > still can't find the best solution for working with Mercurial copy of
>> > Python.
>>
>> Mercurial is relatively flexible in that there are lots of ways you
>> can do this, and so I find that, certainly for the local parts of the
>> workflow (e.g. those that don't directly affect the repo that everyone
>> sees), I don't want to mandate a certain workflow. On the other hand,
>
> And this is the reason that Martin says that a *working* (final
> configuration) repo must be available for some time before the transition
> takes place, so that we can all experiment and figure out what external
> workflow is needed, and document what people find to be useful internal
> workflows.
>
> I think someone needs to say, "OK, what's up is how it is going to be,
> you've got X weeks to make sure you can work with it and then we cut
> over" before the balance of the dev community is going to actually try
> working with it.  But one or more volunteers could make the first cut
> at the workflow docs right now, I would think, and that would be a big
> help for this process
>
> I know I would have preferred to have such docs before I gave it a
> try...but I need to be able to talk intelligently about HG at PyOhio,
> so I need to start learning it this week.

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 am also not saying this is how we will
want people to contribute in the long run, but this does work and
matches how svn does things well enough that people shouldn't get
thrown by the details.

1. Contributor clones the repo
2. Contributor makes changes, committing as they go
3. Contributor runs ``hg outgoing --patch --git > patch.diff``
4. Committer runs ``hg patch --no-commit patch.diff``
5. Committer does the usual review->commit thing

Basically this creates git-style diffs that one can shuttle around. I
think you can also use ``patch -p1`` or git-apply to apply the patch
generated by Mercurial.

The other option is using mq (Mercurial Queues), but I personally have
not gotten around to learning how to use them so I can't tell you any
details. But if the Hg transition is taking too long for you, mq can
be used on top of svn w/o issue:
http://mercurial.selenic.com/wiki/WorkingWithSubversion#With_MQ_only .

This obviously does not cover how committers should backport. That
will very between whether it is within 3.x or 3.x to 2.x (or
vice-versa). That will require a bit more thought and discussion.

And finally, http://hginit.com/ is one of the best Hg intros I have
come across for explaining fundamentals.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Mercurial migration readiness (was: Taking over the Mercurial Migration)

2010-07-01 Thread Éric Araujo 
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 workflow would be a changesets-and-repos one.

1. Contributor clones the repo.
2. Contributor makes changes, committing as needed.
3. Contributor pushes to some public location and asks for pulling.
4. Core dev reviews and pulls from that repo into the official one.
(optional step) Core dev may make additional edits (e.g. to NEWS and
ACKS) in another changeset.

One advantage of DVCS is that it separates the step of getting ideas
from brain to code (commit) from the step of approving code and putting
it into the official repo (pull). Having both the contributor and the
core dev doing commits seems counter-natural to me.

Advanced users may use MQ or pbranches or bookmarks to refine patches,
but basic usage (commit and pull) still seems worthwhile to me.

> And finally, http://hginit.com/ is one of the best Hg intros I have
> come across for explaining fundamentals.
Agreed, although I’m not sure whether I’d call it a long introduction or
a short tuto :) The “reeducation for Subversion users” page is helpful.
hgtip.com has bite-sized tips for daily use, and
http://hgbook.red-bean.com/ is an excellent read.

Regards

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Mercurial migration readiness (was: Taking over the Mercurial Migration)

2010-07-01 Thread Doug Hellmann 


On Jul 1, 2010, at 10:31 AM, Daniel Stutzbach wrote:

On Thu, Jul 1, 2010 at 7:52 AM, anatoly techtonik  
 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 the central repository  
on a site such as bitbucket or github?  I tried searching the python- 
dev archives but was unable to find much.


I just set up a PSF account on BitBucket for hosting the Pulse  
newsletter repository. I can assist with setting up a public  
repository for the source under that account, too.


Doug

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Mercurial migration readiness (was: Taking over the Mercurial Migration)

2010-07-01 Thread Paul Moore 
On 1 July 2010 20:58, Brett Cannon  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 am also not saying this is how we will
> want people to contribute in the long run, but this does work and
> matches how svn does things well enough that people shouldn't get
> thrown by the details.
>
> 1. Contributor clones the repo
> 2. Contributor makes changes, committing as they go
> 3. Contributor runs ``hg outgoing --patch --git > patch.diff``
> 4. Committer runs ``hg patch --no-commit patch.diff``
> 5. Committer does the usual review->commit thing
>
> Basically this creates git-style diffs that one can shuttle around. I
> think you can also use ``patch -p1`` or git-apply to apply the patch
> generated by Mercurial.

I'd suggest the patchbomb extension (distributed with Mercurial)

hg email --outgoing --to d...@somewhere sends a series of patches to
the given email address. This is what the Mercurial developers use
(with the to address being the mercurial-dev list). Or maybe better,
hg email --outgoing --bundle which sends a binary bundle of all
outgoing changesets. You can use --to to send the email to something
like roundup (will Roundup extract an attachment from an email and add
it to the issue as a file? That would be particularly neat...)

Paul.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Mercurial migration readiness (was: Taking over the Mercurial Migration)

2010-07-01 Thread Barry Warsaw 
On Jul 01, 2010, at 10:57 PM, Paul Moore wrote:

>On 1 July 2010 20:58, Brett Cannon  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 am also not saying this is how we
>> will want people to contribute in the long run, but this does work
>> and matches how svn does things well enough that people shouldn't get
>> thrown by the details.
>>
>> 1. Contributor clones the repo
>> 2. Contributor makes changes, committing as they go
>> 3. Contributor runs ``hg outgoing --patch --git > patch.diff``
>> 4. Committer runs ``hg patch --no-commit patch.diff``
>> 5. Committer does the usual review->commit thing
>>
>> Basically this creates git-style diffs that one can shuttle around. I
>> think you can also use ``patch -p1`` or git-apply to apply the patch
>> generated by Mercurial.
>
>I'd suggest the patchbomb extension (distributed with Mercurial)
>
>hg email --outgoing --to d...@somewhere sends a series of patches to
>the given email address. This is what the Mercurial developers use
>(with the to address being the mercurial-dev list). Or maybe better,
>hg email --outgoing --bundle which sends a binary bundle of all
>outgoing changesets. You can use --to to send the email to something
>like roundup (will Roundup extract an attachment from an email and add
>it to the issue as a file? That would be particularly neat...)

Wouldn't it be cool if we could hook this up to Rietveld?

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.

-Barry


signature.asc
Description: PGP signature
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Mercurial migration readiness

2010-07-01 Thread Martin v. Löwis 
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
alread).

Regards,
Martin
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Mercurial migration readiness (was: Taking over the Mercurial Migration)

2010-07-01 Thread Brett Cannon 
On Thu, Jul 1, 2010 at 15:07, Barry Warsaw  wrote:
> On Jul 01, 2010, at 10:57 PM, Paul Moore wrote:
>
>>On 1 July 2010 20:58, Brett Cannon  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 am also not saying this is how we
>>> will want people to contribute in the long run, but this does work
>>> and matches how svn does things well enough that people shouldn't get
>>> thrown by the details.
>>>
>>> 1. Contributor clones the repo
>>> 2. Contributor makes changes, committing as they go
>>> 3. Contributor runs ``hg outgoing --patch --git > patch.diff``
>>> 4. Committer runs ``hg patch --no-commit patch.diff``
>>> 5. Committer does the usual review->commit thing
>>>
>>> Basically this creates git-style diffs that one can shuttle around. I
>>> think you can also use ``patch -p1`` or git-apply to apply the patch
>>> generated by Mercurial.
>>
>>I'd suggest the patchbomb extension (distributed with Mercurial)
>>
>>hg email --outgoing --to d...@somewhere sends a series of patches to
>>the given email address. This is what the Mercurial developers use
>>(with the to address being the mercurial-dev list). Or maybe better,
>>hg email --outgoing --bundle which sends a binary bundle of all
>>outgoing changesets. You can use --to to send the email to something
>>like roundup (will Roundup extract an attachment from an email and add
>>it to the issue as a file? That would be particularly neat...)
>
> Wouldn't it be cool if we could hook this up to Rietveld?

Don't see why not; it already has Hg support, IIRC.

>
> 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.

As I said, quick-and-dirty. It will take discussion to decide what we
want to ask non-committers to do, weighing cost of complexity of the
approach for people new to DVCS in general and Hg in particular,
resource access such as a publicly accessible place to push repos,
what data format we prefer, etc. I just wanted to give David something
to go to PyOhio with that I know will be simple to explain and will
always work.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Mercurial migration readiness (was: Taking over the Mercurial Migration)

2010-07-01 Thread Antoine Pitrou 
On Thu, 1 Jul 2010 15:26:12 -0700
Brett Cannon  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 form of a patch.
Whether they use named branches, separate clones, mercurial queues, the
pbranch extension, or even the basic hg-as-an-svn-synonym workflow you
suggested should be none of our business, IMO.

A DVCS allows non-committers to manage (augment, fix, synchronize) their
patches more easily until they get committed. I don't think it will
change the committers' work a lot, though. I don't know how Mercurial
could make the task of committing an outsider's patch significantly
simpler.

Regards

Antoine.


___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Mercurial migration readiness (was: Taking over the Mercurial Migration)

2010-07-01 Thread Tim Delaney 
On 2 July 2010 08:07, Barry Warsaw  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 team over from ClearCase to Mercurial in the last 3 months
(just before we were made redundant ... :) Obviously our usage was coloured
by our previous use of ClearCase, but the workflow I found that worked best
was along the lines of the following.

1. Central server for the team, with a repository for each version (e.g.
2.6, 2.7, 3.2) where the default branch is the "trunk". Later versions get
cloned from a previous version at a particular tag, and merges between
versions are always forwards (if there's a need to merge backwards, we
cherry-pick the change by doing an hg export of the appropriate versions).

2. Developer made at least one clone of the appropriate repo, but could have
as many as they liked. Generally would have one local repo for production
work, and others for prototyping, exploratory work, etc - stuff that you may
not want in the central repo.

3. Each change is developed in its own named branch, named for the task
number. Local commits are performed as often as possible - no requirement
that any particular commit was compilable so long as it was on the task's
named branch.

4. Changesets are pushed to the central repository (requires forcing, as Hg
doesn't like you pushing new named branches). The named branch should be
compilable, pass unit tests, etc at this point. Generally preferred not to
edit the history or anything, but if there was something egregious

5. Other developers pulled from the central repository and reviewed
(integration with ReviewBoard or Reitveld was planned, but ran out of
time). This often led to a pair programming session on the reviewers machine
where comments were addressed directly.

6. Named branch was closed and merged to the main/trunk branch (in our case,
default). In our case this was usually done by the author - for Python this
would be done by a committer.

7. Merged default branch was pushed to the central repo, which triggered a
continuous build.

This approach is quite contrary to that favoured by the Mercurial
developers, but we found it had the following advantages:

a. Central team repo made backup and continuous build simple.

b. Named branches for tasks made the whole "what do I do with these
unfinished changes?" question moot - you commit them to your named branch.

c. Switching between tasks is incredibly simple - you already have your
workspace set up (e.g. Eclipse) and just update to the appropriate named
branch. No need to set up multiple workspaces.

d. Similarly, switching to someone else's named branch is just as easy (for
review, pair programming, etc).

e. Named branches make it very obvious what needs to be merged for any
particular task.

f. Easier to follow in the log/graphical log as everything was "tagged" with
what task it was against.

The only issue was that if a branch was abandoned, it would show up in "hg
branches" unless it was closed - but closing wasn't a problem since you can
always reopen if necessary.

Tim Delaney
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Mercurial migration readiness (was: Taking over the Mercurial Migration)

2010-07-01 Thread Tim Delaney 
On 2 July 2010 09:08, Tim Delaney  wrote:

> On 2 July 2010 08:07, Barry Warsaw  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.
>>
>>
> 7. Merged default branch was pushed to the central repo, which triggered a
> continuous build.
>
> Clarification here - I mean that a committer would merge it to default,
then pull it into the main python repo - there would be one that anyone
could push changes to, and those named branches would then be cherry-picked
to be merged and pulled into the main repo by committers. Or something along
those lines.

Tim Delaney
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Mercurial migration readiness (was: Taking over the Mercurial Migration)

2010-07-01 Thread Barry Warsaw 
On Jul 01, 2010, at 03:26 PM, Brett Cannon wrote:

>On Thu, Jul 1, 2010 at 15:07, Barry Warsaw  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.
>
>As I said, quick-and-dirty. It will take discussion to decide what we
>want to ask non-committers to do, weighing cost of complexity of the
>approach for people new to DVCS in general and Hg in particular,
>resource access such as a publicly accessible place to push repos,
>what data format we prefer, etc. I just wanted to give David something
>to go to PyOhio with that I know will be simple to explain and will
>always work.

That's cool.  I've had pretty good luck asking contributors on other project
to create branches and merge proposals (a Launchpad feature that triggers code
reviews), even when they first posted patches to a tracker or mailing list.
I'm confident most of our non-committers will find it pretty easy, especially
if we can provide a guide for the basics.

-Barry


signature.asc
Description: PGP signature
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Mercurial migration readiness (was: Taking over the Mercurial Migration)

2010-07-01 Thread Stephen J. Turnbull 
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 in a position to tell people to change them.

 > So, instead of rushing with migration

We are hardly rushing.  You're just late to the party.  Catch your
breathe, get a beer, have a good time.  No?

 > I'd like to propose incremental change rather than revolutionary
 > that will allow people to taste what it like to work with Mercurial
 > and update all relevant papers on the website.

Been there, done that, if that's the way it's gonna be, I won't touch
it.  It's much too painful for those who are doing the work, compared
to the small benefits received by the community as a whole.

 > I am willing to collaborate for getting this system in place before
 > EuroPython even if I won't find a chance to get there.

Are you also willing to maintain the system indefinitely?  I haven't
yet seen such a system that really works without regular attention
from a human.

 > However, PEP 385 "The Future of Subversion" [1] does not propose any
 > way to keep Subversion repository in sync. "it will probably live on
 > for a bit" phrase looks like Subversion will be immediately dead after
 > switching.

Yes, that is the intent.  For old versions, the Subversion repo will
be available read-only.

For casual contributors, there's a one-time set up cost of pulling a
local mirror from the public repository.

For those familiar with Mercurial, there is nothing but joy to be
found in the transition.

For folks like you, heavily invested in Subversion-based private
automation, yes, there will be some pain.

 > The second concern is workflow. Even after getting my hands dirty I
 > still can't find the best solution for working with Mercurial copy of
 > Python. In Subversion I do shallow checkouts of interesting features
 > when I run into one bug or another. Not all patches are ready, so they
 > stay in those checkouts as uncommitted diffs.

For this kind of workflow, Mercurial queues (mq) is probably the best
solution.  Unfortunately, it will require you to write some additional
scripts to get the same level of convenience you have now.

 > To be prepared for conflicts I review code with `svn log -vr
 > base:head` before updating.  But with Mercurial I see two major
 > problems with my workflow (which I am unlikely to change for the
 > next few weeks due to heavy automation):
 > 1. No shallow checkouts - that means that I have to copy 200Mb+ for
 > every patch I have

No, you don't.  You make links to 200MB+ (unless you're on Windows,
where I don't know how this works).  This is much cheaper than
copying, though not as cheap as in git.  I don't hesitate to make
branches in Mercurial.

Alternatively, for localized bugfixes, doc typos, and the like, one
"little-fixes" branch with an mq patch or two for each is a reasonable
way to work.

 > 2. No `hg log` command to see changes in my branch from remote
 > repository before fetching them
 > (I used to invoke `hg incoming`, but ended up with fetching everything
 > with `hg pull` and then using `hg log -vr .:tip`, because `hg inc`
 > didn't show changes that were already pulled, but not updated in wc,
 > and `hg log` could not show incoming)

 > 3. There is no clear branch separation in my working copy. I don't
 > know how to diff files in different branches without copying 200Mb+
 > clone. I don't know how to diff my files with remote repository
 > without pulling it.

If you're at all serious about working with Mercurial, you don't do
any operations except pull (and push, if you're a committer) against
the remote.  You keep a local pristine mirror of the remote
repository, which you update frequently, and all of your work revolves
around that rather than around contact with upstream.

This does mean that when upstream uses a repo-per-branch model you
have to keep multiple mirrors.  On the other hand, you can work
directly in branches that you work on only infrequently, and also use
Mercurial queues to avoid making branches if you don't want to.

 > 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.

No loss, either, since that's the current workflow, and maintaining as
much of the current workflow (possibly with "new spellings" of the
commands implementing it) was an explicit goal for PEP 374.  I assume
that carries over to PEP 385.

If you and some others working on a common project want to work with
branches rather than patches (email or tracker), then if there's a
committer in the group, you can set up a branch on code.python.org.
If not, you can use bitbucket or something.  Yes, it's a bit of extra
effort for you.

 > So from these PEPs I can't really see how Mercurial solves problems
 > with development. I can feel

Re: [Python-Dev] Mercurial migration readiness

2010-07-01 Thread Dan Buch 
> 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 instance at this address for anybody who wants to try
it out:

http://reviews.meatballhat.com

Cheers,

-- 
~ Dan


.. _ReviewBoard: http://www.reviewboard.org/


pgpaapotlZg21.pgp
Description: PGP signature
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Can Python implementations reject semantically invalid expressions?

2010-07-01 Thread Steven D'Aprano 
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 optimizer raised SyntaxError (or 
some other exception) on seeing this:

def f():
return 1 + "1"

instead of compiling something which can't fail to raise an exception, 
would that still be a legal Python implementation?


-- 
Steven D'Aprano
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Can Python implementations reject semantically invalid expressions?

2010-07-01 Thread Martin v. Löwis 
> 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 of compiling something which can't fail to raise an exception, 
> would that still be a legal Python implementation?

I'd say "no". Any syntactically correct module should start executing,
and type errors are only a runtime concept.

If you were to reject code at startup more restrictively, you might
end up rejecting the standard library, as it contains syntax errors
in code that isn't being imported normally (test/badsyntax*).

Regards,
Martin

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Can Python implementations reject semantically invalid expressions?

2010-07-01 Thread Glyph Lefkowitz 
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 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 of compiling something which can't fail to raise an exception, 
> would that still be a legal Python implementation?

I'd say "no".  Python has defined semantics in this situation: a TypeError is 
raised.

To me, this seems akin to a keyhole optimizer arbitrarily deciding that

raise TypeError()

should cause the compiler to abort.

If this type of expression were common, it would be within the rights of, for 
example, a Python JIT to generate a fast path through 'f' that wouldn't bother 
to actually invoke its 'int' type's '__add__' method, since there is no 
possible way for a Python program to tell the difference, since int.__add__ is 
immutable.

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Can Python implementations reject semantically invalid expressions?

2010-07-01 Thread Stefan Behnel 

Glyph Lefkowitz, 02.07.2010 06:43:

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 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 of compiling something which can't fail to raise an exception,
would that still be a legal Python implementation?


I'd say "no".  Python has defined semantics in this situation: a TypeError is 
raised.


So, would it still be Python if it folded

1 + "1"

into

raise TypeError()

at compile time?

Stefan

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Can Python implementations reject semantically invalid expressions?

2010-07-01 Thread Maciej Fijalkowski 
On Fri, Jul 2, 2010 at 12:31 AM, Stefan Behnel  wrote:
> Glyph Lefkowitz, 02.07.2010 06:43:
>>
>> 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 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 of compiling something which can't fail to raise an exception,
>>> would that still be a legal Python implementation?
>>
>> I'd say "no".  Python has defined semantics in this situation: a TypeError
>> is raised.
>
> So, would it still be Python if it folded
>
>    1 + "1"
>
> into
>
>    raise TypeError()
>
> at compile time?
>
> Stefan
>

This question has an easy answer - can you possibly tell the difference?

Cheers,
fijal
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Can Python implementations reject semantically invalid expressions?

2010-07-01 Thread Craig Citro 
> This question has an easy answer - can you possibly tell the difference?
>

Ok, I'm obviously being silly here, but sure you can:

>>> dis.dis("raise TypeError()")
  0 <114>   26977
  3 <115>8293
  6 IMPORT_STAR
  7 SETUP_EXCEPT25968 (to 25978)
 10 <69>
 11 <114>   28530
 14 <114>   10536
>>> dis.dis("1 + '1'")
  0 <49>
  1 SLICE+2
  2 STORE_SLICE+3
  3 SLICE+2
  4 <39>
  5 <49>
  6 <39>

That said, I agree with the point you're making -- they have the same
semantics, so you should be fine substituting one for the other.

Honestly, though, I'd come down on the side of letting the compiler
raise an error -- while I understand that it means you have
*different* behavior, I think it's *preferable* behavior.

-cc
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com