On Wed, Oct 29, 2008 at 9:22 PM, <[EMAIL PROTECTED]> wrote:
>
> On 29 Oct, 09:14 pm, [EMAIL PROTECTED] wrote:
>>
>> Will 3.1 and 2.7 also be parallel releases? (I ask, not having read
>> the 3xxx PEPS at all.)
>>
>> If yes, why? While I can see a case for 2.6/3.0 being in sync -- new
>> features
On Fri, Oct 31, 2008 at 11:55 AM, Brian Granger <[EMAIL PROTECTED]> wrote:
>>> Has anyone made the argument for keeping the GIL to discourage
>>> threading?
>>
>> Oooh, you are on to my secret plan! :-)
>
> I completely agree that there are other approaches to parallelism and
> concurrency that are
>> Has anyone made the argument for keeping the GIL to discourage
>> threading?
>
> Oooh, you are on to my secret plan! :-)
I completely agree that there are other approaches to parallelism and
concurrency that are much better than threading. However, I don't
think this is a good argument for hav
ACTIVITY SUMMARY (10/24/08 - 10/31/08)
Python tracker at http://bugs.python.org/
To view or respond to any of the issues listed below, click on the issue
number. Do NOT respond to this message.
2153 open (+33) / 13915 closed (+19) / 16068 total (+52)
Open issues with patches: 705
Average
> But we need also some hooks to automate stage changes:
> * attach a new patch => set stage to "patch review"
>(and maybe add the keyword "review")
The latter already happens automatically.
> * remove "patch reviewed" keyword => set stage to "commit review"
> * set status to "closed" => s
> I have a similar list that I have been thinking about proposing. I did
> a blog post about it at
> http://sayspy.blogspot.com/2008/08/what-are-typical-steps-issue-goes.html
> and received positive feedback:
>
> * triage
> * verify bug
> * test needed
> * needs patch
> * patch review
> * commit re
On Fri, Oct 31, 2008 at 4:59 AM, Calvin Spealman <[EMAIL PROTECTED]> wrote:
> Has anyone made the argument for keeping the GIL to discourage
> threading?
Oooh, you are on to my secret plan! :-)
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
_
Victor Stinner schrieb:
> Le Friday 31 October 2008 14:13:01 Christian Heimes, vous avez écrit :
>> ctypes is also missing utilities to write code that works on 32 and
>> 64bit platforms. Without a tool like
>> http://pypi.python.org/pypi/ctypes_configure it's very hard and tedious
>> to avoid and
Christian Heimes schrieb:
> Nick Coghlan wrote:
>> If I recall correctly, the main blocker to ctypes portability is libffi
>> portability. So if anyone would like to see ctypes on more platforms,
>> then that's the limitation they really need to attack.
>
> ctypes is also missing utilities to writ
Calvin> Has anyone made the argument for keeping the GIL to discourage
Calvin> threading? I'm only throwing this out there and I'm sure we'd
Calvin> want to improve things no matter what, but I would like to voice
Calvin> the concern anyway. We all know there are people who think
On Fri, Oct 31, 2008 at 9:17 AM, Michael Foord
<[EMAIL PROTECTED]> wrote:
> Calvin Spealman wrote:
>>
>> Has anyone made the argument for keeping the GIL to discourage
>> threading? I'm only throwing this out there and I'm sure we'd want to
>> improve things no matter what, but I would like to voic
Le Friday 31 October 2008 14:13:01 Christian Heimes, vous avez écrit :
> ctypes is also missing utilities to write code that works on 32 and
> 64bit platforms. Without a tool like
> http://pypi.python.org/pypi/ctypes_configure it's very hard and tedious
> to avoid and fix segfaults.
I wrote some c
Calvin Spealman wrote:
Has anyone made the argument for keeping the GIL to discourage
threading? I'm only throwing this out there and I'm sure we'd want to
improve things no matter what, but I would like to voice the concern
anyway. We all know there are people who think threading is the answer
t
Nick Coghlan wrote:
If I recall correctly, the main blocker to ctypes portability is libffi
portability. So if anyone would like to see ctypes on more platforms,
then that's the limitation they really need to attack.
ctypes is also missing utilities to write code that works on 32 and
64bit pla
Alexandre Vassalotti wrote:
But what if PyType_GenericAlloc is used for tp_alloc? As far as I
know, the memory block allocated with PyType_GenericAlloc is zeroed.
Oh, you are right. The generic allocator uses memset to initialize the
block with \0.
Christian
_
On Fri, Oct 31, 2008 at 07:59:01AM -0400, Calvin Spealman wrote:
> Has anyone made the argument for keeping the GIL to discourage
> threading?
I haven't, but I would support such argument. In my humble opinion
multithreading is rarely a good answer, and for multicore CPUs it's a wrong
answer. F
Has anyone made the argument for keeping the GIL to discourage
threading? I'm only throwing this out there and I'm sure we'd want to
improve things no matter what, but I would like to voice the concern
anyway. We all know there are people who think threading is the answer
to all things, and who don
> Looks like it should be
>
> http://code.python.org/loggerhead/static/images/ico_folder.gif
I did a quick hack for the static files, but many of the links still
don't work. loggerhead has specific support for reverse proxies
(through loggerhead.conf), but I couldn't figure out how to activat
> A couple nits. Leaving off the trailing / yields a 404. (No big deal
> though). More importantly, there seem to be no images, e.g.:
>
> http://code.python.org/static/images/ico_folder.gif
>
> Looks like it should be
>
> http://code.python.org/loggerhead/static/images/ico_folder.gif
Martin> I have now restored the original URL structure, and moved the
Martin> loggerhead installation to
Martin> http://code.python.org/loggerhead/
A couple nits. Leaving off the trailing / yields a 404. (No big deal
though). More importantly, there seem to be no images, e.g.:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Oct 31, 2008, at 03:50 AM, Eric Smith wrote:
>I posted this yesterday about using bzr:
>
> >I'd like to try it out, but the instructions on
> > http://www.python.org/dev/bazaar/ say to get wget
> > http://code.python.org/snapshots/python-bzr-snapsh
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Oct 31, 2008, at 08:58 AM, Barry Warsaw wrote:
>Naw, I think I just f'd up the Apache conf. I'll try to fix that.
And by "I'll" of course I meant "Martin". :)
Thanks Martin!
- -Barry
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Oct 31, 2008, at 08:44 AM, Georg Brandl wrote:
>Brett Cannon schrieb:
>> I just tried to update my 3.0 branch in hg from
>> http://code.python.org/hg/branches/py3k/ and hg is telling me it's a
>> 404. Anyone else having trouble?
>
>404 here too.
>
>> Yet another hint at the evil force-Bazaar-upon-them conspiracy .
>
> I'm not so sure Bazaar isn't it's own victim :)
I have now restored the original URL structure, and moved the loggerhead
installation to
http://code.python.org/loggerhead/
Regards,
Martin
___
On Fri, Oct 31, 2008 at 2:11 AM, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Adam Olsen wrote:
>> On Fri, Oct 31, 2008 at 12:24 AM, Nick Coghlan <[EMAIL PROTECTED]> wrote:
>>> Neil Schemenauer wrote:
Sigurd Torkel Meldgaard <[EMAIL PROTECTED]> wrote:
> For a student project in a course on vi
On Fri, Oct 31, 2008 at 7:46 AM, Nick Coghlan <[EMAIL PROTECTED]> wrote:
>>
>> What about having two level of devs ?
>>
>> + core developers + standard library developers
>>
>> [cut]
>
>
> So I'd suggest thinking about developer responsibilities more in terms
> of areas of expertise rather than "le
Adam Olsen wrote:
> On Fri, Oct 31, 2008 at 12:24 AM, Nick Coghlan <[EMAIL PROTECTED]> wrote:
>> Neil Schemenauer wrote:
>>> Sigurd Torkel Meldgaard <[EMAIL PROTECTED]> wrote:
For a student project in a course on virtual machines, we are
evaluating the possibility to experiment with remov
On Fri, Oct 31, 2008 at 12:24 AM, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Neil Schemenauer wrote:
>> Sigurd Torkel Meldgaard <[EMAIL PROTECTED]> wrote:
>>> For a student project in a course on virtual machines, we are
>>> evaluating the possibility to experiment with removing the GIL
>>> from CPy
Georg Brandl wrote:
Brett Cannon schrieb:
I just tried to update my 3.0 branch in hg from
http://code.python.org/hg/branches/py3k/ and hg is telling me it's a
404. Anyone else having trouble?
404 here too.
Since http://code.python.org/ serves the loggerhead Bazaar view, I suppose
the problem
Brett Cannon schrieb:
> I just tried to update my 3.0 branch in hg from
> http://code.python.org/hg/branches/py3k/ and hg is telling me it's a
> 404. Anyone else having trouble?
404 here too.
Since http://code.python.org/ serves the loggerhead Bazaar view, I suppose
the problem is that the logger
30 matches
Mail list logo
