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, s
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
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
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'
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(
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 t
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:
Binar
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
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!
>>
>>
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
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 hav
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
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
> 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 repositor
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
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, e
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, especiall
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
> ofte
>> 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 c
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 cro
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 append
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 object
> 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 pus
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
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 objectiv
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 Review
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.
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 ho
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
> 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, h
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 sh
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 c
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 ena
> 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
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,
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
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 i
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 c
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). I
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 trac
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 gene
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 tr
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
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 wi
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. W
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 checkou
> > 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
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.
_
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
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 developer
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 pi
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
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 ge
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
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 Revie
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 p
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
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 th
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
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 major
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.
>>
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
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
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 e
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,
Dirkj
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
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 ju
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
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
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
>>
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 w
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
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
-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
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
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
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 man
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 int
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
-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
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
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 easil
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 specif
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
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-commi
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
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 fo
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 fund
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 ho
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 t
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 a
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
> renami
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 relea
> 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 optim
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 man
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 th
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 o
97 matches
Mail list logo
