C or L Smith wrote:
> PROBLEM
> I need to find code snippets which are located in docstrings.
> Docstrings, being string literals should be able to be parsed out
> with tokenize. But tokenize is giving the wrong results (or I am
> doing something wrong) for this (pathological) case:
>
> foo
Ben Finney writes:
> Steven D'Aprano writes:
> > "get" is such a generic term that I don't believe that is a problem.
>
> The problem above is made less problematic by the fact that the function
> signature (e.g. 'foo_dict.get(key)') clarifies the answer to the
> question "get what?". Wher
BACKGROUND
I'm trying to modify the doctest DocTestParser so it will parse docstring
code snippets out of a *py file. (Although doctest can parse these with another
method out of *pyc, it is missing certain decorated functions and we would also
like to insist of import of needed modules rath
Steven D'Aprano writes:
> I'm not being tongue-in-cheek or sarcastic. My question was serious --
> if there is a moratorium, is there any reason to bother submitting
> patches for functional changes to built-ins?
Yes. Python is open source. Private and public forks are possible
and (at lea
Steven D'Aprano writes:
> On Sat, 24 Oct 2009 02:02:48 pm Ben Finney wrote:
> > I would expect a parameter-less ‘set.get’ to get the set. Not
> > terribly useful, but the name and function signature doesn't suggest
> > anything else.
>
> You already have the set. Why would you need a method that
On Sat, 24 Oct 2009 02:02:48 pm Ben Finney wrote:
> Steven D'Aprano writes:
> > On Sat, 24 Oct 2009 10:26:27 am Ben Finney wrote:
> > > Steven D'Aprano writes:
> > > > The lack of get() in sets and frozensets is sounding more and
> > > > more to me like the victory of purity over practicality.
>
Steven D'Aprano writes:
> On Sat, 24 Oct 2009 10:26:27 am Ben Finney wrote:
> > Steven D'Aprano writes:
> > > The lack of get() in sets and frozensets is sounding more and more
> > > to me like the victory of purity over practicality.
> >
> > What would be the input to ‘set.get’?
>
> It wouldn't
On Sat, 24 Oct 2009 10:26:27 am Ben Finney wrote:
> Steven D'Aprano writes:
> > On Sat, 24 Oct 2009 06:04:12 am Terry Reedy wrote:
> > > fwiw, I think the use case for this is sufficiently rare that it
> > > does not need a separate method just for this purpose.
> >
> > And yet it keeps coming up,
On Fri, 23 Oct 2009 11:47:22 pm Nick Coghlan wrote:
> Yuvgoog Greenle wrote:
> > On Fri, Oct 23, 2009 at 1:09 PM, Steven D'Aprano
wrote:
> >> Is there any point? Even if accepted, it's too late to make it
> >> into 3.1, and with the overwhelming approval for a moratorium on
> >> changes to built-
Steven D'Aprano writes:
> On Sat, 24 Oct 2009 06:04:12 am Terry Reedy wrote:
> > fwiw, I think the use case for this is sufficiently rare that it
> > does not need a separate method just for this purpose.
>
> And yet it keeps coming up, again and again... obviously people using
> sets in code thi
On Sat, 24 Oct 2009 07:53:24 am Willi Richert wrote:
> Hi,
>
> surprised about the performance of for/break provided by Vitor, I did
> some more testing. It revealed that indeed we can forget the get()
> (which was implemented as a stripped down pop()):
I don't understand that conclusion. Accord
Sturla Molden skrev:
I have a suggestion, forgive me if I am totally ignorant. :-)
Ah, damn... Since there is a GIL, we don't need any of that crappy
synchronization. And my code does not correct for the 20 ms time jitter
in GetSystemTimeAsFileTime. Sorry!
S.M.
__
On Sat, 24 Oct 2009 06:04:12 am Terry Reedy wrote:
> John Arbash Meinel wrote:
> > So 'for x in s: break' is about 2x faster than next(iter(s)) and 3x
> > faster than (iter(s).next()).
> > I was pretty surprised that it was 30% faster than "for x in s:
> > pass". I assume it has something to do wit
On Sat, 24 Oct 2009 07:11:57 am John Arbash Meinel wrote:
> The point of my test was that it was a set with a *single* item, and
> 'break' was 30% faster than 'pass'. Which was surprising.
Not really. See below.
> Certainly
> the difference is huge if there are 10k items in the set.
Earlier
Hi,
surprised about the performance of for/break provided by Vitor, I did some
more testing. It revealed that indeed we can forget the get() (which was
implemented as a stripped down pop()):
from timeit import *
stats = ["for i in xrange(1000): iter(s).next() ",
"for i in xrange(100
Terry Reedy wrote:
> John Arbash Meinel wrote:
>> So 'for x in s: break' is about 2x faster than next(iter(s)) and 3x
>> faster than (iter(s).next()).
>> I was pretty surprised that it was 30% faster than "for x in s: pass". I
>> assume it has something to do with a potential "else:" statement?
>
While I think there is some risk of exposure on this bug, I haven't
yet heard a compelling argument for delaying 2.6.4 final for it. I
think we should go ahead and do the release this Sunday as planned
with the code from 2.6.4rc2.
If you strongly disagree, please private email me. Otherwi
John Arbash Meinel wrote:
So 'for x in s: break' is about 2x faster than next(iter(s)) and 3x
faster than (iter(s).next()).
I was pretty surprised that it was 30% faster than "for x in s: pass". I
assume it has something to do with a potential "else:" statement?
for x in s: pass
iterates throu
Willi Richert wrote:
> recently I wrote an algorithm, in which very often I had to get an arbitrary
> element from a set without removing it.
See this discussion:
http://comments.gmane.org/gmane.comp.python.ideas/5606
Stefan
___
Python-Dev mailing li
2009/10/23 John Arbash Meinel :
> I was pretty surprised that it was 30% faster than "for x in s: pass". I
> assume it has something to do with a potential "else:" statement?
I'd imagine it's actually because it has to call next() a second time
and deal with the StopIteration exception - the loop
On Thu, Oct 22, 2009 at 5:51 PM, "Martin v. Löwis" wrote:
> > 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
Vitor Bosshard wrote:
> 2009/10/23 Willi Richert :
>> Hi,
>>
>> recently I wrote an algorithm, in which very often I had to get an arbitrary
>> element from a set without removing it.
>>
>> Three possibilities came to mind:
>>
>> 1.
>> x = some_set.pop()
>> some_set.add(x)
>>
>> 2.
>> for x in some
Kristján Valur Jónsson skrev:
Thanks, I'll take a look in that direction.
I have a suggestion, forgive me if I am totally ignorant. :-)
Sturla Molden
#include
union __reftime {
double us;
__int64 bits;
};
static volatile union __reftime __ref_perftime, __ref_filetime;
doubl
2009/10/23 Willi Richert :
> Hi,
>
> recently I wrote an algorithm, in which very often I had to get an arbitrary
> element from a set without removing it.
>
> Three possibilities came to mind:
>
> 1.
> x = some_set.pop()
> some_set.add(x)
>
> 2.
> for x in some_set:
> break
>
> 3.
> x = ite
VanL wrote:
Have you had any bites?
I'm going to help Andrew with the invites and working out agendas. He's
sent me a bunch of stuff to get me started.
Michael
Thanks,
Van
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.or
ACTIVITY SUMMARY (10/16/09 - 10/23/09)
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.
2474 open (+27) / 16541 closed (+16) / 19015 total (+43)
Open issues with patches: 987
Average
Have you had any bites?
Thanks,
Van
___
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
Antoine Pitrou writes:
> Besides, the more keywords there are, the messier it is.
That's what I've found in the XEmacs tracker. Keywords are a
reasonable way (in the context of the Roundup implementation) to test
new classifications before going to the effort of messing with the
page templates.
Brett> Another summit, another potential time to see if people want to
Brett> change anything about the issue tracker.
I have no idea how hard this would be to implement and won't be at the
language summit to formally present the idea, but it seems to me that some
integration between the i
Yuvgoog Greenle wrote:
> On Fri, Oct 23, 2009 at 1:09 PM, Steven D'Aprano wrote:
>> Is there any point? Even if accepted, it's too late to make it into 3.1,
>> and with the overwhelming approval for a moratorium on changes to
>> built-ins, it is likely to just sit in the tracker, forgotten, until
Le Thu, 22 Oct 2009 21:47:06 -0700, Brett Cannon a écrit :
>
> - Dropping Stage in favor of some keywords (e.g. 'needs unit test',
> 'needs docs')
What would it bring? We don't have a very strict process and the current
"stage" looks sufficient to me. Saying that unit tests or docs are
lacking
Thanks, I'll take a look in that direction.
> -Original Message-
> From: Nick Coghlan [mailto:ncogh...@gmail.com]
> I've even played with using Kalman filtering to do it... The idea is
> > to use the low frequency timer to apply correction coefficients to
> > the high frequency timer, yet
On Fri, Oct 23, 2009 at 1:09 PM, Steven D'Aprano wrote:
> Is there any point? Even if accepted, it's too late to make it into 3.1,
> and with the overwhelming approval for a moratorium on changes to
> built-ins, it is likely to just sit in the tracker, forgotten, until
> 2013 or later. How likely
On Fri, 23 Oct 2009 09:37:09 pm Oleg Broytman wrote:
> On Fri, Oct 23, 2009 at 12:23:08PM +0200, Willi Richert wrote:
> > The patch is attached.
>
>Patches should be put to the issue tracker. Thank you.
Is there any point? Even if accepted, it's too late to make it into 3.1,
and with the over
On Fri, 23 Oct 2009 08:32:45 pm Willi Richert wrote:
> Hi,
>
> recently I wrote an algorithm, in which very often I had to get an
> arbitrary element from a set without removing it.
>
> Three possibilities came to mind:
...
> Of course, the third should be the fastest.
If you need one or more item
On Fri, Oct 23, 2009 at 12:23:08PM +0200, Willi Richert wrote:
> The patch is attached.
Patches should be put to the issue tracker. Thank you.
Oleg.
--
Oleg Broytmanhttp://phd.pp.ru/p...@phd.pp.ru
Programmers don't die, they just GOSUB without RETURN.
_
Hi,
here is the first shot to provide a faster means of retrieving an arbitrary
element from a set without removing it.
The times for
=
from timeit import *
stat1 = "for i in xrange(100): iter(s).next()"
stat2 = "for i in xrange(100): s.get()"
for stat in [stat1, stat
Hi,
recently I wrote an algorithm, in which very often I had to get an arbitrary
element from a set without removing it.
Three possibilities came to mind:
1.
x = some_set.pop()
some_set.add(x)
2.
for x in some_set:
break
3.
x = iter(some_set).next()
Of course, the third should be
Brett Cannon wrote:
> 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, std
Steven D'Aprano wrote:
> 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
> Others have explained the rationale for the backport, so I won't bother
> repeating those arguments.
>
> I understand your point about code supporting 2.6, but as you say, that
> applies to any new features being added in 2.7. I'm therefore confused
> as to what the rationale for a 2.7 release
On Thu, Oct 22, 2009 at 1:24 PM, "Martin v. Löwis" wrote:
> Can you please explain why it would be desirable
> to [backport nonlocal]? 2.7 will likely be the last 2.x release, so only a
> fairly
> small portion of the applications would be actually able to use this (or
> any other new feature adde
42 matches
Mail list logo
