I'm pushing the release schedule for 2.7.7 back a week. That means the
release candidate will be next weekend (May 17). This will hopefully
save some trouble for the people who build our binaries, since 3.4.1
final is happening next weekend, too.
Regards,
Benjamin
_
Hi,
May tests expect that unless they themselves start a thread then there
are no threads to worry about?
I see that some old tests are not thread-safe and I have not found it to
be explicitly mentioned in the devguide.
I've written a test for http://bugs.python.org/issue21332 that is known
On May 9, 2014, at 4:20 PM, Terry Reedy wrote:
> On 5/9/2014 2:12 PM, Donald Stufft wrote:
>>
>> On May 9, 2014, at 1:28 PM, R. David Murray wrote:
>
>>> I don't understand this. Why it is our responsibility to provide a
>>> free service for a large project to repeatedly download a set of fi
On 5/9/2014 2:12 PM, Donald Stufft wrote:
On May 9, 2014, at 1:28 PM, R. David Murray wrote:
I don't understand this. Why it is our responsibility to provide a
free service for a large project to repeatedly download a set of files
they need? Why does it not make more sense for them to down
On May 9, 2014, at 1:28 PM, R. David Murray wrote:
> On Fri, 09 May 2014 11:39:02 -0400, Donald Stufft wrote:
>>
>> On May 9, 2014, at 9:58 AM, M.-A. Lemburg wrote:
>>> On 09.05.2014 13:44, Donald Stufft wrote:
On May 9, 2014, at 4:12 AM, M.-A. Lemburg wrote:
>>> I snipped the rest of t
On Fri, 09 May 2014 11:39:02 -0400, Donald Stufft wrote:
>
> On May 9, 2014, at 9:58 AM, M.-A. Lemburg wrote:
> > On 09.05.2014 13:44, Donald Stufft wrote:
> >> On May 9, 2014, at 4:12 AM, M.-A. Lemburg wrote:
> > I snipped the rest of the discussion and reliability, using
> > unmaintained pack
On Thu, May 8, 2014 at 4:20 PM, Zachary Ware
wrote:
> I updated the 2.7 buildbot scripts to pull in Tcl/Tk 8.5.15 a couple
> of weeks ago (see http://bugs.python.org/issue21303), but hadn't
> gotten anything done with Tix yet. It should just need python.mak
> updated to point to Tcl/Tk 8.5.15; it
Stefan,
If the only way you can think of to invalidate Donald's (vastly
superior) arguments is to accuse of him of "gossip", you should
probably reconsider your arguments. Looking at the conversation you
didn't actually link to
(https://botbot.me/freenode/python-requests/msg/14389415/) there is no
On May 9, 2014, at 12:11 PM, Stefan Krah wrote:
> Donald, I'm out of his discussion. I have one last request: please don't
> gossip about core devs in public as long as you have commit privs:
>
> https://botbot.me/freenode/python-requests/
I don’t really know how to respond to this. I was tal
On 09.05.2014 17:39, Donald Stufft wrote:
>
> On May 9, 2014, at 9:58 AM, M.-A. Lemburg wrote:
>
>> On 09.05.2014 13:44, Donald Stufft wrote:
>>>
>>> On May 9, 2014, at 4:12 AM, M.-A. Lemburg wrote:
Donald: I don't think anyone is arguing that hosting packages on
PyPI is a bad thing a
Donald, I'm out of his discussion. I have one last request: please don't
gossip about core devs in public as long as you have commit privs:
https://botbot.me/freenode/python-requests/
Stefan Krah
___
Python-Dev mailing list
Python-Dev@python.org
ht
ACTIVITY SUMMARY (2014-05-02 - 2014-05-09)
Python tracker at http://bugs.python.org/
To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.
Issues counts and deltas:
open4611 ( +6)
closed 28624 (+42)
total 33235 (+48)
Open issues wit
On May 9, 2014, at 9:58 AM, M.-A. Lemburg wrote:
> On 09.05.2014 13:44, Donald Stufft wrote:
>>
>> On May 9, 2014, at 4:12 AM, M.-A. Lemburg wrote:
>>> Donald: I don't think anyone is arguing that hosting packages on
>>> PyPI is a bad thing and PyPI as a service has gotten a lot better
>>> tha
On Fri, May 09, 2014 at 06:09:28AM -0700, Ethan Furman
wrote:
> On 05/08/2014 02:02 PM, Paul Moore wrote:
> Well, I do host a small handful of modules on PyPI, but I can say that some
> of my pain points are:
>
> - getting a good name: the obvious ones are taken, so the search
> begins to
On 09.05.2014 13:44, Donald Stufft wrote:
>
> On May 9, 2014, at 4:12 AM, M.-A. Lemburg wrote:
>> Donald: I don't think anyone is arguing that hosting packages on
>> PyPI is a bad thing and PyPI as a service has gotten a lot better
>> than it was a few years ago.
>
> Didn’t mean to imply that I
On 05/08/2014 02:02 PM, Paul Moore wrote:
Socially, this change does not seem to be having the effect of
persuading more package developers to host on PyPI. The stick doesn't
appear to have worked, maybe we should be trying to find a carrot? Or
maybe we have to accept that some developers have s
On Fri, 9 May 2014 13:47:49 +0100
Paul Moore wrote:
> On 9 May 2014 13:25, Donald Stufft wrote:
> >> You're claiming that Mercurial moved to hosting on PyPI solely because
> >> users suddenly needed to add a flag to install from pip? As opposed to
> >> because PyPI gave them a more reliable hosti
On 9 May 2014 13:25, Donald Stufft wrote:
>> You're claiming that Mercurial moved to hosting on PyPI solely because
>> users suddenly needed to add a flag to install from pip? As opposed to
>> because PyPI gave them a more reliable hosting platform, for example?
>> OK. I certainly can't give any e
Paul Moore wrote:
> You're claiming that Mercurial moved to hosting on PyPI solely because
> users suddenly needed to add a flag to install from pip? As opposed to
> because PyPI gave them a more reliable hosting platform, for example?
> OK. I certainly can't give any evidence to dispute that clai
On May 9, 2014, at 8:21 AM, Paul Moore wrote:
> On 9 May 2014 13:06, Donald Stufft wrote:
I think it's important to point out that one of the driving factors that
caused
me to finally push for changes and what lead to PEP438 being created was
that
Mercurial's external
On 9 May 2014 13:06, Donald Stufft wrote:
>>> I think it's important to point out that one of the driving factors that
>>> caused
>>> me to finally push for changes and what lead to PEP438 being created was
>>> that
>>> Mercurial's external hosted was being extremely flaky. I can't remember the
On May 9, 2014, at 7:55 AM, Paul Moore wrote:
> On 9 May 2014 12:44, Donald Stufft wrote:
>> We still wouldn't be forcing anyone to upload things to PyPI. We are,
>> however,
>> discouraging people from not hosting on PyPI and providing incentives to
>> doing
>> that.
>
> But you're doing so
On 9 May 2014 21:55, Paul Moore wrote:
> On 9 May 2014 12:44, Donald Stufft wrote:
>> I think it's important to point out that one of the driving factors that
>> caused
>> me to finally push for changes and what lead to PEP438 being created was that
>> Mercurial's external hosted was being extre
On May 9, 2014, at 5:01 AM, Paul Moore wrote:
> On 9 May 2014 05:34, Donald Stufft wrote:
>> On May 8, 2014, at 5:22 PM, Donald Stufft wrote:
>>
Socially, this change does not seem to be having the effect of
persuading more package developers to host on PyPI. The stick doesn't
On 9 May 2014 12:44, Donald Stufft wrote:
> We still wouldn't be forcing anyone to upload things to PyPI. We are, however,
> discouraging people from not hosting on PyPI and providing incentives to doing
> that.
But you're doing so by inflicting pain on people using pip to install
those packages.
On May 9, 2014, at 4:12 AM, M.-A. Lemburg wrote:
> On 08.05.2014 23:22, Donald Stufft wrote:
>>
>>> On a personal note, I'm uncomfortable with the way this change is
>>> perceived as a case of *pip* enforcing a behaviour that the pip
>>> developers feel should be required. I actually don't like
Donald Stufft wrote:
> I?m unsure if you?re being willfully dense or if you?re just not understanding
> what I mean when I say ?almost?. Of course there are going to be a few
> outliers
> where people do bother to do that, but it?s not going to be common place at
> all.
I suggest that you confin
On 9 May 2014 05:34, Donald Stufft wrote:
> On May 8, 2014, at 5:22 PM, Donald Stufft wrote:
>
>>> Socially, this change does not seem to be having the effect of
>>> persuading more package developers to host on PyPI. The stick doesn't
>>> appear to have worked, maybe we should be trying to find
On 08.05.2014 23:22, Donald Stufft wrote:
>
>> On a personal note, I'm uncomfortable with the way this change is
>> perceived as a case of *pip* enforcing a behaviour that the pip
>> developers feel should be required. I actually don't like this change
>> particularly. So having pip implement the
29 matches
Mail list logo
