Re: [Python-Dev] Atlassian and bitbucket merge

[Brett Cannon]

On Tue, Sep 28, 2010 at 18:13, Steve Holden  wrote:
> I see that Atlassian have just taken over BitBucket, the Mercurial
> hosting company. IIRC Atlassian offered to host our issue tracking on
> JIRA, but in the end we decided to eat our own dog food and went with
> roundup.

That's right. Enough of a vocal stink was thrown when the
infrastructure committee chose a closed source, Java issue tracker
that we went with Roundup instead, even though Atlassian offered to
host the tracker for us.

>
> I'm wondering if they'd be similarly interested in supporting our Hg
> server. Or is self-hosting the only acceptable solution? From recent
> mail it looks likes we may be up and running on Hg fairly soon.

Looking at their pricing model, we don't need permission; public repos
can have unlimited contributors. Plus bitbucket supports CNAMEs so we
would also be able to still have hg.python.org for accessing the
repos.

The trick would be managing accounts. I would assume either everyone
would need bitbucket accounts to add as contributors to a repo, or a
dummy python-dev user account would be created where select core devs
could add SSH keys to the python-dev user account (although I think
the latter would destroy the commit history in terms of who made what
change as I suspect bitbucket does it based on the bitbucket account
and not one's .hgrc info although I could be wrong). Without knowing
how this would be handled I can't really comment.

>
> regards
>  Steve
> --
> Steve Holden           +1 571 484 6266   +1 800 494 3119
> DjangoCon US September 7-9, 2010    http://djangocon.us/
> See Python Video!       http://python.mirocommunity.org/
> Holden Web LLC                 http://www.holdenweb.com/
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> http://mail.python.org/mailman/options/python-dev/brett%40python.org
>
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Atlassian and bitbucket merge

[Dirkjan Ochtman]

On Wed, Sep 29, 2010 at 03:13, Steve Holden  wrote:
> I see that Atlassian have just taken over BitBucket, the Mercurial
> hosting company. IIRC Atlassian offered to host our issue tracking on
> JIRA, but in the end we decided to eat our own dog food and went with
> roundup.
>
> I'm wondering if they'd be similarly interested in supporting our Hg
> server. Or is self-hosting the only acceptable solution? From recent
> mail it looks likes we may be up and running on Hg fairly soon.

Don't know about acceptable, but as far as I know hosting Mercurial
repositories doesn't require as much work as hosting Roundup instances
(which the Mercurial project also has). I wouldn't mind maintaining
hg.python.org, and there are probably other devs that could also
easily get involved.

Anyway, I don't think using Bitbucket buys us much. It could be nice
to keep a mirror there for redundancy and because it might make
contributing slightly easier for non-committers, but it won't allow
doing all kinds of custom hooks the way we could do with hg.p.o,
AFAICT.

Cheers,

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

Re: [Python-Dev] Atlassian and bitbucket merge

[Dirkjan Ochtman]

On Wed, Sep 29, 2010 at 08:58, Brett Cannon  wrote:
> Looking at their pricing model, we don't need permission; public repos
> can have unlimited contributors. Plus bitbucket supports CNAMEs so we
> would also be able to still have hg.python.org for accessing the
> repos.
>
> The trick would be managing accounts. I would assume either everyone
> would need bitbucket accounts to add as contributors to a repo, or a
> dummy python-dev user account would be created where select core devs
> could add SSH keys to the python-dev user account (although I think
> the latter would destroy the commit history in terms of who made what
> change as I suspect bitbucket does it based on the bitbucket account
> and not one's .hgrc info although I could be wrong). Without knowing
> how this would be handled I can't really comment.

Yeah, you can just add all the SSH keys to a single account. And
usernames are always taken from the hgrc. Remember, the changeset
authors are put into the changeset at commit time, not at push time,
and the changeset ID depends on it, so you could never have a remote
host changing the usernames without the history changing.

Still, I think the flexibility of self-hosting (in terms of hooks and
extension -- for example the one that would allow lookup by SVN rev)
should win out here.

Cheers,

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

Re: [Python-Dev] Prefetching on buffered IO files

[Hagen Fürstenau]

> Ow... I've always assumed that seek() is essentially free, because
> that's how a typical OS kernel implements it. If seek() is bad on
> GzipFile, how hard would it be to fix this?

I'd imagine that there's no easy way to make arbitrary seeks on a
GzipFile fast. But wouldn't it be enough to optimize small relative
(backwards) seeks?

> How common is the use case where you need to read a gzipped pickle
> *and* you need to leave the unzipped stream positioned exactly at the
> end of the pickle?

Not uncommon, I think. You need this for unpickling objects which were
dumped one after another into a GzipFile, right?

ISTM that the immediate performance issue can be solved by the present
patch, and there's room for future improvement by optimizing GzipFile
seeks and/or extending the IO API.

Cheers,
Hagen

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

Re: [Python-Dev] hg conversion: tags

[Dirkjan Ochtman]

Okay, so let's summarize this thread so far:

Martin is in favor of removing some tags (certainly partial ones), but
is -0 on renaming them.
Tres is in favor of renaming release tags.
Georg advocates removing non-release tags, and doesn't care much about renaming.
Barry would like to clean up release tag names (either dotted or hexversion).
Alexander is +1 on renaming tags on the premise that "r311" tags
conflict with "r42543" SVN rev notation.
Antoine is in favor of renaming tags on the premise that using hg log
-rr311 is awkward in comparison to -r3.1.1.

So it seems like most people here like the idea of renaming the tags.
Martin and Georg would also like to get rid of some of the non-release
tags, but it's unclear if we should get rid of all non-release tags or
just the partial ones.

Below is a grouped list. Based on that list, I propose the following scheme:

- keep all "normal" release tags, renamed along these lines:
r27 -> 2.7
r266 -> 2.6.6
r27rc2 -> 2.7rc2
r262c1 -> 2.6.2rc1 (rc and c should be normalized into the same
thing, don't care which one)
r30b3 -> 3.0b3
release22 -> 2.2

- keep Mac release tags that don't have the top-level Mac dir, renamed
along these lines:
r23b1-mac -> 2.3b1-mac

- get rid of "special" release tags and Mac release tags with top-level Mac dir
- get rid of email and distutils tags
- get rid of all other tags

Does that make sense?

Cheers,

Dirkjan

==

"Normal" release tags:

r32a2
r266
r266rc2
r266rc1
r32a1
r27
r27rc2
r27rc1
r27b2
r27b1
r312
r265
r265rc2
r312rc1
r27a4
r265rc1
r27a3
r255
r255c2
r255c1
r27a2
r27a1
r311
r264
r264rc2
r264rc1
r263
r263rc1
r311rc1
r31
r31rc2
r31rc1
r31b1
r262
r262c1
r31a2
r31a1
r301
r254
r253
r246
r253c1
r246c1
r261
r30
r30rc3
r30rc2
r26
r26rc2
r30rc1
r26rc1
r30b3
r26b3
r26b2
r30b2
r26b1
r30b1
r26a3
r30a5
r26a2
r30a4
r237
r245
r237c1
r245c1
r30a3
r26a1
r252
r252c1
r251c1
r30a2
r30a1
r251
r236
r236c1
r244
r244c1
r25
r25c2
r25c1
r25b3
r25b2
r25b1
r25a2
r25a1
r25a0
r243
r243c1
r242
r242c1
r241
r241c2
r241c1
r235
r235c1
r24
r24c1
r24b2
r24b1
r24a3
r24a2
r24a1
r234
r234c1
r233
r233c1
r232
r232c1
r231
r23
r23c2
r23c1
r23b2
r09b1
r223
r223c1
r23b1
r23a2
r09a2
r09a1
r23a1
r09a0
r222
r222b1
r221
r213
r22p1
r221c2
r221c1
r212
r212c1
r22c1
r22b2
r22b1
r22a4
r22a3
r22a2
r211
r22a1
r211c1
r201
r201c1
r21c2
r21c1
r21b2
r21b1
r161
r21a2
r21a1
r20c1
r20b2
r20b11
r20b1
r16b1
r16a2
r16a1
r152
r152c1
r06
r152b2
r152b1
r01
r152a2
r152a1
r151
r15b2
r15b1
r15a4
r15a3
r15a2
r15a1
r14beta3
r14beta2
r14beta1
r13beta1
r12beta4
r12beta3
r12beta2
r12beta1
release22
release21
release20
release16
release15
release14
release13
release12
release111
release11
release102
release101
release100
release099
release098

"Special" release tags:

release152p1-branch-tag
r09a2nt
r16b1-win
r15a4near
r22b1-docs-prep
r22a3-docs-prep
r22a2-docs-prep
r23a1-fork
r23rc1-fork
r23b2-fork
r23b1-fork
r23a2-fork
r22b2-fork
r22rc1-fork
r22a2-fork
r22b1-fork
r22a4-fork
r22a3-fork
release24-fork
release23-fork
release22-fork
release152p2 (docs only)
release152p1 (docs only)
release152 (docs only)
release152b2 (docs only)
release152b1 (docs only)
release152a1 (docs only)
release151p1 (docs only)

Mac releases:

r23b1-mac
r222-mac
r23-mac
r22c1-mac
r22b2-mac
r22b1-mac
release22-mac
mac102
r22c1-macmergefromtrunk (Mac dir)
release22-macmerge (Mac dir)
mac152c1 (Mac dir)
mac152b1 (Mac dir)
mac151 (Mac dir)
mac210 (Mac dir)
mac210b2 (Mac dir)
mac210b1a (Mac dir)
mac210b1 (Mac dir)
mac210a3 (Mac dir)
mac210a1 (Mac dir)
mac200 (Mac dir)
mac200b1 (Mac dir)

distutils tags (distutils only):

Distutils-1_0_3
Distutils-1_0_2
Distutils-1_0_1
Distutils-1_0
Distutils-0_9_4
Distutils-0_9_3
Distutils-0_9_2
Distutils-0_9_1
Distutils-0_9
Distutils-0_8_2
Distutils-0_8_1
Distutils-0_8
Distutils-0_1_5
Distutils-0_1_4
Distutils-0_1_3-branch
Distutils-0_1_3
Distutils-0_1_2
Distutils-0_1_1
Distutils-0_1

email tags (email only):

email_Release_2_5_6
email_Release_2_5_5
email_Release_2_5_3
email_Release_2_5_2
email_Release_2_5_1
email_Release_2_5
email_Release_2_5b1
email_Release_2_4_3
email_Release_2_4_2
email_Release_2_4_1
email_Release_2_4
email_Release_2_3_1
email_Release_2_3
email_Release_2_2
email_Release_2_1
Release_2_0_4
email_Release_2_0_5

Other tags:

r25a0/trunk
py3k-before-rstdocs
py26-before-rstdocs
before-ast-merge-to-head
mrg_to_ast-branch_15OCT05
IDLE-syntax-root
merged_from_MAIN_07JAN05
mrg_to_ast-branch_05JAN05
pre-sf-818006
bsddb_version_4_3_0
tim-doctest-closed
tim-doctest-merge-24a2
pre-sf-1149508
start-sf-965425
before-ast-merge-from-head
bsddb_version_4_2_4
pybsddb_after_bsddb42_01
pybsddb_before_bsddb42
bsddb_version_4_1_6
anthony-parser-branchpoint
IDLELIB_CREATED
COPY_TO_PYTHON
mrg_to_ast-branch_24APR03
cache-attr-fork
LAST_OLD_IDLE
before-bgen-pep252
py-cvs-2002_09_13-merged
py-cvs-2002_09_13
MERGED_FROM_DS_RPC_13SEP02
MERGED_TO_MAIN_13SEP02
PRE_DS_RPC_MERGE
BEFORE_RESTART
final_classic_builds
TAG_pre_teyc_gvr_rpc_patch
final_

Re: [Python-Dev] hg conversion: tags

[M.-A. Lemburg]

Dirkjan Ochtman wrote:
> Okay, so let's summarize this thread so far:
> 
> Martin is in favor of removing some tags (certainly partial ones), but
> is -0 on renaming them.
> Tres is in favor of renaming release tags.
> Georg advocates removing non-release tags, and doesn't care much about 
> renaming.
> Barry would like to clean up release tag names (either dotted or hexversion).
> Alexander is +1 on renaming tags on the premise that "r311" tags
> conflict with "r42543" SVN rev notation.
> Antoine is in favor of renaming tags on the premise that using hg log
> -rr311 is awkward in comparison to -r3.1.1.
> 
> So it seems like most people here like the idea of renaming the tags.
> Martin and Georg would also like to get rid of some of the non-release
> tags, but it's unclear if we should get rid of all non-release tags or
> just the partial ones.
> 
> Below is a grouped list. Based on that list, I propose the following scheme:
> 
> - keep all "normal" release tags, renamed along these lines:
> r27 -> 2.7
> r266 -> 2.6.6
> r27rc2 -> 2.7rc2
> r262c1 -> 2.6.2rc1 (rc and c should be normalized into the same
> thing, don't care which one)
> r30b3 -> 3.0b3
> release22 -> 2.2
> 
> - keep Mac release tags that don't have the top-level Mac dir, renamed
> along these lines:
> r23b1-mac -> 2.3b1-mac
> 
> - get rid of "special" release tags and Mac release tags with top-level Mac 
> dir
> - get rid of email and distutils tags
> - get rid of all other tags
> 
> Does that make sense?

I'm not sure whether throwing away history in form of such tags
is a good idea.

I don't know how hg manages this, but can't we preserve the tag
information of the tags that you've scheduled to be removed
in some place that can easily be pulled in but doesn't
affect the main repo size ?

Renaming the release tags certainly is a good idea, since
we're not stuck with CVS naming requirements anymore. I'd prefix
the release tags with "release-" for additional context,
though.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Sep 29 2010)
>>> Python/Zope Consulting and Support ...http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/


::: Try our new mxODBC.Connect Python Database Interface for free ! 


   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
   Registered at Amtsgericht Duesseldorf: HRB 46611
   http://www.egenix.com/company/contact/
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Prefetching on buffered IO files

[Antoine Pitrou]

On Wed, 29 Sep 2010 10:06:57 +0200
Hagen Fürstenau  wrote:
> > Ow... I've always assumed that seek() is essentially free, because
> > that's how a typical OS kernel implements it. If seek() is bad on
> > GzipFile, how hard would it be to fix this?
> 
> I'd imagine that there's no easy way to make arbitrary seeks on a
> GzipFile fast. But wouldn't it be enough to optimize small relative
> (backwards) seeks?

As I explained to Guido, GzipFile doesn't know the buffering size of
its consumer (apart from introducing couplings), and therefore
has no way to know how much information it must retain.

To reiterate, there's a complicated solution (optimize an
implementation-dependent behaviour of GzipFile, with a non-trivial
coding effort and performance tradeoff) which will not work on
unseekable files anyway. And there's a more generic solution involving
non-seeking primitives such as read() + peek().

(follow-up to python-ideas, if I didn't mess up the headers)

Regards

Antoine.


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

Re: [Python-Dev] Atlassian and bitbucket merge

[Victor Stinner]

Le mercredi 29 septembre 2010 08:58:49, Brett Cannon a écrit :
> The trick would be managing accounts. I would assume either everyone
> would need bitbucket accounts to add as contributors to a repo, or a
> dummy python-dev user account would be created where select core devs
> could add SSH keys to the python-dev user account (although I think
> the latter would destroy the commit history in terms of who made what
> change as I suspect bitbucket does it based on the bitbucket account
> and not one's .hgrc info although I could be wrong).

Can't we rewrite the history when converting from svn to hg to use real names 
instead of logins?

Mercurial 1.6 (and maybe older versions) refuses to commit if the user didn't 
set its name (in ~/.hgrc).

Bitbucket doesn't rewrite commit authors: it keeps original names. So 
developers have to configure correctly their Mercurial, but it allows to keep 
the name of the contributor on a contribution.

Is it possible with Mercurial to add a tag on a commit to specify who commited 
a contribution? Like the Signed-By tag with git on the Linux kernel.

-- 
Victor Stinner
http://www.haypocalc.com/
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Atlassian and bitbucket merge

[Antoine Pitrou]

On Wed, 29 Sep 2010 09:03:29 +0200
Dirkjan Ochtman  wrote:
> 
> Anyway, I don't think using Bitbucket buys us much. It could be nice
> to keep a mirror there for redundancy and because it might make
> contributing slightly easier for non-committers, but it won't allow
> doing all kinds of custom hooks the way we could do with hg.p.o,
> AFAICT.

Using Bitbucket seems mainly useful if you need the whole suite of
services (issue tracker, wiki, etc.).

Also, I find the Bitbucket UI horrible. Better than Launchpad probably,
but still...

Regards

Antoine.


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

Re: [Python-Dev] Atlassian and bitbucket merge

[Ben Finney]

Dirkjan Ochtman  writes:

> Still, I think the flexibility of self-hosting (in terms of hooks and
> extension -- for example the one that would allow lookup by SVN rev)
> should win out here.

Not only the flexibility, but the autonomy. Hosting the source code on
systems either paid for by PSF funds or donated to the PSF will allow
all decisions about how the VCS repositories are administrated to be
made without deferring to the repository provider as a separate entity.

Or, more briefly: it's better for the PSF to be as much in control of
the decisions about what happens to the VCS repositories as possible.

-- 
 \“We have to go forth and crush every world view that doesn't |
  `\believe in tolerance and free speech.” —David Brin |
_o__)  |
Ben Finney

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

Re: [Python-Dev] Atlassian and bitbucket merge

[Georg Brandl]

Am 29.09.2010 09:03, schrieb Dirkjan Ochtman:
> On Wed, Sep 29, 2010 at 03:13, Steve Holden  wrote:
>> I see that Atlassian have just taken over BitBucket, the Mercurial
>> hosting company. IIRC Atlassian offered to host our issue tracking on
>> JIRA, but in the end we decided to eat our own dog food and went with
>> roundup.
>>
>> I'm wondering if they'd be similarly interested in supporting our Hg
>> server. Or is self-hosting the only acceptable solution? From recent
>> mail it looks likes we may be up and running on Hg fairly soon.
> 
> Don't know about acceptable, but as far as I know hosting Mercurial
> repositories doesn't require as much work as hosting Roundup instances
> (which the Mercurial project also has). I wouldn't mind maintaining
> hg.python.org, and there are probably other devs that could also
> easily get involved.
> 
> Anyway, I don't think using Bitbucket buys us much. It could be nice
> to keep a mirror there for redundancy and because it might make
> contributing slightly easier for non-committers, but it won't allow
> doing all kinds of custom hooks the way we could do with hg.p.o,
> AFAICT.

Agreed on both counts.  Bitbucket will be a good solution for non-core
developers to host their clones and branches, and I'm sure there will
be a mirror of the main Python repo somewhere.  But as you say, hosting
Mercurial is very easy, and doesn't require constant administration.

The argument of hooks is a very strong one in favor of hg.python.org.

Georg

-- 
Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
Four shall be the number of spaces thou shalt indent, and the number of thy
indenting shall be four. Eight shalt thou not indent, nor either indent thou
two, excepting that thou then proceed to four. Tabs are right out.

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

Re: [Python-Dev] Atlassian and bitbucket merge

[Dirkjan Ochtman]

On Wed, Sep 29, 2010 at 11:35, Victor Stinner
 wrote:
> Can't we rewrite the history when converting from svn to hg to use real names
> instead of logins?

I've been doing that since the start, look at the test repo on hg.p.o.

Cheers,

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

Re: [Python-Dev] Atlassian and bitbucket merge

[Xavier Morel]

On 2010-09-29, at 11:50 , Antoine Pitrou wrote:
> On Wed, 29 Sep 2010 09:03:29 +0200
> Dirkjan Ochtman  wrote:
>> 
>> Anyway, I don't think using Bitbucket buys us much. It could be nice
>> to keep a mirror there for redundancy and because it might make
>> contributing slightly easier for non-committers, but it won't allow
>> doing all kinds of custom hooks the way we could do with hg.p.o,
>> AFAICT.
> 
> Using Bitbucket seems mainly useful if you need the whole suite of
> services (issue tracker, wiki, etc.).
> 

The most useful features are probably the follow and fork, but for a project as 
big as Python I'm not sure those are going to be used a lot. The question then 
becomes whether Python development workflow will remain as-is or would more to 
a "pull-request" model via bitbucket.

If it's negative, then I see no intrinsic value in the main server being on 
bitbucket.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Resource leaks warnings

[Antoine Pitrou]

Hello,

> I'd like to ask your opinion on this change; I think it should be reverted
> or at least made silent by default.  Basically, it prints a warning like
> 
>   gc: 2 uncollectable objects at shutdown:
>   Use gc.set_debug(gc.DEBUG_UNCOLLECTABLE) to list them.
> 
> at interpreter shutdown if gc.garbage is nonempty.

I would like to piggy-back on this discussion to suggest further
warnings (either by default, or switchable).

One feature I've often considered would be to add a warning in FileIO
and socket dealloc if these objects haven't been closed explicitly. In
most situations, relying on garbage collection to shutdown OS resources
(here, file descriptors) is something we like to discourage.
Furthermore, it can produce real bugs, especially under Windows when
coupled with refererence cycles created by traceback objects (the
random test_tarfile failures on the Windows buildbots were a symptom of
that; their cause would have been obvious with such warnings).

What do you think?

Antoine.


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

Re: [Python-Dev] Pronouncement needed in issue9675

[Nick Coghlan]

On Wed, Sep 29, 2010 at 9:03 AM, Jesus Cea  wrote:
> About converting the deprecation warning to a py3k warning... Would a
> py3k warning be converted to an error when python is invoked as "-We"?.
> If that is the case, we are in the same situation.

To unpack Guido's response slightly, Py3k specific deprecation
warnings are only triggered if you pass the "-3" flag on the command
line. So "-We" won't cause them to throw an exception, but "-We -3"
will.

(Python 2.6.5, started with "-We")
>>> warnings.warnpy3k("Test")
>>> sys.py3kwarning = True
>>> warnings.warnpy3k("Test")
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python2.6/warnings.py", line 22, in warnpy3k
warn(message, category, stacklevel+1)
DeprecationWarning: Test

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] hg conversion: tags

[Nick Coghlan]

On Wed, Sep 29, 2010 at 6:29 PM, M.-A. Lemburg  wrote:
> I'm not sure whether throwing away history in form of such tags
> is a good idea.
>
> I don't know how hg manages this, but can't we preserve the tag
> information of the tags that you've scheduled to be removed
> in some place that can easily be pulled in but doesn't
> affect the main repo size ?

But why bother? The tags are static, so grabbing them from svn instead
of hg shouldn't be a big issue. If we had unlimited resources to
support the transition my opinion would probably be different, but
since we don't, applying the simple rule of culling the non-release
tags seems good enough and better than spending too much time trying
to figure out which tags are "important" enough to be worth
preserving.

> Renaming the release tags certainly is a good idea, since
> we're not stuck with CVS naming requirements anymore. I'd prefix
> the release tags with "release-" for additional context,
> though.

So long as we don't start using bare numbers for anything other than
releases, I think that would just become redundant typing in fairly
short order.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Resource leaks warnings

[Benjamin Peterson]

2010/9/29 Antoine Pitrou :
>
> Hello,
>
>> I'd like to ask your opinion on this change; I think it should be reverted
>> or at least made silent by default.  Basically, it prints a warning like
>>
>>       gc: 2 uncollectable objects at shutdown:
>>           Use gc.set_debug(gc.DEBUG_UNCOLLECTABLE) to list them.
>>
>> at interpreter shutdown if gc.garbage is nonempty.
>
> I would like to piggy-back on this discussion to suggest further
> warnings (either by default, or switchable).
>
> One feature I've often considered would be to add a warning in FileIO
> and socket dealloc if these objects haven't been closed explicitly. In
> most situations, relying on garbage collection to shutdown OS resources
> (here, file descriptors) is something we like to discourage.
> Furthermore, it can produce real bugs, especially under Windows when
> coupled with refererence cycles created by traceback objects (the
> random test_tarfile failures on the Windows buildbots were a symptom of
> that; their cause would have been obvious with such warnings).
>
> What do you think?

It seems like a slippery slope. Sometimes you really don't care like
when you're just hacking together a quick script.


-- 
Regards,
Benjamin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] hg conversion: tags

[Tres Seaver]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 09/29/2010 08:16 AM, Nick Coghlan wrote:
> On Wed, Sep 29, 2010 at 6:29 PM, M.-A. Lemburg  wrote:
>> I'm not sure whether throwing away history in form of such tags
>> is a good idea.
>>
>> I don't know how hg manages this, but can't we preserve the tag
>> information of the tags that you've scheduled to be removed
>> in some place that can easily be pulled in but doesn't
>> affect the main repo size ?
> 
> But why bother? The tags are static, so grabbing them from svn instead
> of hg shouldn't be a big issue. If we had unlimited resources to
> support the transition my opinion would probably be different, but
> since we don't, applying the simple rule of culling the non-release
> tags seems good enough and better than spending too much time trying
> to figure out which tags are "important" enough to be worth
> preserving.

I think the key heuristic is which information you want to use directly
in Hg, e.g. to diff between tags, or diff a working branch against a
tag.  Based on how I use tags under SVN, the release tags account for
nearly all of such cases.  Having to go back to SVN to check out the
rare exception seems like a good tradeoff.

>> Renaming the release tags certainly is a good idea, since
>> we're not stuck with CVS naming requirements anymore. I'd prefix
>> the release tags with "release-" for additional context,
>> though.
> 
> So long as we don't start using bare numbers for anything other than
> releases, I think that would just become redundant typing in fairly
> short order.

+1 for bare release numbers (Dirkjan's proposal).  Although I would
prefer 'c' over 'rc' in the normalized case, PEP 386 allows 'rc' as an
alternative to 'c' precisely because some Python versions used it).  I
think we need to make the migrated version tags match the corresponding
tarball version numbers exactly.


Tres.
- -- 
===
Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   "Excellence by Design"http://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkyjMdgACgkQ+gerLs4ltQ4Y1ACfeIK6KtO7RAZyzcSp5ap2/Zn6
bH8AnjQGRFjrI7PaisUcSex3nsFp4AR/
=f8ZR
-END PGP SIGNATURE-

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

Re: [Python-Dev] Resource leaks warnings

[Dirkjan Ochtman]

On Wed, Sep 29, 2010 at 14:27, Benjamin Peterson  wrote:
> It seems like a slippery slope. Sometimes you really don't care like
> when you're just hacking together a quick script.

Yeah, I often don't close files in scripts that I know are short
running or only ever open one or two files, and I don't think I should
be warned about that.

Cheers,

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

Re: [Python-Dev] Atlassian and bitbucket merge

[exarkun]

On 01:13 am, st...@holdenweb.com wrote:

I see that Atlassian have just taken over BitBucket, the Mercurial
hosting company. IIRC Atlassian offered to host our issue tracking on
JIRA, but in the end we decided to eat our own dog food and went with
roundup.

I'm wondering if they'd be similarly interested in supporting our Hg
server. Or is self-hosting the only acceptable solution? From recent
mail it looks likes we may be up and running on Hg fairly soon.


I know of two medium sized projects (smaller than CPython) that are 
switching away from BitBucket's free services because of their poor 
reliability.


Jean-Paul
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] hg conversion: tags

[Benjamin Peterson]

2010/9/29 Tres Seaver :
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 09/29/2010 08:16 AM, Nick Coghlan wrote:
>> On Wed, Sep 29, 2010 at 6:29 PM, M.-A. Lemburg  wrote:
>>> I'm not sure whether throwing away history in form of such tags
>>> is a good idea.
>>>
>>> I don't know how hg manages this, but can't we preserve the tag
>>> information of the tags that you've scheduled to be removed
>>> in some place that can easily be pulled in but doesn't
>>> affect the main repo size ?
>>
>> But why bother? The tags are static, so grabbing them from svn instead
>> of hg shouldn't be a big issue. If we had unlimited resources to
>> support the transition my opinion would probably be different, but
>> since we don't, applying the simple rule of culling the non-release
>> tags seems good enough and better than spending too much time trying
>> to figure out which tags are "important" enough to be worth
>> preserving.
>
> I think the key heuristic is which information you want to use directly
> in Hg, e.g. to diff between tags, or diff a working branch against a
> tag.  Based on how I use tags under SVN, the release tags account for
> nearly all of such cases.  Having to go back to SVN to check out the
> rare exception seems like a good tradeoff.
>
>>> Renaming the release tags certainly is a good idea, since
>>> we're not stuck with CVS naming requirements anymore. I'd prefix
>>> the release tags with "release-" for additional context,
>>> though.
>>
>> So long as we don't start using bare numbers for anything other than
>> releases, I think that would just become redundant typing in fairly
>> short order.
>
> +1 for bare release numbers (Dirkjan's proposal).  Although I would
> prefer 'c' over 'rc' in the normalized case, PEP 386 allows 'rc' as an
> alternative to 'c' precisely because some Python versions used it).  I
> think we need to make the migrated version tags match the corresponding
> tarball version numbers exactly.

Well, the tarballs use rc, too.



-- 
Regards,
Benjamin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Resource leaks warnings

[Antoine Pitrou]

Le mercredi 29 septembre 2010 à 07:27 -0500, Benjamin Peterson a écrit :
> >
> > I would like to piggy-back on this discussion to suggest further
> > warnings (either by default, or switchable).
> >
> > One feature I've often considered would be to add a warning in FileIO
> > and socket dealloc if these objects haven't been closed explicitly. In
> > most situations, relying on garbage collection to shutdown OS resources
> > (here, file descriptors) is something we like to discourage.
> > Furthermore, it can produce real bugs, especially under Windows when
> > coupled with refererence cycles created by traceback objects (the
> > random test_tarfile failures on the Windows buildbots were a symptom of
> > that; their cause would have been obvious with such warnings).
> >
> > What do you think?
> 
> It seems like a slippery slope. Sometimes you really don't care like
> when you're just hacking together a quick script.

Isn't the "with" statement appropriate in these cases?

My assumption is/was that the benefit of warning against leaks in real
applications (or even - sigh - the standard library) would outweigh the
inconvenience when hacking together a quick script.

But if it doesn't, what about enabling it with a command-line switch?


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

Re: [Python-Dev] Atlassian and bitbucket merge

[Steve Holden]

On 9/29/2010 6:32 AM, Ben Finney wrote:
> Dirkjan Ochtman  writes:
> 
>> Still, I think the flexibility of self-hosting (in terms of hooks and
>> extension -- for example the one that would allow lookup by SVN rev)
>> should win out here.
> 
> Not only the flexibility, but the autonomy. Hosting the source code on
> systems either paid for by PSF funds or donated to the PSF will allow
> all decisions about how the VCS repositories are administrated to be
> made without deferring to the repository provider as a separate entity.
> 
> Or, more briefly: it's better for the PSF to be as much in control of
> the decisions about what happens to the VCS repositories as possible.
> 
That's true, but we also have to balance that against the resources it
takes to develop and manage our own hosting solutions. I'm not trying to
push one way or the other (and Dirkan's points about tailored commit
hooks seems compelling); I simply want to make sure that as much
developer time as possible is actually spent developing Python rather
than supporting the development effort in various ways that aren't as
directly productive.

regards
 Steve
-- 
Steve Holden   +1 571 484 6266   +1 800 494 3119
DjangoCon US September 7-9, 2010http://djangocon.us/
See Python Video!   http://python.mirocommunity.org/
Holden Web LLC http://www.holdenweb.com/
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] hg conversion: tags

[Tres Seaver]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 09/29/2010 08:38 AM, Benjamin Peterson wrote:
> 2010/9/29 Tres Seaver :

>> +1 for bare release numbers (Dirkjan's proposal).  Although I would
>> prefer 'c' over 'rc' in the normalized case, PEP 386 allows 'rc' as an
>> alternative to 'c' precisely because some Python versions used it).  I
>> think we need to make the migrated version tags match the corresponding
>> tarball version numbers exactly.
> 
> Well, the tarballs use rc, too.

Right.  I meant to indicate that we should map any 'rc' in the
historical release tarball name onto 'rc' in the new Hg tag.


Tres.
- -- 
===
Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   "Excellence by Design"http://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkyjOVsACgkQ+gerLs4ltQ4r9wCfYKYhfPTn/At4zqBuGCqYIwPf
uQUAoNPsbKLkSDPflITveyBQ+VE24Tnl
=vBUr
-END PGP SIGNATURE-

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

Re: [Python-Dev] Resource leaks warnings

[Steven D'Aprano]

On Wed, 29 Sep 2010 10:42:27 pm Antoine Pitrou wrote:

> My assumption is/was that the benefit of warning against leaks in
> real applications (or even - sigh - the standard library) would
> outweigh the inconvenience when hacking together a quick script.
>
> But if it doesn't, what about enabling it with a command-line switch?

I think the ability to detect such file descriptor leaks would be 
valuable, but I'm not sure that it should be running all the time. At 
the risk of bike-shedding, is it something which could be controlled at 
runtime, like garbage collection? E.g. something like:

gc.enable_file_warnings()
run_my_tests_for_leakage()
gc.disable_file_warnings()

or similar. (I'm not wedded to it being in the gc module.)

Otherwise, I'm +0.25 on enabling it with a command line switch, and -0 
on turning it on by default.


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

Re: [Python-Dev] Resource leaks warnings

[Hrvoje Niksic]

On 09/29/2010 02:42 PM, Antoine Pitrou wrote:

 It seems like a slippery slope. Sometimes you really don't care like
 when you're just hacking together a quick script.


Isn't the "with" statement appropriate in these cases?


A hacked-together quick script might contain code like:

parse(open(bla).read())

Compared to this, "with" adds a new indentation level and a new 
variable, while breaking the flow of the code:


with open(bla) as foo:
contents = foo.read()
parse(contents)

People used to writing production code under stringent guidelines 
(introduced for good reason) will probably not be sympathetic to 
quick-hack usage patterns, but Python is used on both sides of the fence.

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

Re: [Python-Dev] Atlassian and bitbucket merge

[Tarek Ziadé]

On Wed, Sep 29, 2010 at 2:36 PM,   wrote:
> On 01:13 am, st...@holdenweb.com wrote:
>>
>> I see that Atlassian have just taken over BitBucket, the Mercurial
>> hosting company. IIRC Atlassian offered to host our issue tracking on
>> JIRA, but in the end we decided to eat our own dog food and went with
>> roundup.
>>
>> I'm wondering if they'd be similarly interested in supporting our Hg
>> server. Or is self-hosting the only acceptable solution? From recent
>> mail it looks likes we may be up and running on Hg fairly soon.
>
> I know of two medium sized projects (smaller than CPython) that are
> switching away from BitBucket's free services because of their poor
> reliability.

Me too, but I am pretty sure the reliability is going to drastically
change in the upcoming months. If Atlassian took over this probably
means Bitbucket will have more people to work on the project and some
help from the Atlassian Ops. That's really a good news !

Although, I am also -1 because of the hooks management issues that were raised

-- 
Tarek Ziadé | http://ziade.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] hg conversion: tags

[M.-A. Lemburg]

Nick Coghlan wrote:
> On Wed, Sep 29, 2010 at 6:29 PM, M.-A. Lemburg  wrote:
>> I'm not sure whether throwing away history in form of such tags
>> is a good idea.
>>
>> I don't know how hg manages this, but can't we preserve the tag
>> information of the tags that you've scheduled to be removed
>> in some place that can easily be pulled in but doesn't
>> affect the main repo size ?
> 
> But why bother? The tags are static, so grabbing them from svn instead
> of hg shouldn't be a big issue. If we had unlimited resources to
> support the transition my opinion would probably be different, but
> since we don't, applying the simple rule of culling the non-release
> tags seems good enough and better than spending too much time trying
> to figure out which tags are "important" enough to be worth
> preserving.

You don't need to spend any extra time on this: just put all the tags
that Dirkjan wants to delete into some other place. The separation
work has already been done by Dirkjan.

Note that the reason for keeping this history around is just that:
for historic purposes and possible future research (e.g on copyright
issues). It's not meant for development.

>> Renaming the release tags certainly is a good idea, since
>> we're not stuck with CVS naming requirements anymore. I'd prefix
>> the release tags with "release-" for additional context,
>> though.
> 
> So long as we don't start using bare numbers for anything other than
> releases, I think that would just become redundant typing in fairly
> short order.

That's a Perl argument ;-)

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Sep 29 2010)
>>> Python/Zope Consulting and Support ...http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/


::: Try our new mxODBC.Connect Python Database Interface for free ! 


   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
   Registered at Amtsgericht Duesseldorf: HRB 46611
   http://www.egenix.com/company/contact/
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Resource leaks warnings

[Barry Warsaw]

On Sep 29, 2010, at 11:11 PM, Steven D'Aprano wrote:

>On Wed, 29 Sep 2010 10:42:27 pm Antoine Pitrou wrote:
>
>> My assumption is/was that the benefit of warning against leaks in
>> real applications (or even - sigh - the standard library) would
>> outweigh the inconvenience when hacking together a quick script.
>>
>> But if it doesn't, what about enabling it with a command-line switch?
>
>I think the ability to detect such file descriptor leaks would be 
>valuable, but I'm not sure that it should be running all the time. At 
>the risk of bike-shedding, is it something which could be controlled
>at runtime, like garbage collection? E.g. something like:
>
>gc.enable_file_warnings()
>run_my_tests_for_leakage()
>gc.disable_file_warnings()
>
>or similar. (I'm not wedded to it being in the gc module.)

I don't think it should be in the gc module, but I would prefer it be enabled
and controlled through a separate module, rather than something Python does
automatically for your convenience.

-Barry


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

Re: [Python-Dev] hg conversion: tags

[Barry Warsaw]

On Sep 29, 2010, at 10:15 AM, Dirkjan Ochtman wrote:

>Below is a grouped list. Based on that list, I propose the following
>scheme:
>
>- keep all "normal" release tags, renamed along these lines:
>r27 -> 2.7
>r266 -> 2.6.6

+1

>r27rc2 -> 2.7rc2
>r262c1 -> 2.6.2rc1 (rc and c should be normalized into the same
>thing, don't care which one)

Personally, I prefer 'c' to keep things regular.

>r30b3 -> 3.0b3
>release22 -> 2.2

+1

>- keep Mac release tags that don't have the top-level Mac dir, renamed
>along these lines:
>r23b1-mac -> 2.3b1-mac

+0

>- get rid of "special" release tags and Mac release tags with
>top-level Mac dir
>- get rid of email and distutils tags

+0.  If distutils-sig needs those tags, keep 'em.  Similarly with email-sig,
but being more involved with the separate email package releases, I don't
think they'll be necessary.  We're not going to diff against any earlier
release and we have an email6 repository in Bazaar on Launchpad.  When we
integrate that back into Python, it'll likely be an undiffable change so I see
no reason to keep the old tags (we can decide later if we'll want new tags in
the main Python repo).

>- get rid of all other tags

+1.  We'll always have the Subversion repository for the historical record.
It'll make future mining a bit more difficult, but not insurmountably so and
I'd rather plan for the benefit of future developers than the convenience of
future archaeologists.

-Barry


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

Re: [Python-Dev] hg conversion: tags

[Dj Gilcrease]

On Wed, Sep 29, 2010 at 9:36 AM, M.-A. Lemburg  wrote:
> You don't need to spend any extra time on this: just put all the tags
> that Dirkjan wants to delete into some other place. The separation
> work has already been done by Dirkjan.
>
> Note that the reason for keeping this history around is just that:
> for historic purposes and possible future research (e.g on copyright
> issues). It's not meant for development.

Can just create a .hgtags_historic that has the full tag list so if
someone wants to do historic tag data mining they can just replace the
.hgtags to get the historic tags.


mm that gives me an idea for a HG plugin to be able to set a tag as
historic so it removes it from the .hgtags to .hgtags_historic and
some bindings to be able to use historic tags just like normal tags
(but ensure it is explicit to look in historic eg --historic)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Atlassian and bitbucket merge

[Barry Warsaw]

On Sep 28, 2010, at 09:13 PM, Steve Holden wrote:

>I see that Atlassian have just taken over BitBucket, the Mercurial
>hosting company. IIRC Atlassian offered to host our issue tracking on
>JIRA, but in the end we decided to eat our own dog food and went with
>roundup.

I was an advocate for JIRA at the time, and I think Atlassian is a fine
organization with true fans of open source, but we have made a decision to
manage our services ourselves, and I think until it's proven that we can't
keep up, we should manage our source code repository.  It's one of our most
valuable assets, if not *the* most valuable asset.

The beauty of dvcs of course is that we can have mirrors all over the place.
But I certainly feel more comfortable with the official repository on our
servers, with our admins in complete control.

Do we expect Mercurial to require more, less, or about the same amount of
babysitting as the current Subversion repository?  I would think no more and
Subversion hasn't been much of a problem.

-Barry


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

Re: [Python-Dev] Atlassian and bitbucket merge

[Dirkjan Ochtman]

On Wed, Sep 29, 2010 at 16:43, Barry Warsaw  wrote:
> Do we expect Mercurial to require more, less, or about the same amount of
> babysitting as the current Subversion repository?  I would think no more and
> Subversion hasn't been much of a problem.

Yeah, should be about the same.

Cheers,

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

Re: [Python-Dev] Atlassian and bitbucket merge

[Xavier Morel]

On 2010-09-29, at 15:26 , Tarek Ziadé wrote:
> On Wed, Sep 29, 2010 at 2:36 PM,   wrote:
>> On 01:13 am, st...@holdenweb.com wrote:
>>> I see that Atlassian have just taken over BitBucket, the Mercurial
>>> hosting company. IIRC Atlassian offered to host our issue tracking on
>>> JIRA, but in the end we decided to eat our own dog food and went with
>>> roundup.
>>> 
>>> I'm wondering if they'd be similarly interested in supporting our Hg
>>> server. Or is self-hosting the only acceptable solution? From recent
>>> mail it looks likes we may be up and running on Hg fairly soon.
>> 
>> I know of two medium sized projects (smaller than CPython) that are
>> switching away from BitBucket's free services because of their poor
>> reliability.
> 
> Me too, but I am pretty sure the reliability is going to drastically
> change in the upcoming months. If Atlassian took over this probably
> means Bitbucket will have more people to work on the project and some
> help from the Atlassian Ops. That's really a good news !

According to Atlassian's announcement of the acquisition, they've already 
gotten started on that:

>> Performance enhancements
> Bitbucket's performance has lagged due to poor infrastructure and
> lack of IT resources. Recently, Bitbucket customer repositories were
> migrated from an EC2 storage system to the Contegix data center, the
> same ISV that Atlassian uses for its hosted tools. Atlassian has hired
> a full-time IT resource to continue to improve the Bitbucket service
> to work on delivering even more services and improvements. It should
> be noted that all Bitbucket users are now covered under the Atlassian
> Terms of Use. There is heaps more work to do to provide the legendary
> service that Atlassian customers have come to expect, and we fully
> intend to live up to that promise.

>> Feature updates
> We've tripled the Bitbucket developer team to ramp up feature
> improvements and the frequency of releases. Over the next few months,
> users can expect to see more UI improvements, feature enhancements,
> and integration with Atlassian's developer stack. Even though the team
> has already tripled, we're still hiring (hint hint)!

YMMV.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Resource leaks warnings

[Brett Cannon]

On Wed, Sep 29, 2010 at 05:42, Antoine Pitrou  wrote:
>
> Le mercredi 29 septembre 2010 à 07:27 -0500, Benjamin Peterson a écrit :
>> >
>> > I would like to piggy-back on this discussion to suggest further
>> > warnings (either by default, or switchable).
>> >
>> > One feature I've often considered would be to add a warning in FileIO
>> > and socket dealloc if these objects haven't been closed explicitly. In
>> > most situations, relying on garbage collection to shutdown OS resources
>> > (here, file descriptors) is something we like to discourage.
>> > Furthermore, it can produce real bugs, especially under Windows when
>> > coupled with refererence cycles created by traceback objects (the
>> > random test_tarfile failures on the Windows buildbots were a symptom of
>> > that; their cause would have been obvious with such warnings).
>> >
>> > What do you think?
>>
>> It seems like a slippery slope. Sometimes you really don't care like
>> when you're just hacking together a quick script.
>
> Isn't the "with" statement appropriate in these cases?

Yes, which is why I suspect people saying they don't bother have been
programming Python for a while and are not in the habit yet of using a
'with' statement. The amount of extra typing compared to inlining a
call is minimal.

>
> My assumption is/was that the benefit of warning against leaks in real
> applications (or even - sigh - the standard library) would outweigh the
> inconvenience when hacking together a quick script.

Does everyone here run all their code under py-debug? If not then I
say switch it on when py-debug is on so that we at least detect the
leaks in the stdlib without having to think about it.

>
> But if it doesn't, what about enabling it with a command-line switch?

Sure, but I say always turn it on under py-debug.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Resource leaks warnings

[geremy condra]

On Wed, Sep 29, 2010 at 9:31 AM, Brett Cannon  wrote:
> On Wed, Sep 29, 2010 at 05:42, Antoine Pitrou  wrote:
>>
>> Le mercredi 29 septembre 2010 à 07:27 -0500, Benjamin Peterson a écrit :
>>> >
>>> > I would like to piggy-back on this discussion to suggest further
>>> > warnings (either by default, or switchable).
>>> >
>>> > One feature I've often considered would be to add a warning in FileIO
>>> > and socket dealloc if these objects haven't been closed explicitly. In
>>> > most situations, relying on garbage collection to shutdown OS resources
>>> > (here, file descriptors) is something we like to discourage.
>>> > Furthermore, it can produce real bugs, especially under Windows when
>>> > coupled with refererence cycles created by traceback objects (the
>>> > random test_tarfile failures on the Windows buildbots were a symptom of
>>> > that; their cause would have been obvious with such warnings).
>>> >
>>> > What do you think?
>>>
>>> It seems like a slippery slope. Sometimes you really don't care like
>>> when you're just hacking together a quick script.
>>
>> Isn't the "with" statement appropriate in these cases?
>
> Yes, which is why I suspect people saying they don't bother have been
> programming Python for a while and are not in the habit yet of using a
> 'with' statement. The amount of extra typing compared to inlining a
> call is minimal.
>
>>
>> My assumption is/was that the benefit of warning against leaks in real
>> applications (or even - sigh - the standard library) would outweigh the
>> inconvenience when hacking together a quick script.
>
> Does everyone here run all their code under py-debug? If not then I
> say switch it on when py-debug is on so that we at least detect the
> leaks in the stdlib without having to think about it.
>
>>
>> But if it doesn't, what about enabling it with a command-line switch?
>
> Sure, but I say always turn it on under py-debug.

This would be a big +1 from me.

Geremy Condra
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] r85028 - in python/branches/py3k: Doc/c-api/init.rst Include/pythonrun.h Modules/getpath.c PC/getpathp.c

[Lisandro Dalcin]

On 27 September 2010 11:57, Georg Brandl  wrote:
> Am 27.09.2010 07:32, schrieb kristjan.jonsson:
>> Author: kristjan.jonsson
>> Date: Mon Sep 27 07:32:54 2010
>> New Revision: 85028
>>
>> Log:
>> issue 9910
>> Add a Py_SetPath api to override magic path computations when starting up 
>> python.
>>
>> Modified:
>>    python/branches/py3k/Doc/c-api/init.rst
>>    python/branches/py3k/Include/pythonrun.h
>>    python/branches/py3k/Modules/getpath.c
>>    python/branches/py3k/PC/getpathp.c
>>
>> Modified: python/branches/py3k/Doc/c-api/init.rst
>
>> +.. cfunction::  void Py_SetPath(const wchar_t *)
>> +
>> +   .. index::
>> +      triple: module; search; path
>> +      single: path (in module sys)
>> +      single: Py_GetPath()
>> +
>> +   Set the default module search path.  If this function is called before
>> +   :cfunc: `Py_Initialize` then :cfunc: Py_GetPath won't attempt to compute
>> +   a default serarch path but uses the provided one in stead.  This is 
>> useful
>> +   if Python is being embedded by an application that has full knowledge
>> +   of the location of all modules.  The path components should be separated
>> +   by semicolons.
>> +
>> +   This also causes `sys.executable` to be set only to the raw program name
>> +   (see :cfunc:`Py_SetProgramName`) and `for sys.prefix` and
>> +   `sys.exec_prefix` to be empty.  It is up to the caller to modify these if
>> +   required after calling :cfunc: `Py_Initialize`.
>> +
>
> This needs a versionadded.
>
> Georg
>

Did you noticed " ... The path components should be separated by
semicolons." ? I would expect os.path.pathsep, after all paths are not
OS-independent.


-- 
Lisandro Dalcin
---
CIMEC (INTEC/CONICET-UNL)
Predio CONICET-Santa Fe
Colectora RN 168 Km 472, Paraje El Pozo
Tel: +54-342-4511594 (ext 1011)
Tel/Fax: +54-342-4511169
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] We should be using a tool for code reviews

[Guido van Rossum]

I would like to recommend that the Python core developers start using
a code review tool such as Rietveld or Reviewboard. I don't really
care which tool we use (I'm sure there are plenty of pros and cons to
each) but I do think we should get out of the stone age and start
using a tool for the majority of our code reviews.

While I would personally love to see Rietveld declared the official
core Python code review tool, I realize that since I wrote as a Google
engineer and it is running on Google infrastructure (App Engine), I
can't be fully objective about the tool choice -- even though it is
open source, has several non-Googler maintainers, and can be run
outside App Engine as well.

But I do think that using a specialized code review tool rather than
unstructured email plus a general-purpose issue tracker can hugely
improve developer performance and also increase community
participation. (A code review tool makes it much more convenient for a
senior reviewer to impart their wisdom to a junior developer without
appearing judgmental or overbearing.)

See also this buzz thread:
http://www.google.com/buzz/115212051037621986145/At6Rj82Kret/When-will-the-Python-dev-community-start-using

-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] We should be using a tool for code reviews

[Antoine Pitrou]

On Wed, 29 Sep 2010 11:32:19 -0700
Guido van Rossum  wrote:
> I would like to recommend that the Python core developers start using
> a code review tool such as Rietveld or Reviewboard. I don't really
> care which tool we use (I'm sure there are plenty of pros and cons to
> each) but I do think we should get out of the stone age and start
> using a tool for the majority of our code reviews.

He, several of us would like it too (although for short patches it
doesn't really make a difference), but what's missing is some kind of
Roundup integration. Something as trivial as a "start review" button in
front of every uploaded patch file would do the trick; it has been
suggested several times already, but what's needed is someone to write
the code :)

Regards

Antoine.


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

Re: [Python-Dev] We should be using a tool for code reviews

[Brett Cannon]

On Wed, Sep 29, 2010 at 11:41, Antoine Pitrou  wrote:
> On Wed, 29 Sep 2010 11:32:19 -0700
> Guido van Rossum  wrote:
>> I would like to recommend that the Python core developers start using
>> a code review tool such as Rietveld or Reviewboard. I don't really
>> care which tool we use (I'm sure there are plenty of pros and cons to
>> each) but I do think we should get out of the stone age and start
>> using a tool for the majority of our code reviews.
>
> He, several of us would like it too (although for short patches it
> doesn't really make a difference), but what's missing is some kind of
> Roundup integration. Something as trivial as a "start review" button in
> front of every uploaded patch file would do the trick; it has been
> suggested several times already, but what's needed is someone to write
> the code :)

The other option (as discussed on Buzz) is to add Rietveld's upload.py
to Misc/ and tell people to use that to submit the patch. Then we
simply say to the person submitting the patch, "upload it to Rietveld
and paste in the link" or simply require it upfront to encourage
people to do the upload in the first place. This would let usage to
move forward until we get that "start review" button (wasn't Ezio
looking into it?).
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] We should be using a tool for code reviews

[Guido van Rossum]

On Wed, Sep 29, 2010 at 11:41 AM, Antoine Pitrou  wrote:
> On Wed, 29 Sep 2010 11:32:19 -0700
> Guido van Rossum  wrote:
>> I would like to recommend that the Python core developers start using
>> a code review tool such as Rietveld or Reviewboard. I don't really
>> care which tool we use (I'm sure there are plenty of pros and cons to
>> each) but I do think we should get out of the stone age and start
>> using a tool for the majority of our code reviews.
>
> He, several of us would like it too (although for short patches it
> doesn't really make a difference), but what's missing is some kind of
> Roundup integration. Something as trivial as a "start review" button in
> front of every uploaded patch file would do the trick; it has been
> suggested several times already, but what's needed is someone to write
> the code :)

As I tried to explain in the Buzz thread (not that I require you to
read it -- I'll happily repeat myself here):

Unfortunately taking the average patch posted to the tracker and
importing it in Rietveld is very iffy -- it's very hard to find the
right branch+rev needed to be able to apply the patch correctly -- not
to mention that there are so many (slightly) different patch formats.
It would take a fair bit of AI to get this right.

The recommended way to work with Rietveld is to use a checkout
(fortunately with Hg this will become easier to do) and use the
"upload.py" script that you can download from Rietveld (log in and
click on the Create link).

Other projects that have adopted Rietveld (Chromum, GWT, Go) require
its use for all reviews and have written their own scripts extending
upload.py to implement the workflow they like (each one a bit
different). They've also created their own branded Rietveld sites
(which is easy to do using App Engine).

-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] We should be using a tool for code reviews

[Daniel Stutzbach]

On Wed, Sep 29, 2010 at 1:41 PM, Antoine Pitrou  wrote:

> He, several of us would like it too (although for short patches it
> doesn't really make a difference), but what's missing is some kind of
> Roundup integration. Something as trivial as a "start review" button in
> front of every uploaded patch file would do the trick; it has been
> suggested several times already, but what's needed is someone to write
> the code :)
>

Most patches won't import cleanly into Rietveld, because the patch typical
does not contain precise information about the base revision for the patch.

How about the opposite approach: make a Python-specific version of upload.py
that lets the user attach the patch to an issue with an optional message?

-- 
Daniel Stutzbach, Ph.D.
President, Stutzbach Enterprises, LLC 
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] We should be using a tool for code reviews

[Guido van Rossum]

On Wed, Sep 29, 2010 at 11:47 AM, Brett Cannon  wrote:
> On Wed, Sep 29, 2010 at 11:41, Antoine Pitrou  wrote:
>> On Wed, 29 Sep 2010 11:32:19 -0700
>> Guido van Rossum  wrote:
>>> I would like to recommend that the Python core developers start using
>>> a code review tool such as Rietveld or Reviewboard. I don't really
>>> care which tool we use (I'm sure there are plenty of pros and cons to
>>> each) but I do think we should get out of the stone age and start
>>> using a tool for the majority of our code reviews.
>>
>> He, several of us would like it too (although for short patches it
>> doesn't really make a difference), but what's missing is some kind of
>> Roundup integration. Something as trivial as a "start review" button in
>> front of every uploaded patch file would do the trick; it has been
>> suggested several times already, but what's needed is someone to write
>> the code :)
>
> The other option (as discussed on Buzz) is to add Rietveld's upload.py
> to Misc/

A problem with that is that we regularly make matching improvements to
upload.py and the server-side code it talks to. While we tend to be
conservative in these changes (because we don't control what version
of upload.py people use) it would be a pain to maintain backwards
compatibility with a version that was distributed in Misc/ two years
ago -- that's kind of outside our horizon.

Maybe the upload.py script distributed could just download the most
current version from codereview.appspot.com/static/upload.py -- that
URL is easy enough to keep stable.

> and tell people to use that to submit the patch. Then we
> simply say to the person submitting the patch, "upload it to Rietveld
> and paste in the link" or simply require it upfront to encourage
> people to do the upload in the first place. This would let usage to
> move forward until we get that "start review" button (wasn't Ezio
> looking into it?).

Yeah, but it would still not work if they are working in an unpacked
tarball -- upload.py requires that you have a VCS checkout of some
sort (though it supports SVN, Hg, Git and Bzr).

-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] We should be using a tool for code reviews

[Antoine Pitrou]

Guido, Brett,

On Wed, 29 Sep 2010 11:47:51 -0700
Brett Cannon  wrote:
> 
> The other option (as discussed on Buzz) is to add Rietveld's upload.py
> to Misc/ and tell people to use that to submit the patch.

It sounds like a good option (or, even better, a customized version as
suggested by Daniel).

> Then we
> simply say to the person submitting the patch, "upload it to Rietveld
> and paste in the link" or simply require it upfront to encourage
> people to do the upload in the first place.

We shouldn't require it. Some people don't have a Google account
(and/or don't want to have one). Also sometimes posting on Rietveld is
overkill (patches less than 30 lines long fall in this category, as far
as I'm concerned).

> This would let usage to
> move forward until we get that "start review" button (wasn't Ezio
> looking into it?).

Yes, I think Ezio was looking into it, but working on the tracker
apparently has a tendency to burn out developers rather quickly :-/
(first Ajaksu, now Ezio)

Regards

Antoine.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] We should be using a tool for code reviews

[Barry Warsaw]

On Sep 29, 2010, at 11:32 AM, Guido van Rossum wrote:

>I would like to recommend that the Python core developers start using
>a code review tool such as Rietveld or Reviewboard. I don't really
>care which tool we use (I'm sure there are plenty of pros and cons to
>each) but I do think we should get out of the stone age and start
>using a tool for the majority of our code reviews.

I like and have used Rietveld, both as a submitter of a patch and as a
reviewer of someone else's code.  It's very nice, and I think we should use it
where appropriate, I don't think it should be a requirement.

While it will be somewhat better integrated into our normal development
processes whenever we move to Mercurial, it won't be seamless.  I don't
particularly like having to run a separate script (upload.py IIRC) in order to
initiate a review and push updates.  One thing I really like about Launchpad's
merge proposals is that it's very well integrated into normal workflows.
Updates against the target branch are automatically tracked in the generated
diff and in fact, once a merge proposal has been accepted, it can be
automatically landed by a 'bot if you want.

Launchpad's merge proposal system doesn't have the really nice web-based ui
that Rietveld has, but it is well integrated with an email-based workflow.
When I see a merge proposal come into my inbox, with the diff against the
target branch, I can just reply with my review inline right there, and those
comments are visible to all subscribers.  It lowers the barrier to performing
the review immensely.  Web is nice and should be available, but I really do
not want to give up on email-based reviews (well, with Python give up on the
possibility of them).

Someone else mentioned that it should better integrate with Roundup, and I
agree with that.

I would much rather we concentrate on converting over to Mercurial as soon as
possible, since I think a dvcs will do more to improve our processes than
anything else at this point.  Please, please, please, let's not let it wait
until Pycon 2011 (*2 years* after pronouncement) [1].

-Barry

[1] Apologies for sounding critical of any individual - that's not my intent.
Dirkjan and folks have done a lot of great work to this point and ISTM that
we're *really* close.  Let's JFDI and work out remaining kinks as we go!


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

Re: [Python-Dev] We should be using a tool for code reviews

[skip]

Guido> I would like to recommend that the Python core developers start
Guido> using a code review tool ...

+1

I've suggested that something like Rietveld be integrated with our Roundup
instance in the past.  I suspect there is an open tracker case.  Martin will
be better able to find it than me.  I became a convert watching the Unladen
Swallow folks use it.

Skip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Question on bz2 codec. Is this a bug?

[Chris Bergstresser]

Hi all --

   I looked through the bug tracker, but I didn't see this listed.  I
was trying to use the bz2 codec, but it seems like it's not very
useful in the current form (and I'm not sure if it's getting added
back to py3k, so maybe this is a moot point).  It looks like the codec
writes every piece of data fed to it as a separate compressed block.
This results in compressed files which are significantly larger than
the uncompressed files, if you're writing a lot of small bursts of
data.  It also leads to interesing oddities like this:

import codecs

with codecs.open('text.bz2', 'w', 'bz2') as f:
for x in xrange(20):
f.write('This is data %i\n' % x)

with codecs.open('text.bz2', 'r', 'bz2') as f:
print f.read()

This prints "This is data 0" and exits, because the codec won't read
beyond the first compressed block.

My question is, is this known, intended behavior?  Should I open a bug
report?  Is it going away in py3k, so there's no real point in fixing
it?

-- Chris
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] We should be using a tool for code reviews

[Brett Cannon]

On Wed, Sep 29, 2010 at 12:03, Guido van Rossum  wrote:
> On Wed, Sep 29, 2010 at 11:47 AM, Brett Cannon  wrote:
>> On Wed, Sep 29, 2010 at 11:41, Antoine Pitrou  wrote:
>>> On Wed, 29 Sep 2010 11:32:19 -0700
>>> Guido van Rossum  wrote:
 I would like to recommend that the Python core developers start using
 a code review tool such as Rietveld or Reviewboard. I don't really
 care which tool we use (I'm sure there are plenty of pros and cons to
 each) but I do think we should get out of the stone age and start
 using a tool for the majority of our code reviews.
>>>
>>> He, several of us would like it too (although for short patches it
>>> doesn't really make a difference), but what's missing is some kind of
>>> Roundup integration. Something as trivial as a "start review" button in
>>> front of every uploaded patch file would do the trick; it has been
>>> suggested several times already, but what's needed is someone to write
>>> the code :)
>>
>> The other option (as discussed on Buzz) is to add Rietveld's upload.py
>> to Misc/
>
> A problem with that is that we regularly make matching improvements to
> upload.py and the server-side code it talks to. While we tend to be
> conservative in these changes (because we don't control what version
> of upload.py people use) it would be a pain to maintain backwards
> compatibility with a version that was distributed in Misc/ two years
> ago -- that's kind of outside our horizon.

Well, I would assume people are working from a checkout. Patches from
an outdated checkout simply would fail and that's fine by me.

>
> Maybe the upload.py script distributed could just download the most
> current version from codereview.appspot.com/static/upload.py -- that
> URL is easy enough to keep stable.

That's fine by me.

>
>> and tell people to use that to submit the patch. Then we
>> simply say to the person submitting the patch, "upload it to Rietveld
>> and paste in the link" or simply require it upfront to encourage
>> people to do the upload in the first place. This would let usage to
>> move forward until we get that "start review" button (wasn't Ezio
>> looking into it?).
>
> Yeah, but it would still not work if they are working in an unpacked
> tarball -- upload.py requires that you have a VCS checkout of some
> sort (though it supports SVN, Hg, Git and Bzr).

How often do we even get patches generated from a downloaded copy of
Python? Is it enough to need to worry about this?
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] We should be using a tool for code reviews

[Guido van Rossum]

On Wed, Sep 29, 2010 at 1:12 PM, Brett Cannon  wrote:
> On Wed, Sep 29, 2010 at 12:03, Guido van Rossum  wrote:
>> A problem with that is that we regularly make matching improvements to
>> upload.py and the server-side code it talks to. While we tend to be
>> conservative in these changes (because we don't control what version
>> of upload.py people use) it would be a pain to maintain backwards
>> compatibility with a version that was distributed in Misc/ two years
>> ago -- that's kind of outside our horizon.
>
> Well, I would assume people are working from a checkout. Patches from
> an outdated checkout simply would fail and that's fine by me.

Ok, but that's an extra barrier for contributions. Lots of people when
asked for a patch just modify their distro in place and you can count
yourself lucky if they send you a diff from a clean copy.

But maybe with Hg it's less of a burden to ask people to use a checkout.

> How often do we even get patches generated from a downloaded copy of
> Python? Is it enough to need to worry about this?

I used to get these frequently. I don't know what the experience of
the current crop of core developers is though, so maybe my gut
feelings here are outdated.

-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] We should be using a tool for code reviews

[Alexander Belopolsky]

On Wed, Sep 29, 2010 at 4:23 PM, Guido van Rossum  wrote:
..
> But maybe with Hg it's less of a burden to ask people to use a checkout.
>

I thought with Hg it would be more of a burden for casual contributors
to use a checkout simply because the checkout is many times bigger.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] We should be using a tool for code reviews

[Antoine Pitrou]

> > Well, I would assume people are working from a checkout. Patches from
> > an outdated checkout simply would fail and that's fine by me.
> 
> Ok, but that's an extra barrier for contributions. Lots of people when
> asked for a patch just modify their distro in place and you can count
> yourself lucky if they send you a diff from a clean copy.

Well, either they're doing a small patch and uploading to Rietveld
doesn't bring much anyway; or they're doing a large patch and it may not
apply cleanly if they do it against the stable release.

So I don't think there's a real problem here.

> I used to get these frequently. I don't know what the experience of
> the current crop of core developers is though, so maybe my gut
> feelings here are outdated.

Most patches posted on the tracker are generated either by "SVN diff" or
a DCVS equivalent (often hg).

Regards

Antoine.


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

Re: [Python-Dev] We should be using a tool for code reviews

[Guido van Rossum]

On Wed, Sep 29, 2010 at 1:31 PM, Alexander Belopolsky
 wrote:
> On Wed, Sep 29, 2010 at 4:23 PM, Guido van Rossum  wrote:
> ..
>> But maybe with Hg it's less of a burden to ask people to use a checkout.
>>
>
> I thought with Hg it would be more of a burden for casual contributors
> to use a checkout simply because the checkout is many times bigger.

Isn't it still faster though?

-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] We should be using a tool for code reviews

[Brett Cannon]

On Wed, Sep 29, 2010 at 13:23, Guido van Rossum  wrote:
> On Wed, Sep 29, 2010 at 1:12 PM, Brett Cannon  wrote:
>> On Wed, Sep 29, 2010 at 12:03, Guido van Rossum  wrote:
>>> A problem with that is that we regularly make matching improvements to
>>> upload.py and the server-side code it talks to. While we tend to be
>>> conservative in these changes (because we don't control what version
>>> of upload.py people use) it would be a pain to maintain backwards
>>> compatibility with a version that was distributed in Misc/ two years
>>> ago -- that's kind of outside our horizon.
>>
>> Well, I would assume people are working from a checkout. Patches from
>> an outdated checkout simply would fail and that's fine by me.
>
> Ok, but that's an extra barrier for contributions. Lots of people when
> asked for a patch just modify their distro in place and you can count
> yourself lucky if they send you a diff from a clean copy.
>
> But maybe with Hg it's less of a burden to ask people to use a checkout.
>
>> How often do we even get patches generated from a downloaded copy of
>> Python? Is it enough to need to worry about this?
>
> I used to get these frequently. I don't know what the experience of
> the current crop of core developers is though, so maybe my gut
> feelings here are outdated.

Well, we can start with strongly worded suggestions that patches
submitted using Rietveld will typically get priority over patches
submitted just to the issue tracker and that this means doing it from
a checkout. From there we can see if there is a drop in submissions.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] We should be using a tool for code reviews

[Antoine Pitrou]

Le mercredi 29 septembre 2010 à 13:35 -0700, Brett Cannon a écrit :
> 
> Well, we can start with strongly worded suggestions that patches
> submitted using Rietveld will typically get priority over patches
> submitted just to the issue tracker and that this means doing it from
> a checkout.

But will we (all of us) actually follow this rule?
Granted, a patch is reviewed faster if it's easier to review. But in
many cases (small patches) it doesn't really make a difference.

I have from time to time suggested that a contributor post his/her patch
to Rietveld. But that was for really large or nasty ones.

Regards

Antoine.


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

Re: [Python-Dev] We should be using a tool for code reviews

[Brett Cannon]

On Wed, Sep 29, 2010 at 13:31, Alexander Belopolsky
 wrote:
> On Wed, Sep 29, 2010 at 4:23 PM, Guido van Rossum  wrote:
> ..
>> But maybe with Hg it's less of a burden to ask people to use a checkout.
>>
>
> I thought with Hg it would be more of a burden for casual contributors
> to use a checkout simply because the checkout is many times bigger.

Many times bigger than what? If you mean svn that's not true (the eval
of the DVCS pegged Hg at only 50% larger than svn). If you mean
compared to the tar.bz2 file, then sure, but a zip of an Hg checkout
is under 50 MB which is less than 5x larger.

But honestly, the line has to be drawn somewhere. Right now we won't
take a patch submitted to the mailing list, but accepting patches not
against a checkout wastes time for everyone involved as soon as it
doesn't apply cleanly. At that point either a core developer has to
fix it or (what typically happens) the person has to get a checkout,
update their patch, and then re-submit. We might as well minimize that
when possible by really pushing for checkout patches.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] We should be using a tool for code reviews

[Guido van Rossum]

On Wed, Sep 29, 2010 at 1:43 PM, Antoine Pitrou  wrote:
> Le mercredi 29 septembre 2010 à 13:35 -0700, Brett Cannon a écrit :
>>
>> Well, we can start with strongly worded suggestions that patches
>> submitted using Rietveld will typically get priority over patches
>> submitted just to the issue tracker and that this means doing it from
>> a checkout.
>
> But will we (all of us) actually follow this rule?
> Granted, a patch is reviewed faster if it's easier to review. But in
> many cases (small patches) it doesn't really make a difference.
>
> I have from time to time suggested that a contributor post his/her patch
> to Rietveld. But that was for really large or nasty ones.

More use of the tool also increases accountability and provides more
opportunities for junior developers to learn. (And it increases
familiarity of all involved with the tool for the future.)

I agree it shouldn't be mandatory, but I would suggest you give it a
try even for small changes.

-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] We should be using a tool for code reviews

[Paul Moore]

On 29 September 2010 21:12, Brett Cannon  wrote:
> How often do we even get patches generated from a downloaded copy of
> Python? Is it enough to need to worry about this?

When I do simple bugfixes of library code, I'll often work from my
"live" Python environment, patch it in place, test and generate a
patch with diff. Very primitive, but surprisingly effective.

Having said that, I don't think it's the end of the world if such
patches couldn't use Reitveld. They are probably small enough that it
would be overkill anyway.

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

Re: [Python-Dev] We should be using a tool for code reviews

[Brett Cannon]

On Wed, Sep 29, 2010 at 13:43, Antoine Pitrou  wrote:
> Le mercredi 29 septembre 2010 à 13:35 -0700, Brett Cannon a écrit :
>>
>> Well, we can start with strongly worded suggestions that patches
>> submitted using Rietveld will typically get priority over patches
>> submitted just to the issue tracker and that this means doing it from
>> a checkout.
>
> But will we (all of us) actually follow this rule?

Does it matter? If it leads to an easier review process in some cases
and doesn't impact reviews overall in a negative way who cares.

> Granted, a patch is reviewed faster if it's easier to review. But in
> many cases (small patches) it doesn't really make a difference.

So it's a no-op in some cases, a benefit in others. I don't see the harm.

>
> I have from time to time suggested that a contributor post his/her patch
> to Rietveld. But that was for really large or nasty ones.

Same here, but that was because I didn't have an easy way to say
"submit the patch to Rietveld and add the link to the issue". If we
have it in a checkout we can easily say "please run code_review.py
from your checkout and paste the link into the issue to move the
review forward."
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Question on bz2 codec. Is this a bug?

[M.-A. Lemburg]

Chris Bergstresser wrote:
> Hi all --
> 
>I looked through the bug tracker, but I didn't see this listed.  I
> was trying to use the bz2 codec, but it seems like it's not very
> useful in the current form (and I'm not sure if it's getting added
> back to py3k, so maybe this is a moot point).  It looks like the codec
> writes every piece of data fed to it as a separate compressed block.
> This results in compressed files which are significantly larger than
> the uncompressed files, if you're writing a lot of small bursts of
> data.  It also leads to interesing oddities like this:
> 
> import codecs
> 
> with codecs.open('text.bz2', 'w', 'bz2') as f:
> for x in xrange(20):
> f.write('This is data %i\n' % x)
> 
> with codecs.open('text.bz2', 'r', 'bz2') as f:
> print f.read()
> 
> This prints "This is data 0" and exits, because the codec won't read
> beyond the first compressed block.
> 
> My question is, is this known, intended behavior?  Should I open a bug
> report?  Is it going away in py3k, so there's no real point in fixing
> it?

The codec is scheduled to be added back to Python3.

However, it's main use is in working on whole chunks of
data rather than the line-by-line approach you're after.
This is provided by the codec's incremental encoder/decoders,
but these are currently not used by codecs.open() and
I'm not sure whether the io lib uses them, which could
be used via the regular open().

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Sep 29 2010)
>>> Python/Zope Consulting and Support ...http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/


::: Try our new mxODBC.Connect Python Database Interface for free ! 


   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
   Registered at Amtsgericht Duesseldorf: HRB 46611
   http://www.egenix.com/company/contact/
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] We should be using a tool for code reviews

[Robert Kern]

On 9/29/10 3:33 PM, Guido van Rossum wrote:

On Wed, Sep 29, 2010 at 1:31 PM, Alexander Belopolsky
  wrote:

On Wed, Sep 29, 2010 at 4:23 PM, Guido van Rossum  wrote:
..

But maybe with Hg it's less of a burden to ask people to use a checkout.


I thought with Hg it would be more of a burden for casual contributors
to use a checkout simply because the checkout is many times bigger.


Isn't it still faster though?


For what it's worth, when I tried it, the relationship is reversed:

[hg]$ time hg clone http://code.python.org/hg/branches/py3k/
...
hg clone http://code.python.org/hg/branches/py3k/  24.44s user 3.43s system 10% 
cpu 4:15.48 total


[hg]$ du -hsc py3k
105Mpy3k

[svn]$ time svn co http://svn.python.org/projects/python/branches/py3k/
...
svn co http://svn.python.org/projects/python/branches/py3k/  5.03s user 7.01s 
system 12% cpu 1:35.97 total

[svn]$ du -hsc py3k
131Mpy3k


Mercurial's checkout with the whole history is actually smaller than the SVN 
checkout because it applies some very nice compression to the history whereas 
the SVN checkout has an uncompressed copy of every single file tucked away in 
its .svn/ directory.


My mercurial checkout happens to be slower, but I don't know whose fault that 
is. I'm still using Mercurial 1.5.1 on my OS X box, and while I wasn't doing 
much that would take up CPU or bandwidth, I wasn't trying especially hard to 
prevent such interference, either.


--
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
 that is made terrible by our own mad attempt to interpret it as though it had
 an underlying truth."
  -- Umberto Eco

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

Re: [Python-Dev] We should be using a tool for code reviews

[Antoine Pitrou]

On Wed, 29 Sep 2010 13:56:46 -0700
Brett Cannon  wrote:
> On Wed, Sep 29, 2010 at 13:31, Alexander Belopolsky
>  wrote:
> > On Wed, Sep 29, 2010 at 4:23 PM, Guido van Rossum  wrote:
> > ..
> >> But maybe with Hg it's less of a burden to ask people to use a checkout.
> >>
> >
> > I thought with Hg it would be more of a burden for casual contributors
> > to use a checkout simply because the checkout is many times bigger.
> 
> Many times bigger than what? If you mean svn that's not true (the eval
> of the DVCS pegged Hg at only 50% larger than svn). If you mean
> compared to the tar.bz2 file, then sure, but a zip of an Hg checkout
> is under 50 MB which is less than 5x larger.

The disk footprint is not very much larger, but I assume that the
amount of bandwidth needed for a first checkout can easily be 10x or
50x.
(then, if you keep the checkout around, pulling new revisions is very
efficient)

That said, it seems there are tools to optimize the internal structures
of an hg repository so that it takes less disk space (and therefore
less checkout bandwidth). I don't know whether Dirkjan intends to use
that.

Regards

Antoine.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] We should be using a tool for code reviews

[Alexander Belopolsky]

On Wed, Sep 29, 2010 at 4:56 PM, Brett Cannon  wrote:
> On Wed, Sep 29, 2010 at 13:31, Alexander Belopolsky
>  wrote:
>> On Wed, Sep 29, 2010 at 4:23 PM, Guido van Rossum  wrote:
>> ..
>>> But maybe with Hg it's less of a burden to ask people to use a checkout.
>>>
>>
>> I thought with Hg it would be more of a burden for casual contributors
>> to use a checkout simply because the checkout is many times bigger.
>
> Many times bigger than what? If you mean svn that's not true (the eval
> of the DVCS pegged Hg at only 50% larger than svn).

My experience was different.  I may misremember because I did not try
to use Hg since about a year ago, but the Hg checkout was 3-4x of that
of an SVN branch.   However, my comment was simply a reaction to the
argument that Hg checkout would be *less* of a burden than SVN.

>
> But honestly, the line has to be drawn somewhere. Right now we won't
> take a patch submitted to the mailing list, but accepting patches not
> against a checkout wastes time for everyone involved as soon as it
> doesn't apply cleanly. At that point either a core developer has to
> fix it or (what typically happens) the person has to get a checkout,
> update their patch, and then re-submit. We might as well minimize that
> when possible by really pushing for checkout patches.
>

Well, many patches do not apply cleanly by the time they are reviewed
even when they are originally produced from a clean checkout.   I
actually wonder if it would be appropriate to encourage *reviewers* to
upload the patches to a review tool.   A reviewer is much more likely
to have a clean checkout already than a casual contributor and
oftentimes applying the patch is the first thing reviewers do anyways.
 If a review tool is one command away, it may be even easier to run it
rather than to figure out how to reference the code in the patch in
the roundup comment.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Question on bz2 codec. Is this a bug?

[Antoine Pitrou]

On Wed, 29 Sep 2010 23:05:38 +0200
"M.-A. Lemburg"  wrote:
> 
> The codec is scheduled to be added back to Python3.
> 
> However, it's main use is in working on whole chunks of
> data rather than the line-by-line approach you're after.
> This is provided by the codec's incremental encoder/decoders,
> but these are currently not used by codecs.open() and
> I'm not sure whether the io lib uses them, which could
> be used via the regular open().

The io lib will not work with a codec which doesn't return unicode
strings.

Anyway, the obvious way to write line-by-line to a bz2 file is to use
the BZ2File class!

Regards

Antoine.


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

Re: [Python-Dev] Atlassian and bitbucket merge

[Martin v. Löwis]

> Do we expect Mercurial to require more, less, or about the same amount of
> babysitting as the current Subversion repository? 

The ongoing effort is to manage write access; this is not going to
change with Mercurial.

With a hosted service, you still need someone who gives write
permissions to people. What you gain is not having to deal with
lost credentials (forgotten passwords, new SSH keys). We *could*
of course setup a web-based user management on python.org as
well so committers can upload their SSH keys over the web, however,
the current approach has not produced much problems.

For Mercurial (or any other VCS), there is also an upfront effort
to setup the system, which is primarily data conversion and hooks.
Expect increased activity in creating hooks for one year after
the switchover.

Of course, with a hosted service, you often can't run hooks at all,
so the effort to write them is also reduced :-)

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

Re: [Python-Dev] Resource leaks warnings

[Nick Coghlan]

On Wed, Sep 29, 2010 at 11:40 PM, Barry Warsaw  wrote:
> I don't think it should be in the gc module, but I would prefer it be enabled
> and controlled through a separate module, rather than something Python does
> automatically for your convenience.

The os module would seem to be the place to enable/disable tracking of
OS level resource leaks (i.e. file descriptors and possible HANDLES on
Windows).

I'm not sure how practical this idea will prove to implement though.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] r85028 - in python/branches/py3k: Doc/c-api/init.rst Include/pythonrun.h Modules/getpath.c PC/getpathp.c

[Nick Coghlan]

On Thu, Sep 30, 2010 at 3:43 AM, Lisandro Dalcin  wrote:
> Did you noticed " ... The path components should be separated by
> semicolons." ? I would expect os.path.pathsep, after all paths are not
> OS-independent.

That's true when reading from PYTHONPATH. For a programmatic API like
this, being consistent is probably simpler in most cases.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] We should be using a tool for code reviews

[Barry Warsaw]

One other thought: IME patches in general are suboptimal to branches, so I
think we should be encouraging people to publish their branches publicly for
review.  A diff is a decent way to get feedback about code changes, but that's
often only part of the work involved in deciding whether a change should be
accepted or not.  A reviewer often wants to do a build with the changes, test
them on various tasks and application, run the test suite, etc.  For this,
"merge" is much better than patch(1).

-Barry


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

Re: [Python-Dev] We should be using a tool for code reviews

[Martin v. Löwis]

> While I would personally love to see Rietveld declared the official
> core Python code review tool, I realize that since I wrote as a Google
> engineer and it is running on Google infrastructure (App Engine), I
> can't be fully objective about the tool choice -- even though it is
> open source, has several non-Googler maintainers, and can be run
> outside App Engine as well.

I considered having roundup post all patches to Rietveld (trust me
that I can solve the "what branch and revision problem").

However, the stumbling block is access control - I don't know how
to get roundup to post to Rietveld, "anonymously", so to speak.

So perhaps we should just run our own Rietveld instance next to Roundup.

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

Re: [Python-Dev] Question on bz2 codec. Is this a bug?

[Chris Bergstresser]

On Wed, Sep 29, 2010 at 5:23 PM, Antoine Pitrou  wrote:
> Anyway, the obvious way to write line-by-line to a bz2 file is to use
> the BZ2File class!

   The BZ2File class does not allow you to open a file for appending.
   Using the incremental encoder does work, which leads to the obvious
question of why the codecs.open() method doesn't use the incremental
method by default, at least in this case.

-- Chris
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Atlassian and bitbucket merge

[Daniel Stutzbach]

On Wed, Sep 29, 2010 at 4:25 PM, "Martin v. Löwis" wrote:

> Of course, with a hosted service, you often can't run hooks at all,
> so the effort to write them is also reduced :-)
>

It should be easy to write an automated script that pulls the latest changes
from the hosted service and then runs hooks.  Obviously, it would not be
possible to write hooks that reject changesets, but it would be possible to
write hooks that send email or notify buildbots.

-- 
Daniel Stutzbach, Ph.D.
President, Stutzbach Enterprises, LLC 
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-checkins] r85101 - in python/branches/py3k/Doc/library: http.client.rst urllib.request.rst

[Eric Smith]

On 9/29/2010 7:24 AM, antoine.pitrou wrote:


Modified: python/branches/py3k/Doc/library/urllib.request.rst
==
--- python/branches/py3k/Doc/library/urllib.request.rst (original)
+++ python/branches/py3k/Doc/library/urllib.request.rst Wed Sep 29 13:24:21 2010
@@ -11,6 +11,10 @@
  opening URLs (mostly HTTP) in a complex world --- basic and digest
  authentication, redirections, cookies and more.

+.. warning:: When opening HTTPS (or FTPS) URLs, it is not attempted to
+   validate the server certificate.  Use at your own risk!
+
+
  The :mod:`urllib.request` module defines the following functions:


That wording is a little awkward. How about: "When opening HTTPS (or 
FTPS) URLs, no attempt is made to validate the server certificate. Use 
at your own risk."

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

Re: [Python-Dev] We should be using a tool for code reviews

[Nick Coghlan]

On Thu, Sep 30, 2010 at 4:47 AM, Brett Cannon  wrote:
> On Wed, Sep 29, 2010 at 11:41, Antoine Pitrou  wrote:
>> On Wed, 29 Sep 2010 11:32:19 -0700
>> Guido van Rossum  wrote:
>>> I would like to recommend that the Python core developers start using
>>> a code review tool such as Rietveld or Reviewboard. I don't really
>>> care which tool we use (I'm sure there are plenty of pros and cons to
>>> each) but I do think we should get out of the stone age and start
>>> using a tool for the majority of our code reviews.

Somewhat amusing to get to this thread a few minutes after creating a
Reitveld issue for the first pass of my urllib.parse patch :)

>> He, several of us would like it too (although for short patches it
>> doesn't really make a difference), but what's missing is some kind of
>> Roundup integration. Something as trivial as a "start review" button in
>> front of every uploaded patch file would do the trick; it has been
>> suggested several times already, but what's needed is someone to write
>> the code :)
>
> The other option (as discussed on Buzz) is to add Rietveld's upload.py
> to Misc/ and tell people to use that to submit the patch. Then we
> simply say to the person submitting the patch, "upload it to Rietveld
> and paste in the link" or simply require it upfront to encourage
> people to do the upload in the first place. This would let usage to
> move forward until we get that "start review" button (wasn't Ezio
> looking into it?).

Make our script a "submit_patch.py" wrapper around the vanilla
"upload.py" rather than a replacement of it and it sounds like a good
idea to me. I'd want to be able to do a signature check on upload.py
before we enabled runtime downloading of new versions from the
codereview site though (in the meantime, a vetted version checked into
SVN would do the trick).

Even with Roundup integration, being able to create/update the
Reitveld issue and make the appropriate tracker updates with a single
command would still be handy.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] We should be using a tool for code reviews

[Brett Cannon]

On Wed, Sep 29, 2010 at 14:35, "Martin v. Löwis"  wrote:
>> While I would personally love to see Rietveld declared the official
>> core Python code review tool, I realize that since I wrote as a Google
>> engineer and it is running on Google infrastructure (App Engine), I
>> can't be fully objective about the tool choice -- even though it is
>> open source, has several non-Googler maintainers, and can be run
>> outside App Engine as well.
>
> I considered having roundup post all patches to Rietveld (trust me
> that I can solve the "what branch and revision problem").
>
> However, the stumbling block is access control - I don't know how
> to get roundup to post to Rietveld, "anonymously", so to speak.
>
> So perhaps we should just run our own Rietveld instance next to Roundup.

That shouldn't be too hard. Someone just has to create an App Engine
project and handle the deployment. I guess the trickiest part is
making sure enough people have admin access so multiple people can
update the website, especially if we run a modified copy so that
bugs.python.org can push "anonymous" (and probably be the only thing
that can).
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] We should be using a tool for code reviews

[Barry Warsaw]

On Sep 29, 2010, at 05:22 PM, Alexander Belopolsky wrote:

>> Many times bigger than what? If you mean svn that's not true (the
>> eval of the DVCS pegged Hg at only 50% larger than svn).
>
>My experience was different.  I may misremember because I did not try
>to use Hg since about a year ago, but the Hg checkout was 3-4x of that
>of an SVN branch.   However, my comment was simply a reaction to the
>argument that Hg checkout would be *less* of a burden than SVN.

With Bazaar, if you're a frequent contributor to a project, you can amortize
the expensive initial checkout across all the branches you'll ever make.  The
first branch may take a while, but subsequent ones are very fast.  I'd be
surprised if Mercurial didn't have at least something similar.

It's true though that for drive-by contributors who rarely develop a patch,
generating a branch may be too high a barrier.  In that case, I think it's
fine to have diffs (which a more experienced developer can turn into a
branch).

>> But honestly, the line has to be drawn somewhere. Right now we won't
>> take a patch submitted to the mailing list, but accepting patches not
>> against a checkout wastes time for everyone involved as soon as it
>> doesn't apply cleanly. At that point either a core developer has to
>> fix it or (what typically happens) the person has to get a checkout,
>> update their patch, and then re-submit. We might as well minimize
>> that when possible by really pushing for checkout patches.
>>
>
>Well, many patches do not apply cleanly by the time they are reviewed
>even when they are originally produced from a clean checkout.   I
>actually wonder if it would be appropriate to encourage *reviewers* to
>upload the patches to a review tool.   A reviewer is much more likely
>to have a clean checkout already than a casual contributor and
>oftentimes applying the patch is the first thing reviewers do anyways.
> If a review tool is one command away, it may be even easier to run it
>rather than to figure out how to reference the code in the patch in
>the roundup comment.

While branches are far better than patches here, you can still have conflicts
when merging the branch to the trunk (which I recommend doing when reviewing a
branch).  I have no problem halting a review right there and asking the
developer to ensure a conflict-free merge.

It's of course at the reviewer's discretion to assist them with this (e.g. by
branching their branch, resolving the conflicts, committing and publishing
this clean branch, for the original developer to merge into *their* branch
before requesting a re-review -- see why branches are so much better?! :).

-Barry


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

Re: [Python-Dev] We should be using a tool for code reviews

[Martin v. Löwis]

> That shouldn't be too hard. Someone just has to create an App Engine
> project and handle the deployment. I guess the trickiest part is
> making sure enough people have admin access so multiple people can
> update the website, especially if we run a modified copy so that
> bugs.python.org can push "anonymous" (and probably be the only thing
> that can).

I was hoping that I can run Rietveld on the same machine as roundup,
with the added advantage that people can use the same logins, and
even the same cookies.

Of course, we could do an OpenID-style indirect communication,
referring people to Roundup when they need to be authenticated to
Rietveld (in particular when commenting).

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

Re: [Python-Dev] We should be using a tool for code reviews

[Nick Coghlan]

On Thu, Sep 30, 2010 at 7:35 AM, "Martin v. Löwis"  wrote:
>> While I would personally love to see Rietveld declared the official
>> core Python code review tool, I realize that since I wrote as a Google
>> engineer and it is running on Google infrastructure (App Engine), I
>> can't be fully objective about the tool choice -- even though it is
>> open source, has several non-Googler maintainers, and can be run
>> outside App Engine as well.
>
> I considered having roundup post all patches to Rietveld (trust me
> that I can solve the "what branch and revision problem").
>
> However, the stumbling block is access control - I don't know how
> to get roundup to post to Rietveld, "anonymously", so to speak.
>
> So perhaps we should just run our own Rietveld instance next to Roundup.

Would it be possible to sync up the reitveld issue numbers with the
roundup ones if you did that? Or would the fact that a single issue
can have multiple attached patches prevent that?

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Question on bz2 codec. Is this a bug?

[Antoine Pitrou]

Le mercredi 29 septembre 2010 à 17:41 -0400, Chris Bergstresser a
écrit :
> On Wed, Sep 29, 2010 at 5:23 PM, Antoine Pitrou  wrote:
> > Anyway, the obvious way to write line-by-line to a bz2 file is to use
> > the BZ2File class!
> 
>The BZ2File class does not allow you to open a file for appending.
>Using the incremental encoder does work,

In what sense? Do you mean it adds a new bz2 stream at the end of the
existing file?


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

Re: [Python-Dev] We should be using a tool for code reviews

[Benjamin Peterson]

2010/9/29 Guido van Rossum :
> On Wed, Sep 29, 2010 at 1:12 PM, Brett Cannon  wrote:
>> How often do we even get patches generated from a downloaded copy of
>> Python? Is it enough to need to worry about this?
>
> I used to get these frequently. I don't know what the experience of
> the current crop of core developers is though, so maybe my gut
> feelings here are outdated.

FWIW, I usually don't apply patches until the last stages of review
(namely I'm going to apply it). So, it's a little annoying to download
and apply a patch just to run upload.py. I'd prefer a pure web
interface for starting reviews with a code review tool.



-- 
Regards,
Benjamin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] We should be using a tool for code reviews

[Martin v. Löwis]

>> So perhaps we should just run our own Rietveld instance next to Roundup.
> 
> Would it be possible to sync up the reitveld issue numbers with the
> roundup ones if you did that?

Most certainly. However, this works fairly well today already. If you
put [issue] into the Rietveld subject, it can already synchronize
with roundup (even though it would use different issue numbers).

For a local copy of Rietveld, I could certainly arrange it to use the
very same numbers.

> Or would the fact that a single issue
> can have multiple attached patches prevent that?

No, Rietveld can deal with multiple patch sets fine (not sure how it
fares when they are unrelated patches, since it also computes deltas
between subsets - but apparently only for the same files).

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

Re: [Python-Dev] We should be using a tool for code reviews

[Antoine Pitrou]

On Wed, 29 Sep 2010 17:30:10 -0400
Barry Warsaw  wrote:
> One other thought: IME patches in general are suboptimal to branches, so I
> think we should be encouraging people to publish their branches publicly for
> review.  A diff is a decent way to get feedback about code changes, but that's
> often only part of the work involved in deciding whether a change should be
> accepted or not.  A reviewer often wants to do a build with the changes, test
> them on various tasks and application, run the test suite, etc.  For this,
> "merge" is much better than patch(1).

When I review a patch, I will tend to assume that the poster has
already run the test suite (especially if it's another committer).
Having to checkout a branch and generate a diff myself would make it
much longer to produce a review, in most cases.

Even rebuilding a new branch from scratch can be slower than applying
the diff in an existing checkout and letting `make` rebuild a couple of
files.

Regards

Antoine.


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

Re: [Python-Dev] We should be using a tool for code reviews

[Brett Cannon]

On Wed, Sep 29, 2010 at 14:58, "Martin v. Löwis"  wrote:
>> That shouldn't be too hard. Someone just has to create an App Engine
>> project and handle the deployment. I guess the trickiest part is
>> making sure enough people have admin access so multiple people can
>> update the website, especially if we run a modified copy so that
>> bugs.python.org can push "anonymous" (and probably be the only thing
>> that can).
>
> I was hoping that I can run Rietveld on the same machine as roundup,
> with the added advantage that people can use the same logins, and
> even the same cookies.

If it can work that sure then great. I just don't know what it takes
to run Rietveld sans App Engine.

-Brett

>
> Of course, we could do an OpenID-style indirect communication,
> referring people to Roundup when they need to be authenticated to
> Rietveld (in particular when commenting).
>
> Regards,
> Martin
>
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] We should be using a tool for code reviews

[Antoine Pitrou]

On Wed, 29 Sep 2010 23:58:05 +0200
"Martin v. Löwis"  wrote:
> > That shouldn't be too hard. Someone just has to create an App Engine
> > project and handle the deployment. I guess the trickiest part is
> > making sure enough people have admin access so multiple people can
> > update the website, especially if we run a modified copy so that
> > bugs.python.org can push "anonymous" (and probably be the only thing
> > that can).
> 
> I was hoping that I can run Rietveld on the same machine as roundup,
> with the added advantage that people can use the same logins, and
> even the same cookies.

That would be very nice.
Aren't there some App Engine emulation layers? Or are they only for
development?


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

Re: [Python-Dev] Atlassian and bitbucket merge

[Fred Drake]

On Wed, Sep 29, 2010 at 5:41 PM, Daniel Stutzbach
 wrote:
> Obviously, it would not be possible to write hooks that reject changesets

Of course, this is one of the more interesting ways to use hooks.

Since there's no current expectation that running our own will be a
problem, why don't we convert and see how it goes?  If we discover
problems doing so and think a hosted solution would solve them, we can
reconsider then.


  -Fred

--
Fred L. Drake, Jr.    
"A storm broke loose in my mind."  --Albert Einstein
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] hg conversion: tags

[Martin v. Löwis]

> I don't know how hg manages this, but can't we preserve the tag
> information of the tags that you've scheduled to be removed
> in some place that can easily be pulled in but doesn't
> affect the main repo size ?

Most certainly, and this is the plan already: we will keep the
subversion repository data "forever".

If you want the CVS repository from the day when it was converted
to subversion, you can still get it from

http://svn.python.org/snapshots/python-cvsroot-final.tar.bz2

(Created 27-Oct-2005 04:34, FWIW, so we are close to 5 years
into subversion usage. Given that the "public" usage of the CVS
started in 2000, we should start to look into the hg successor
around 2013, for a switchover in Oktober 2015 :-).

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

Re: [Python-Dev] We should be using a tool for code reviews

[Fred Drake]

On Wed, Sep 29, 2010 at 5:57 PM, Nick Coghlan  wrote:
> Would it be possible to sync up the reitveld issue numbers with the
> roundup ones if you did that? Or would the fact that a single issue
> can have multiple attached patches prevent that?

Another quirk would be that often several pieces are uploaded which
really constitute a single change; often docs and/or tests are
provided separately, just because we've had to go back and ask for
them.  Sometimes they're provided by a separate contributor.

Keeping the numbers aligned could probably be done based on the file
number containing the patch, assuming those are never reused (I don't
think they are, but haven't dug deep enough into roundup).


  -Fred

--
Fred L. Drake, Jr.    
"A storm broke loose in my mind."  --Albert Einstein
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] We should be using a tool for code reviews

[Barry Warsaw]

On Sep 30, 2010, at 12:04 AM, Antoine Pitrou wrote:

>On Wed, 29 Sep 2010 17:30:10 -0400
>Barry Warsaw  wrote:
>> One other thought: IME patches in general are suboptimal to
>> branches, so I think we should be encouraging people to publish
>> their branches publicly for review.  A diff is a decent way to get
>> feedback about code changes, but that's often only part of the work
>> involved in deciding whether a change should be accepted or not.  A
>> reviewer often wants to do a build with the changes, test them on
>> various tasks and application, run the test suite, etc.  For this,
>> "merge" is much better than patch(1).
>
>When I review a patch, I will tend to assume that the poster has
>already run the test suite (especially if it's another committer).
>Having to checkout a branch and generate a diff myself would make it
>much longer to produce a review, in most cases.

Yep, it depends on who is submitting the branch, what the branch changes,
etc.

>Even rebuilding a new branch from scratch can be slower than applying
>the diff in an existing checkout and letting `make` rebuild a couple of
>files.

You can have "co-located" branches[1] which essentially switch in-place, so if
a branch is changing some .c files, you won't have to rebuild the whole world
just to try out a patch.

-Barry

[1] I only have experience with these in Bazaar so Mercurial's might work
differently or be called something different.


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

Re: [Python-Dev] We should be using a tool for code reviews

[Guido van Rossum]

On Wed, Sep 29, 2010 at 3:12 PM, Antoine Pitrou  wrote:
> On Wed, 29 Sep 2010 23:58:05 +0200
> "Martin v. Löwis"  wrote:
>> > That shouldn't be too hard. Someone just has to create an App Engine
>> > project and handle the deployment. I guess the trickiest part is
>> > making sure enough people have admin access so multiple people can
>> > update the website, especially if we run a modified copy so that
>> > bugs.python.org can push "anonymous" (and probably be the only thing
>> > that can).
>>
>> I was hoping that I can run Rietveld on the same machine as roundup,
>> with the added advantage that people can use the same logins, and
>> even the same cookies.
>
> That would be very nice.
> Aren't there some App Engine emulation layers? Or are they only for
> development?

Yes, http://code.google.com/p/django-gae2django/ (see also
http://code.google.com/appengine/articles/pure_django.html)

-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] We should be using a tool for code reviews

[Martin v. Löwis]

Am 30.09.2010 00:12, schrieb Antoine Pitrou:
> On Wed, 29 Sep 2010 23:58:05 +0200
> "Martin v. Löwis"  wrote:
>>> That shouldn't be too hard. Someone just has to create an App Engine
>>> project and handle the deployment. I guess the trickiest part is
>>> making sure enough people have admin access so multiple people can
>>> update the website, especially if we run a modified copy so that
>>> bugs.python.org can push "anonymous" (and probably be the only thing
>>> that can).
>>
>> I was hoping that I can run Rietveld on the same machine as roundup,
>> with the added advantage that people can use the same logins, and
>> even the same cookies.
> 
> That would be very nice.
> Aren't there some App Engine emulation layers? Or are they only for
> development?

There is dev_appserver.py, but it is indeed only for development.
However, there is also gae2django, which I'm going to try.

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

Re: [Python-Dev] Question on bz2 codec. Is this a bug?

[Chris Bergstresser]

On Wed, Sep 29, 2010 at 5:59 PM, Antoine Pitrou  wrote:
> Le mercredi 29 septembre 2010 à 17:41 -0400, Chris Bergstresser a
> écrit :
>> On Wed, Sep 29, 2010 at 5:23 PM, Antoine Pitrou  wrote:
>> > Anyway, the obvious way to write line-by-line to a bz2 file is to use
>> > the BZ2File class!
>>
>>    The BZ2File class does not allow you to open a file for appending.
>>    Using the incremental encoder does work,
>
> In what sense? Do you mean it adds a new bz2 stream at the end of the
> existing file?

   Yes.  If you open an existing bz2 file for appending and use the
incremental encoder to encode the data you write to it, you end up
with a single file containing two separate bz2 compressed blocks of
data.  The bunzip2 program handles multiple streams in a single file
correctly, and there's a bug open (complete with working patch) in the
Python tracker to handle them as well.

-- Chris
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] distutils and distutils2 bugs (Was: Re: Goodbye)

[Éric Araujo]

Le 23/09/2010 22:51, Éric Araujo a écrit :
> Le 23/09/2010 19:22, Terry Reedy a écrit :
>> As of just now, if you were to wonder "What (security) bugs are open for 
>> 2.5" and search on open 2.5 issues, you would get a list of 44 issues. 
>> [...] It it 44 instead of perhaps 5 because Tarek
>> and Eric insist on marking all disutils2 issues for all versions even 
>> though though these issues have nothing to do with maintenance releases. 
>> It is a real nuisance when trying to do tracker cleanup.
> 
> Let’s fix this.  [...]
> 
> In short, setting versions other than “3rd party” for distutils2 bugs
> does not help distutils2 and raises unhelpful results for people
> querying the status of CPython releases.  +1 on changing that.

There has been no further feedback after Georg (thanks Georg), so I went
ahead and set “3rd party” for distutils2 bugs instead of 2.5-3.2, for
all the aforementioned reasons.  Bugs applying to distutils and
distutils2 have versions 2.7, 3.1, 3.2, 3rd party so that the
forward-port is not forgotten.

If you commit a change to distutils, sysconfig or pkgutil, it’s fine to
assign the forward-port to me or, if you can use Mercurial, to publish a
changeset somewhere and request a pull/import.

(Those versions changes sent a lot of email, but this had to be done.
Sorry for the inconvenience.)

Thanks again to Terry and Mark for their triage work.  Hope this helps!

Kind regards
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] API for binary operations on Sets

[Raymond Hettinger]

I would like to solicit this group's thoughts on how to reconcile the Set 
abstract base class with the API for built-in set objects (see 
http://bugs.python.org/issue8743 ).  I've been thinking about this issue for a 
good while and the RightThingToDo(tm) isn't clear.

Here's the situation:

Binary operators for the built-in set object restrict their "other" argument to 
instances of set, frozenset, or one of their subclasses.   Otherwise, they 
return NotImplemented.  This design was intentional (i.e. part of the original 
pure python version, it is unittested behavior, and it is a documented 
restriction).  It allows other classes to "see" the NotImplemented and have a 
chance to take-over using __ror__, __rand__, etc. Also, by not accepting 
any iterable, it prevents little coding atrocities or possible mistakes like "s 
| 'abc'".  This is a break with what is done for lists (Guido has previously 
lamented that list.__add__ accepting any iterable is one of his "regrets").  
This design has been in place for several years and so far everyone has been 
happy with it (no bug reports, feature requests, or discussions on the 
newsgroup, etc).  If someone needed to process a non-set iterable, the named 
set methods (like intersection, update, etc) all accept any iterable value and 
this provides an immediate, usable alternative.

In contrast, the Set and MutableSet abstract base classes in Lib/_abcoll.py 
take a different approach.  They specify that something claiming to be set-like 
will accept any-iterable for a binary operator (IOW, the builtin set object 
does not comply).   The provided mixins (such as __or__, __and__, etc) are 
implemented that way and it works fine.  Also, the Set and MutableSet API do 
not provide named methods such as update, intersection, difference, etc.  They 
aren't really needed because the operator methods already provide the 
functionality and because it keeps the Set API to a reasonable minimum.

All of this it well and good, but the two don't interoperate.  You can't get an 
instance of the Set ABC to work with a regular set, nor do regular sets comply 
with the ABC.  These are problems because they defeat some of the design goals 
for ABCs.

We have a few options:

1. Liberalize setobject.c binary operator methods to accept anything registered 
to the Set ABC and add a backwards incompatible restriction to the Set ABC 
binary operator methods to only accept Set ABC instances (they currently accept 
any iterable).   

This approach has a backwards incompatible tightening of the Set ABC, but that 
will probably affect very few people.  It also has the disadvantage of not 
providing a straight-forward way to handle general iterable arguments (either 
the implementer needs to write named binary methods like update, difference, 
etc for that purpose or the user will need to cast the the iterable to a set 
before operating on it).   The positive side of this option is that keeps the 
current advantages of the setobject API and its NotImplemented return value.

1a.  Liberalize setobject.c binary operator methods, restrict SetABC methods, 
and add named methods (like difference, update, etc) that accept any iterable.

2. We could liberalize builtin set objects to accept any iterable as an "other" 
argument to a binary set operator.  This choice is not entirely backwards 
compatible because it would break code depending on being able run __ror__, 
__rand__, etc after a NotImplemented value is returned.  That being said, I 
think it unlikely that such code exists.  The real disadvantage is that it 
replicates the problems with list.__add__ and Guido has said before that he 
doesn't want to do that again.  

I was leaning towards #1 or #1a and the guys on IRC thought #2 would be better. 
 Now I'm not sure and would like additional input so I can get this bug closed 
for 3.2.  Any thoughts on the subject would be appreciated.

Thanks,


Raymond


P.S. I also encountered a small difficulty in implementing #2 that would still 
need to be resolved if that option is chosen.

























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

Re: [Python-Dev] API for binary operations on Sets

[geremy condra]

On Wed, Sep 29, 2010 at 8:50 PM, Raymond Hettinger
 wrote:
> I would like to solicit this group's thoughts on how to reconcile the Set
> abstract base class with the API for built-in set objects
> (see http://bugs.python.org/issue8743 ).  I've been thinking about this
> issue for a good while and the RightThingToDo(tm) isn't clear.
> Here's the situation:
> Binary operators for the built-in set object restrict their "other" argument
> to instances of set, frozenset, or one of their subclasses.   Otherwise,
> they return NotImplemented.  This design was intentional (i.e. part of the
> original pure python version, it is unittested behavior, and it is a
> documented restriction).  It allows other classes to "see" the
> NotImplemented and have a chance to take-over using __ror__, __rand__, etc.
>     Also, by not accepting any iterable, it prevents little coding
> atrocities or possible mistakes like "s | 'abc'".  This is a break with what
> is done for lists (Guido has previously lamented that list.__add__ accepting
> any iterable is one of his "regrets").  This design has been in place for
> several years and so far everyone has been happy with it (no bug reports,
> feature requests, or discussions on the newsgroup, etc).  If someone needed
> to process a non-set iterable, the named set methods (like intersection,
> update, etc) all accept any iterable value and this provides an immediate,
> usable alternative.
> In contrast, the Set and MutableSet abstract base classes in Lib/_abcoll.py
> take a different approach.  They specify that something claiming to be
> set-like will accept any-iterable for a binary operator (IOW, the builtin
> set object does not comply).   The provided mixins (such as __or__, __and__,
> etc) are implemented that way and it works fine.  Also, the Set and
> MutableSet API do not provide named methods such as update, intersection,
> difference, etc.  They aren't really needed because the operator methods
> already provide the functionality and because it keeps the Set API to a
> reasonable minimum.
> All of this it well and good, but the two don't interoperate.  You can't get
> an instance of the Set ABC to work with a regular set, nor do regular sets
> comply with the ABC.  These are problems because they defeat some of the
> design goals for ABCs.
> We have a few options:
> 1. Liberalize setobject.c binary operator methods to accept anything
> registered to the Set ABC and add a backwards incompatible restriction to
> the Set ABC binary operator methods to only accept Set ABC instances (they
> currently accept any iterable).
> This approach has a backwards incompatible tightening of the Set ABC, but
> that will probably affect very few people.  It also has the disadvantage of
> not providing a straight-forward way to handle general iterable arguments
> (either the implementer needs to write named binary methods like update,
> difference, etc for that purpose or the user will need to cast the the
> iterable to a set before operating on it).   The positive side of this
> option is that keeps the current advantages of the setobject API and its
> NotImplemented return value.
> 1a.  Liberalize setobject.c binary operator methods, restrict SetABC
> methods, and add named methods (like difference, update, etc) that accept
> any iterable.
> 2. We could liberalize builtin set objects to accept any iterable as an
> "other" argument to a binary set operator.  This choice is not entirely
> backwards compatible because it would break code depending on being able run
> __ror__, __rand__, etc after a NotImplemented value is returned.  That being
> said, I think it unlikely that such code exists.  The real disadvantage is
> that it replicates the problems with list.__add__ and Guido has said before
> that he doesn't want to do that again.
> I was leaning towards #1 or #1a and the guys on IRC thought #2 would be
> better.  Now I'm not sure and would like additional input so I can get this
> bug closed for 3.2.  Any thoughts on the subject would be appreciated.

I'm not clear on what the issues with list.__add__ were, but my first
impression is to lean towards #2. What am I missing?

> Thanks,
>
> Raymond
>
> P.S. I also encountered a small difficulty in implementing #2 that would
> still need to be resolved if that option is chosen.

What's the issue, if you don't mind me asking?

Geremy Condra
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] API for binary operations on Sets

[Terry Reedy]

On 9/29/2010 11:50 PM, Raymond Hettinger wrote:

I would like to solicit this group's thoughts on how to reconcile the
Set abstract base class with the API for built-in set objects (see
http://bugs.python.org/issue8743 ). I've been thinking about this issue
for a good while and the RightThingToDo(tm) isn't clear.

Here's the situation:

Binary operators for the built-in set object restrict their "other"
argument to instances of set, frozenset, or one of their subclasses.
Otherwise, they return NotImplemented. This design was intentional (i.e.
part of the original pure python version, it is unittested behavior, and
it is a documented restriction). It allows other classes to "see" the
NotImplemented and have a chance to take-over using __ror__, __rand__,
etc. Also, by not accepting any iterable, it prevents little coding
atrocities or possible mistakes like "s | 'abc'". This is a break with
what is done for lists (Guido has previously lamented that list.__add__
accepting any iterable is one of his "regrets").


I do not understand this. List.__add__ is currently *more* restrictive 
than set ops in that it will not even accept a 'frozenlist' (aka tuple).


>>> ll + (4,5,6)
Traceback (most recent call last):
  File "", line 1, in 
ll + (4,5,6)
TypeError: can only concatenate list (not "tuple") to list
>>> ll.__add__((5,6,7))
Traceback (most recent call last):
  File "", line 1, in 
ll.__add__((5,6,7))
TypeError: can only concatenate list (not "tuple") to list

Does this violate the Sequence ABC (assuming there is one)?


--
Terry Jan Reedy

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

Re: [Python-Dev] API for binary operations on Sets

[Raymond Hettinger]

On Sep 29, 2010, at 11:29 PM, Terry Reedy wrote:
> I do not understand this. List.__add__ is currently *more* restrictive than 
> set ops in that it will not even accept a 'frozenlist' (aka tuple).

Sorry, that should have been __iadd__().

>>> s = range(5)
>>> s += 'abc'
>>> s
[0, 1, 2, 3, 4, 'a', 'b', 'c']


Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] API for binary operations on Sets

[Jack Diederich]

I will say something snarky now and (hopefully) something useful tomorrow.

When ABCs went in I was +0 because, like annotations, I was told I
wouldn't have to care about them.  That said; I do actually care about
the set interface and what "set-y-ness" means for regular duck typing
reasons.  What people expect sets to do is what sets-alikes should do.

-Jack
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] hg conversion: tags

[Brett Cannon]

On Wed, Sep 29, 2010 at 15:15, "Martin v. Löwis"  wrote:
>> I don't know how hg manages this, but can't we preserve the tag
>> information of the tags that you've scheduled to be removed
>> in some place that can easily be pulled in but doesn't
>> affect the main repo size ?
>
> Most certainly, and this is the plan already: we will keep the
> subversion repository data "forever".
>
> If you want the CVS repository from the day when it was converted
> to subversion, you can still get it from
>
> http://svn.python.org/snapshots/python-cvsroot-final.tar.bz2
>
> (Created 27-Oct-2005 04:34, FWIW, so we are close to 5 years
> into subversion usage. Given that the "public" usage of the CVS
> started in 2000, we should start to look into the hg successor
> around 2013, for a switchover in Oktober 2015 :-).

Just so people know, I am *not* leading that charge.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] API for binary operations on Sets

[Raymond Hettinger]

On Sep 29, 2010, at 11:11 PM, geremy condra wrote:
>> 
>> P.S. I also encountered a small difficulty in implementing #2 that would
>> still need to be resolved if that option is chosen.
> 
> What's the issue, if you don't mind me asking?

IIRC, just commenting-out the Py_AnySet checks in set_or, set_xor, etc
led to a segfault in TestOnlySetsInBinaryOps in Lib/test/test_set.py.
There was something subtle going on and I haven't had time
to trace though it yet.  Somewhere a guard is probably missing.


Raymond

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