On Thu, 22 Oct 2009 12:32:37 -0300, Fabio Zadrozny wrote:
> Just as a note, the nonlocal there is not a requirement...
>
> You can just create a mutable object there and change that object (so,
> you don't need to actually rebind the object in the outer scope).
>
> E.g.: instead of creating a f
Brett Cannon writes:
> Another summit, another potential time to see if people want to change
> anything about the issue tracker.
It requires some coding, but I see OpenID authentication support
http://issues.roundup-tracker.org/issue2550523> to be important for
lowering the barrier to getting b
Another summit, another potential time to see if people want to change
anything about the issue tracker. I would bring up:
- Dropping Stage in favor of some keywords (e.g. 'needs unit test', 'needs
docs')
- Adding a freestyle text box to delineate which, if any, stdlib module is
the cause of a bug
On Fri, 23 Oct 2009 05:39:53 am Brett Cannon wrote:
> > Is __doc__ not normal due to its general underscorishness, or is it
> > not normal because it isn't?
>
> I honestly don't follow that sentence. But __doc__ is special because
> of its use; documenting how to use of an object. In this case whe
> From the Django roadmap for supporting 3.0, using 2.6 as a stepping
> stone (and if 2.7 was a *better* stepping stone then it would make it
> easier):
>
>http://groups.google.com/group/django-developers/msg/0888b1c8f2518059?
Is that still a current plan? It's from November 2008.
> This get
Phillip Sitbon skrev:
Some of this is more low-level. I did see higher performance when
using non-Event objects, although I have not had time to follow up and
do a deeper analysis. The GIL flashing "problem" with critical
sections can very likely be rectified with a call to Sleep(0) or
YieldProce
Antoine Pitrou skrev:
This number lacks the elapsed time. 61 switches in one second is probably
enough, the same amount of switches in 10 or 20 seconds is too small (at least
for threads needing good responsivity, e.g. I/O threads).
Also, "fair" has to take into account the average latency and i
Martin v. Löwis wrote:
exar...@twistedmatrix.com wrote:
On 08:24 pm, mar...@v.loewis.de wrote:
Mike Krell wrote:
Is there any possibility of backporting support for the nonlocal keyword
into a 2.x release?
If so, only into 2.7. Can you please explain why it would be d
Le jeudi 22 octobre 2009 à 13:59 -0700, Guido van Rossum a écrit :
> > I don't really understand how this explains the read-only __doc__.
> > I am talking about modifying __doc__ on a class, not on an instance.
> > (sure, a new-style class is also an instance of type, but still...)
>
> Antoine, it
On Thu, Oct 22, 2009 at 1:49 PM, Antoine Pitrou wrote:
> Brett Cannon python.org> writes:
>> I honestly don't follow that sentence. But __doc__ is special because of its
>> use; documenting how to use of an object. In this case when you call
>> something like help() on an instance of an object it
exar...@twistedmatrix.com wrote:
> On 08:24 pm, mar...@v.loewis.de wrote:
>> Mike Krell wrote:
>>> Is there any possibility of backporting support for the nonlocal keyword
>>> into a 2.x release?
>>
>> If so, only into 2.7. Can you please explain why it would be desirable
>> to do that? 2.7 will l
On Thu, 2009-10-22 at 21:27 +0100, Paul Moore wrote:
> 2009/10/22 Robert Collins :
> > On Thu, 2009-10-22 at 13:16 -0400, Tres Seaver wrote:
> > ...
> >> That being said, I can't this bug as a release blocker: people can
> >> either upgrade to super-current Boost, or stick with 2.6.2 until they ca
Brett Cannon python.org> writes:
>
>
> I honestly don't follow that sentence. But __doc__ is special because of its
> use; documenting how to use of an object. In this case when you call
> something like help() on an instance of an object it skips the instance's
> value for __doc__ and goes s
Kristján Valur Jónsson wrote:
> Yes. The problem with QPC is that although it has very high
> resolution, it is not precise in the long term. And
> GetSystemTimeAsFileTime() is high precision in the long term but only
> updated evey 20ms or so. In EVE Online we use a combination of the
> two for
On 08:24 pm, mar...@v.loewis.de wrote:
Mike Krell wrote:
Is there any possibility of backporting support for the nonlocal
keyword
into a 2.x release?
If so, only into 2.7. Can you please explain why it would be desirable
to do that? 2.7 will likely be the last 2.x release, so only a fairly
s
On Oct 22, 2009, at 3:53 PM, Robert Collins wrote:
On Thu, 2009-10-22 at 13:16 -0400, Tres Seaver wrote:
...
That being said, I can't this bug as a release blocker: people can
either upgrade to super-current Boost, or stick with 2.6.2 until
they can.
Thats the challenge Ubuntu faces:
http
On Oct 22, 2009, at 3:53 PM, Robert Collins wrote:
On Thu, 2009-10-22 at 13:16 -0400, Tres Seaver wrote:
...
That being said, I can't this bug as a release blocker: people can
either upgrade to super-current Boost, or stick with 2.6.2 until
they can.
Thats the challenge Ubuntu faces:
https
2009/10/22 Robert Collins :
> On Thu, 2009-10-22 at 13:16 -0400, Tres Seaver wrote:
> ...
>> That being said, I can't this bug as a release blocker: people can
>> either upgrade to super-current Boost, or stick with 2.6.2 until they can.
>
> Thats the challenge Ubuntu faces:
> https://bugs.edge.la
Mike Krell wrote:
> Is there any possibility of backporting support for the nonlocal keyword
> into a 2.x release?
If so, only into 2.7. Can you please explain why it would be desirable
to do that? 2.7 will likely be the last 2.x release, so only a fairly
small portion of the applications would
On Thu, 2009-10-22 at 13:16 -0400, Tres Seaver wrote:
...
> That being said, I can't this bug as a release blocker: people can
> either upgrade to super-current Boost, or stick with 2.6.2 until they can.
Thats the challenge Ubuntu faces:
https://bugs.edge.launchpad.net/ubuntu/+source/boost1.38/+b
Tres Seaver schrieb:
> Barry Warsaw wrote:
>> On Oct 22, 2009, at 10:47 AM, Benjamin Peterson wrote:
>
>>> 2009/10/22 Barry Warsaw :
So does anybody else think bug 7183 should be a release blocker for
2.6.4
final, or is even a legitimate but that we need to fix?
>>> I think it can
On Oct 22, 2009, at 2:39 PM, Brett Cannon wrote:
On Thu, Oct 22, 2009 at 11:18, sstein...@gmail.com > wrote:
On Oct 22, 2009, at 1:58 PM, Guido van Rossum wrote:
Well __doc__ isn't a normal attribute -- it doesn't follow
inheritance rules.
Maybe we could add a ticket to flag this in the
On 21 Oct 2009, at 06:15, Martin v. Löwis wrote:
I suggest following POSIX's lead and omitted the const in these
cases.
Ah... Yes I see this in strstr for example.
Thanks, that sounds reasonable.
This is basically what I have done in the patch I hope.
I have updated the patch to includ
On Thu, 22 Oct 2009 at 13:16, Tres Seaver wrote:
The fix for 5890 has a funny "smell" to me: copying __doc__ into the
instance dict just feels wrong. How does that work with a pure Python
class using slots? E.g.:
It doesn't. There's even a test to make sure it doesn't :)
(It raises an attrib
On Thu, Oct 22, 2009 at 11:18, sstein...@gmail.com wrote:
>
> On Oct 22, 2009, at 1:58 PM, Guido van Rossum wrote:
>
> Well __doc__ isn't a normal attribute -- it doesn't follow inheritance
>> rules.
>>
>
> Maybe we could add a ticket to flag this in the docs.
>
>
Sure, go for it.
> Is __doc__
On Oct 22, 2009, at 1:16 PM, Tres Seaver wrote:
That being said, I can't this bug as a release blocker: people can
either upgrade to super-current Boost, or stick with 2.6.2 until
they can.
Agreed. I've knocked it down from release-blocker.
-Barryu
PGP.sig
Description: This is a digita
On Thu, Oct 22, 2009 at 08:43, Georg Brandl wrote:
> Hi,
>
> issue #7033 proposes a new C API that creates a new exception class with
> a docstring. Since exception classes should be documented, and adding
> the docstring after creating is not a one-liner, I would say it is a useful
> addition.
I know I already posted some relevant threads to the other discussion,
but I wanted to point out a couple of specific comments on GIL
fairness from the discussion:
http://mail.python.org/pipermail/python-dev/2009-May/089752.html
http://mail.python.org/pipermail/python-dev/2009-May/089755.html
- P
On Oct 22, 2009, at 1:58 PM, Guido van Rossum wrote:
Well __doc__ isn't a normal attribute -- it doesn't follow
inheritance rules.
Maybe we could add a ticket to flag this in the docs.
Is __doc__ not normal due to its general underscorishness, or is it
not normal because it isn't?
Any o
On Thu, Oct 22, 2009 at 1:25 PM, Antoine Pitrou wrote:
..
> I might add why I was asking this question. I was trying to demonstrate the
> use
> of class decorators and the simplest example I found was to add a docstring to
> the class.
I always thought that read-only __doc__ was an artifact of n
Well __doc__ isn't a normal attribute -- it doesn't follow inheritance rules.
On Thu, Oct 22, 2009 at 10:25 AM, Antoine Pitrou wrote:
> Guido van Rossum python.org> writes:
>>
>> On Thu, Oct 22, 2009 at 9:45 AM, Antoine Pitrou pitrou.net>
> wrote:
>> >
>> > Speaking of the __doc__ property, I j
I'd just like to point out some previous discussion about implementing
the GIL as a critical section or semaphore on Windows since it's come
up here (although not quite the center of the OP's proposal AFAICS):
http://bugs.python.org/issue6132
http://mail.python.org/pipermail/python-dev/2009-May/08
Guido van Rossum python.org> writes:
>
> On Thu, Oct 22, 2009 at 9:45 AM, Antoine Pitrou pitrou.net>
wrote:
> >
> > Speaking of the __doc__ property, I just noticed the following thing
on py3k:
> >
> class C: pass
> > ...
> C.__doc__ = "hop"
> > Traceback (most recent call last):
> >
On Thu, Oct 22, 2009 at 7:12 PM, Guido van Rossum wrote:
> Yes.
Why?
--yuv
___
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%40ma
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Barry Warsaw wrote:
> On Oct 22, 2009, at 10:47 AM, Benjamin Peterson wrote:
>
>> 2009/10/22 Barry Warsaw :
>>> So does anybody else think bug 7183 should be a release blocker for
>>> 2.6.4
>>> final, or is even a legitimate but that we need to fix?
Tres Seaver palladion.com> writes:
>
> I read Sturla as saying there were 99,939 switches out of a possible
> 100,000, with sys.checkinterval set to 100.
Oops, you're right.
But depending on the elapsed time (again :-)), it may be too high, because
too many switches per second will add a lot of
On Thu, Oct 22, 2009 at 9:45 AM, Antoine Pitrou wrote:
>
> Speaking of the __doc__ property, I just noticed the following thing on py3k:
>
class C: pass
> ...
C.__doc__ = "hop"
> Traceback (most recent call last):
> File "", line 1, in
> AttributeError: attribute '__doc__' of 'type' ob
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Antoine Pitrou wrote:
> Sturla Molden molden.no> writes:
>> With two threads and a check interval og 100, only 61 of 10 check
>> intervals failed to produce a thread-switch in the interpreter. I'd call
>> that rather fair.
>
> This number lack
On Oct 22, 2009, at 11:04 AM, Barry Warsaw wrote:
On Oct 22, 2009, at 10:47 AM, Benjamin Peterson wrote:
2009/10/22 Barry Warsaw :
So does anybody else think bug 7183 should be a release blocker
for 2.6.4
final, or is even a legitimate but that we need to fix?
I think it cannot hold up a
> Speaking of the __doc__ property, I just noticed the following thing on
> py3k:
>
class C: pass
> ...
C.__doc__ = "hop"
> Traceback (most recent call last):
> File "", line 1, in
> AttributeError: attribute '__doc__' of 'type' objects is not writable
Happens also with new style clas
Speaking of the __doc__ property, I just noticed the following thing on py3k:
>>> class C: pass
...
>>> C.__doc__ = "hop"
Traceback (most recent call last):
File "", line 1, in
AttributeError: attribute '__doc__' of 'type' objects is not writable
Is this deliberate?
Antoine.
Stefan Krah wrote:
> Mark Dickinson wrote:
>> I think my biggest concern is maintenance: we'd be replacing
>> 8500 lines of Python code in a single file, that several of the
>> current core developers understand well, with 3 (Stefan, is
>> that about accurate?) lines of C in several files, tha
Hi,
issue #7033 proposes a new C API that creates a new exception class with
a docstring. Since exception classes should be documented, and adding
the docstring after creating is not a one-liner, I would say it is a useful
addition. What do you all think?
Georg
--
Thus spake the Lord: Thou sh
On Wed, Oct 21, 2009 at 10:56 PM, Mike Krell wrote:
> Is there any possibility of backporting support for the nonlocal keyword
> into a 2.x release? I see it's not in 2.6, but I don't know if that was an
> intentional design choice or due to a lack of demand / round tuits. I'm
> also not sure i
On Oct 22, 2009, at 10:47 AM, Benjamin Peterson wrote:
2009/10/22 Barry Warsaw :
So does anybody else think bug 7183 should be a release blocker for
2.6.4
final, or is even a legitimate but that we need to fix?
I think it cannot hold up a release with out a reproducible code
snippet.
It
Mark Dickinson wrote:
> > 2. Would fastdec - after achieving full decimal.py compatibility - be
> > a serious candidate?
>
> Definitely. As far as I know it's the only real candidate for a full
> C version of decimal right now. Other possibilities that I'm aware of:
>
> * I think Raymond Het
Mark Dickinson wrote:
> Thanks, Antoine! With SLOCCount I can revise my earlier numbers, as well:
> Here's Stefan Krah's mpdecimal, version 0.80:
>
> SLOCDirectory SLOC-by-Language (Sorted)
> 21445 top_dir ansic=21267,sh=105,python=55,asm=18
> 6238python
2009/10/22 Barry Warsaw :
> So does anybody else think bug 7183 should be a release blocker for 2.6.4
> final, or is even a legitimate but that we need to fix?
I think it cannot hold up a release with out a reproducible code snippet.
--
Regards,
Benjamin
___
I'd like to get a second opinion on bug 7183:
http://bugs.python.org/issue7183
The Boost folks have reported this as a regression in 2.6.3, making it
a candidate for Python 2.6.4. IIUC, the latest version of Boost fixes
the problem in their code, but if it really is a regression it could
> -Original Message-
> From: Mark Hammond [mailto:mhamm...@skippinet.com.au]
> Sent: 22. október 2009 10:58
> To: Kristján Valur Jónsson
> Cc: Scott Dial; python-dev@python.org
> It was made in the context of the APIs available to implement this.
> The
> code is short-and-sweet in timemod
M.-A. Lemburg egenix.com> writes:
>
> I'm not sure I understand why time.clock() should be considered
> broken.
Because in some cases you want comparable high-resolution numbers from distinct
processes.
> time.clock() is used for measuring process CPU time
According to the docs, under Windows
On 22/10/2009 3:45 PM, Robert Collins wrote:
On Thu, 2009-10-22 at 15:21 +1100, Mark Hammond wrote:
I'd be very surprised if any applications rely on
the fact that each process starts counting at zero, so if someone can
come up with a high-res counter which avoids that artifact I'd expect it
On 22/10/2009 8:47 PM, Kristján Valur Jónsson wrote:
The point in question seems to be this this (from the thread):
* Need some sort of static "start value", which is set when the
process starts, so I can return to Python in seconds. An easy hack
is to set this the first time clock() is ca
Curt Hagenlocher wrote:
> On Wed, Oct 21, 2009 at 1:51 PM, Antoine Pitrou wrote:
>>
>> Kristján Valur Jónsson ccpgames.com> writes:
>>>
>>> You are right, on windows time.clock() is based relative to its first call
>>> in the process. There is no such promise made on unix.
>>> QueryPerformanceCo
Glenn Linderman g.nevcal.com> writes:
>
> Maybe what David is missing is that since python-dev is uninterested in
> the package management issue, [...]
It's a bit strong to say we are uninterested. Most of us are not interested
enough to tackle it ourselves (*), but we are certainly interested
On Wed, Oct 21, 2009 at 10:35:49PM -0700, Glenn Linderman wrote:
> Maybe what David is missing is that since python-dev is uninterested in
> the package management issue, the only remaining way to include package
> management in a convenient, single installation, is to
>
> 1) Create the package
On Wed, Oct 21, 2009 at 08:34:24PM -0400, David Lyon wrote:
> I started out some time ago and wrote a Python Package Manager
> with wxpython.
David, your message appeared in the middle of another thread. Please
don't use "Reply" button to start a new thread - send a new message.
Oleg.
--
> -Original Message-
> From: python-dev-bounces+kristjan=ccpgames@python.org
> [mailto:python-dev-bounces+kristjan=ccpgames@python.org] On Behalf
> Of Robert Collins
> > I'd be very surprised if any applications rely on the fact that each
> > process starts counting at zero, so if
> -Original Message-
> From: python-dev-bounces+kristjan=ccpgames@python.org
> [mailto:python-dev-bounces+kristjan=ccpgames@python.org] On Behalf
> Of Mark Hammond
> The thread seems to be at
> http://groups.google.com/group/comp.lang.python/browse_frm/thread/be324
> 78a4b8e77b6/8
Sturla Molden molden.no> writes:
>
> With two threads and a check interval og 100, only 61 of 10 check
> intervals failed to produce a thread-switch in the interpreter. I'd call
> that rather fair.
This number lacks the elapsed time. 61 switches in one second is probably
enough, the same
Robert Collins robertcollins.net> writes:
>
> Could you offset it by the system time on the first call?
Two problems:
- the two measurements are not done simultaneously, so the result *still* does
not guarantee you have the same time reference in all processes (but gives you
the illusion you do,
61 matches
Mail list logo
