Re: [Python-Dev] nonlocal keyword in 2.x?
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 added to 2.7): most code supporting 2.x will also > have to support 2.6, so the keyword won't be available to such code, > anyway. > 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 is. It's a bump in minor release number, so it's purpose is to add new features, correct? Could someone please explain what new features are currently envisioned for 2.7? Why would those make the cut but a not backport of nonlocal? Mike ___ 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
Re: [Python-Dev] nonlocal keyword in 2.x?
> 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 is. It's a bump in minor > release number, so it's purpose is to add new features, correct? That, but not only - it's purpose is also to allow for certain incompatible changes, and to arrive at a version that will be maintained until 2015 (wrt. security fixes). > Could someone please explain what new features are currently envisioned > for 2.7? Read through Misc/NEWS for details of what has been added already. > Why would those make the cut but a not backport of nonlocal? Just to name a few changes: - Issue #1655: Make imaplib IPv6-capable. Patch by Derek Morr. - Issue #4915: Port sysmodule to Windows CE. - Issue #6101: A new opcode, SETUP_WITH, has been added to speed up the with statement and correctly lookup the __enter__ and __exit__ special methods. - Issue #1616979: Added the cp720 (Arabic DOS) encoding. In all of these cases, in order to use the new feature, no change to Python code will be necessary: the feature just becomes available transparently. This is the kind of new features I like to see in 2.7. The other kind (i.e. features that do require application changes in order to use them) I find questionable. Regards, Martin ___ 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
Re: [Python-Dev] readonly __doc__
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 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 straight to the defining >> class and stops there as you don't care how a subclass says to use >> itself as that is not what you are working with. > > Classes don't normally inherit behaviour from their subclasses. > Presumably you meant superclass. > > I expected __doc__ to be just like the other double-underscore objects: > lookup skips the instance and goes to the class, then follows the > normal rules of inheritance. Consequently I've just discovered that a > few of my classes, which I assumed inherited __doc__, don't actually > have a docstring. This has consequences beyond help(obj) not working as > expected: doctests which I thought were running aren't. > > Magic behaviour like this is nasty because it breaks the Rule of Least > Astonishment. I thought I understood Python's object model and it's > rules of inheritance, but not only do double-underscore attributes > follow a different rule for inheritance than other attributes, but > __doc__ follows a different rule than other double-underscore > attributes. This actually breaks a recipe I recently suggested in python-ideas, where I recommended inheriting from a namedtuple instance in order to insert additional argument validity checks in __new__. Probably not invalid for it to break there though - in the case of that recipe, the default docstring from the parent class really should be replaced with one that details the additional constraints being placed on the arguments. Then again, the parent class docstring wouldn't have been wrong - merely incomplete. The point you mentioned about doctests silently failing to run strikes me as a pretty major glitch due to this behaviour though. Having a base class that defines the doctests to run in its docstring and then creating subclasses to specialise the test execution sounds like a perfectly reasonable use case to me (even though I personally tend to write unittest based test rather than doctest based ones). Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia --- ___ 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
Re: [Python-Dev] language summit topic: issue tracker
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, stdlib module > is the cause of a bug and tie that into Misc/maintainers.rst; would > potentially scale back the Component box +lots on adding a module field (independent of automatically adding maintainers to the nosy list, it would assist in "I just did a major cleanup of module X, are there any old bugs I can kill off"). Of course, it will take a while for the field to be filled in on existing issues, but even having it be possible would be very nice. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia --- ___ 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
[Python-Dev] Retrieve an arbitrary element from a set without removing it
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 the fastest. It nevertheless goes through all the iterator creation stuff, which costs some time. I wondered, why the builtin set does not provide a more direct and efficient way for retrieving some element without removing it. Is there any reason for this? I imagine something like x = some_set.get() or x = some_set.pop(False) and am thinking about providing a patch against setobject.c (preferring the .get() solution being a stripped down pop()). Before, I would like to know whether I have overlooked something or whether this can be done in an already existing way. Thanks, wr ___ 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
[Python-Dev] First shot at some_set.get()
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, stat2]:
t = Timer(stat, setup="s=set(range(1))") # outside the
try/except
try:
print t.timeit(number=1000)
except:
t.print_exc()
=
are
stat1: 0.0451760292053
stat2: 0.0148510932922
The patch is attached. Feel free to criticize.
I would love to see something like that in the standard Python interpreter.
Regards,
wr
Index: Objects/setobject.c
===
--- Objects/setobject.c (Revision 75593)
+++ Objects/setobject.c (Arbeitskopie)
@@ -757,6 +757,49 @@
PyDoc_STRVAR(pop_doc, "Remove and return an arbitrary set element.\n\
Raises KeyError if the set is empty.");
+static PyObject *
+set_get(PySetObject *so)
+{
+ register Py_ssize_t i = 0;
+ register setentry *entry;
+ PyObject *key;
+
+ assert (PyAnySet_Check(so));
+ if (so->used == 0) {
+ PyErr_SetString(PyExc_KeyError, "get from an empty set");
+ return NULL;
+ }
+
+ /* Set entry to "the first" unused or dummy set entry. We abuse
+ * the hash field of slot 0 to hold a search finger:
+ * If slot 0 has a value, use slot 0.
+ * Else slot 0 is being used to hold a search finger,
+ * and we use its hash value as the first index to look.
+ */
+ entry = &so->table[0];
+ if (entry->key == NULL || entry->key == dummy) {
+ i = entry->hash;
+ /* The hash field may be a real hash value, or it may be a
+ * legit search finger, or it may be a once-legit search
+ * finger that's out of bounds now because it wrapped around
+ * or the table shrunk -- simply make sure it's in bounds now.
+ */
+ if (i > so->mask || i < 1)
+ i = 1; /* skip slot 0 */
+ while ((entry = &so->table[i])->key == NULL || entry->key==dummy) {
+ i++;
+ if (i > so->mask)
+i = 1;
+ }
+ }
+ key = entry->key;
+Py_INCREF(key);
+ return key;
+}
+
+PyDoc_STRVAR(get_doc, "Return an arbitrary set element without removing it.\n\
+Raises KeyError if the set is empty.");
+
static int
set_traverse(PySetObject *so, visitproc visit, void *arg)
{
@@ -2043,6 +2086,8 @@
issuperset_doc},
{"pop", (PyCFunction)set_pop, METH_NOARGS,
pop_doc},
+ {"get", (PyCFunction)set_get, METH_NOARGS,
+ get_doc},
{"__reduce__", (PyCFunction)set_reduce, METH_NOARGS,
reduce_doc},
{"remove", (PyCFunction)set_remove, METH_O,
@@ -2355,6 +2400,16 @@
return set_pop((PySetObject *)set);
}
+PyObject *
+PySet_Get(PyObject *set)
+{
+ if (!PySet_Check(set)) {
+ PyErr_BadInternalCall();
+ return NULL;
+ }
+ return set_get((PySetObject *)set);
+}
+
int
_PySet_Update(PyObject *set, PyObject *iterable)
{
___
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
Re: [Python-Dev] First shot at some_set.get()
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. ___ 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
Re: [Python-Dev] Retrieve an arbitrary element from a set without removing it
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 items chosen randomly without replacement, use a list: L = list(some_set) x = random.choice(L) If you don't need a randomly chosen item, merely an arbitrary item, you can still use a list but avoid the call to random.choice: x = list(some_set)[0] > It nevertheless goes > through all the iterator creation stuff, which costs some time. I > wondered, why the builtin set does not provide a more direct and > efficient way for retrieving some element without removing it. Is > there any reason for this? I can see it being useful to iterate over the entire set, without removing anything. I can see it being useful to pop an arbitrary item, and remove it. But I can't see the use for retrieving an arbitrary item, leaving it in the set. What do you use this for? > I imagine something like > > x = some_set.get() > > or > > x = some_set.pop(False) > > and am thinking about providing a patch against setobject.c > (preferring the .get() solution being a stripped down pop()). -1 on .pop(flag) +0 on .get() -- Steven D'Aprano ___ 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
Re: [Python-Dev] First shot at some_set.get()
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 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 is it that the patch will still be applicable? -- Steven D'Aprano ___ 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
Re: [Python-Dev] First shot at some_set.get()
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 is it that the patch will still be > applicable? +1 on throwing it away completely even if it's a good idea. I suggest Willi go invent a new language (and hope for it to become popular :-) if he wants to experiment. --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%40mail-archive.com
Re: [Python-Dev] time.clock() on windows
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 keep the flow of time smooth (no > > backwards jumps because of corrections.). An optimal solution has so > > far eluded me. > > That sounds very similar to the problem spec for system time > corrections > in Network Time Protocol client implementations. Perhaps the time > drifting algorithms in the NTP specs are relevant? Or are they too slow > to correct discrepancies? K ___ 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
Re: [Python-Dev] language summit topic: issue tracker
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 is part of the review and doesn't need a specific indicator IMO. Besides, the more keywords there are, the messier it is. ___ 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
Re: [Python-Dev] First shot at some_set.get()
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 >> 2013 or later. How likely is it that the patch will still be >> applicable? > > > +1 on throwing it away completely even if it's a good idea. I suggest > Willi go invent a new language (and hope for it to become popular :-) > if he wants to experiment. Careful folks - these kinds of throwaway comments may be clearly tongue in cheek for anyone following the moratorium discussion on python-ideas, but will be justifiably confusing to anyone else, especially newcomers. Willi - Oleg is right that patches should go on the issue tracker. They tend to get lost if they only exist on the mailing list. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia --- ___ 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
Re: [Python-Dev] language summit topic: issue tracker
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 issue tracker and Rietveld would be beneficial. If someone attaches a patch to an issue the current next step is essentially a code review without the benefits provided by a code review tool. I'd envision a bit of workflow like this: * A patch is attached to an issue. * The user clicks the "Create Review" button. (Maybe not all patches require review?) * This generates a review request in Rietveld with all on the nosy list invited as reviewers. (Or should this be a side effect of attaching a patch?) * The "needs review" keyword is added to the selected keywords. * A link to the review request is added as a comment to the issue so other people not on the nosy list can evaluate the patch. * If an updated diff is uploaded the review request would be updated. That might necessitate adding a "Replace Patch" button next to all uploaded patches instead of adding a new one then deleting a previous one. Skip ___ 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
Re: [Python-Dev] language summit topic: issue tracker
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. But if you don't think "stage" is needed, I'd say drop it entirely rather than demote it to keywords. Keywords themselves are rather confusing to non-tracker-hackers, anyway. A lot of people seem to think anything that occurs to them should be allowed. That's not true in Roundup, you need to register a keyword before using it. In the XEmacs tracker I don't allow non-committers to do that. I'm open to changing that policy, but as yet I haven't seen a keyword suggestion from a non-committer that either (1) helps the committers to do their work or (2) seems likely to help users find relevant bugs. The suggestions are always of the form "it would make the interface more complete/consistent." So I'm going to maintain editorial control for now ___ 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
Re: [Python-Dev] Volunteer needed to organize summits
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
[Python-Dev] Summary of Python tracker Issues
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 duration of open issues: 673 days. Median duration of open issues: 428 days. Open Issues Breakdown open 2436 (+27) pending37 ( +0) Issues Created Or Reopened (43) ___ regrtest -j sometimes fails if output gets written to stderr by 10/16/09 CLOSED http://bugs.python.org/issue7151created r.david.murray patch, patch urllib2.build_opener() skips ProxyHandler10/16/09 http://bugs.python.org/issue7152created barry add "start" arg to max and min functions 10/16/09 CLOSED http://bugs.python.org/issue7153created phr urllib.request system proxy configuration lookup broken for OS X 10/16/09 http://bugs.python.org/issue7154created ned.deily urllib2 and python 3 urllib do not document default use of syste 10/16/09 CLOSED http://bugs.python.org/issue7155created ned.deily patch curses can't find _curses10/17/09 CLOSED http://bugs.python.org/issue7156created Archon Fix Download Current Documentation link 10/17/09 http://bugs.python.org/issue7157created ryles os.path.basename/split fails 10/17/09 CLOSED http://bugs.python.org/issue7158created kuiper Urllib2 authentication memory. 10/17/09 http://bugs.python.org/issue7159created bradobro Crash when returning a 64-bit char pointer in Python 2.6.3 ctype 10/17/09 CLOSED http://bugs.python.org/issue7160created creachadair raise of SyntaxError in codeop was ported incorrectly to Py3 10/17/09 CLOSED http://bugs.python.org/issue7161created Trundle patch 2to3 does not convert __builtins__.file 10/17/09 http://bugs.python.org/issue7162created joe.amenta IDLE suppresses sys.stdout.write() return value 10/17/09 http://bugs.python.org/issue7163created tjreedy pickle test failure after test_imp/test_import (_make_stat_resul 10/18/09 CLOSED http://bugs.python.org/issue7164created r.david.murray xmlrpc.server assumes sys.stdout will have a buffer attribute10/18/09 http://bugs.python.org/issue7165created ncoghlan patch IDLE (python 3.1.1) syntax coloring for b'bytestring' and u'unic 10/18/09 http://bugs.python.org/issue7166created lieryan easy Smarter FTP passive mode 10/18/09 http://bugs.python.org/issue7167created pitrou patch Document PyFloat_AsString and PyFloat_AsReprString as deprecated 10/19/09 CLOSED http://bugs.python.org/issue7168created eric.smith patch zipfile leaves a file handle open if file is zero size 10/19/09 http://bugs.python.org/issue7169created skelker
Re: [Python-Dev] Volunteer needed to organize summits
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.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog ___ 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
Re: [Python-Dev] Retrieve an arbitrary element from a set without removing it
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 = iter(some_set).next() > > > Of course, the third should be the fastest. It nevertheless goes through all > the iterator creation stuff, which costs some time. I wondered, why the > builtin > set does not provide a more direct and efficient way for retrieving some > element > without removing it. Is there any reason for this? > > I imagine something like > > x = some_set.get() > I see this as being useful for frozensets as well, where you can't get an arbitrary element easily due to the obvious lack of .pop(). I ran into this recently, when I had a frozenset that I knew had 1 element (it was the difference between 2 other sets), but couldn't get to that element easily (get the pun?) ___ 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
Re: [Python-Dev] time.clock() on windows
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;
double clock()
{
__int64 cnt, hz, init;
double us;
union __reftime ref_filetime;
union __reftime ref_perftime;
for (;;) {
ref_filetime.bits = __ref_filetime.bits;
ref_perftime.bits = __ref_perftime.bits;
if(!QueryPerformanceCounter((LARGE_INTEGER*)&cnt)) goto error;
if(!QueryPerformanceFrequency((LARGE_INTEGER*)&hz)) goto error;
us = ref_filetime.us + ((double)(100*cnt)/(double)hz -
ref_perftime.us);
/* verify that values did not change */
init = InterlockedCompareExchange64((LONGLONG*)&__ref_filetime.bits,
(LONGLONG)ref_filetime.bits,
(LONGLONG)ref_filetime.bits);
if (init != ref_filetime.bits) continue;
init = InterlockedCompareExchange64((LONGLONG*)&__ref_perftime.bits,
(LONGLONG)ref_perftime.bits,
(LONGLONG)ref_perftime.bits);
if (init == ref_perftime.bits) break;
}
return us;
error:
/* only if there is no performance counter */
return -1; /* or whatever */
}
int periodic_reftime_check()
{
/* call this function at regular intervals, e.g. once every second
*/
__int64 cnt1, cnt2, hz;
FILETIME systime;
double ft;
if(!QueryPerformanceFrequency((LARGE_INTEGER*)&hz)) goto error;
if(!QueryPerformanceCounter((LARGE_INTEGER*)&cnt1)) goto error;
GetSystemTimeAsFileTime(&systime);
__ref_filetime.us = (double)(__int64)(systime.dwHighDateTime))
<< 32)
| ((__int64)(systime.dwLowDateTime)))/10);
if(!QueryPerformanceCounter((LARGE_INTEGER*)&cnt2)) goto error;
__ref_perftime.us = 50*(cnt1 + cnt2)/((double)hz);
return 0;
error:
/* only if there is no performance counter */
return -1;
}
___
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
Re: [Python-Dev] Retrieve an arbitrary element from a set without removing it
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_set: >>break >> >> 3. >> x = iter(some_set).next() >> >> >> Of course, the third should be the fastest. It nevertheless goes through all >> the iterator creation stuff, which costs some time. I wondered, why the >> builtin >> set does not provide a more direct and efficient way for retrieving some >> element >> without removing it. Is there any reason for this? >> >> I imagine something like >> >> x = some_set.get() >> > > > I see this as being useful for frozensets as well, where you can't get > an arbitrary element easily due to the obvious lack of .pop(). I ran > into this recently, when I had a frozenset that I knew had 1 element > (it was the difference between 2 other sets), but couldn't get to that > element easily (get the pun?) So in my testing (2) was actually the fastest. I assumed because .next() was a function call overhead, while: for x in some_set: break Was evaluated inline. It probably still has to call PyObject_GetIter, however it doesn't have to create a stack frame for it. This is what "timeit" tells me. All runs are of the form: python -m timeit -s "s = set([10])" ... 0.101us "for x in s: break; x" 0.130us "for x in s: pass; x" 0.234us -s "n = next; i = iter" "x = n(i(s)); x" 0.248us "x = next(iter(s)); x" 0.341us "x = iter(s).next(); x" 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? Note that all of these are significantly < 1us. So this only matters if it is something you are doing often. I don't know your specific timings, but I would guess that: for x in s: break Is actually going to be faster than your s.get() Primarily because s.get() requires an attribute lookup. I would think your version might be faster for: stat2 = "g = s.get; for i in xrange(100): g()" However, that is still a function call, which may be treated differently by the interpreter than the for:break loop. I certainly suggest you try it and compare. John =:-> ___ 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
Re: [Python-Dev] nonlocal keyword in 2.x?
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 > ? > > Is that still a current plan? It's from November 2008. > > Django 1.1 came out in 2H09, not 1H09, and Django 1.2 is now looking to come out in 1H10, not 2H09, so the dates in that note have slipped out by 3-6 months. (The labeling of some features as must-have for a release has been dropped for 1.2, so as to hopefully prevent the kind of slip seen with 1.1.) Django 1.2 is still scheduled to drop Python 2.3 support. I think it's too early to say whether Python 2.4 support will be dropped with 1.3, nor do I have any good idea when supporting 3.x will become a priority. Karen ___ 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
Re: [Python-Dev] Retrieve an arbitrary element from a set without removing it
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 has to end normally, whereas the break form exits prematurely. Paul. ___ 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
Re: [Python-Dev] Retrieve an arbitrary element from a set without removing it
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 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
Re: [Python-Dev] Retrieve an arbitrary element from a set without removing it
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 through *all* the elements in s and leaves x bound to the arbritrary *last* one instead of the arbitrary *first* one. For a large set, this would be a lot slower, not just a little. fwiw, I think the use case for this is sufficiently rare that it does not need a separate method just for this purpose. tjr ___ 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
Re: [Python-Dev] Bug 7183 and Python 2.6.4
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. Otherwise... there's always 2.6.5! :) -Barry PGP.sig Description: This is a digitally signed message part ___ 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
Re: [Python-Dev] Retrieve an arbitrary element from a set without removing it
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? > > for x in s: pass > > iterates through *all* the elements in s and leaves x bound to the > arbritrary *last* one instead of the arbitrary *first* one. For a large > set, this would be a lot slower, not just a little. > > fwiw, I think the use case for this is sufficiently rare that it does > not need a separate method just for this purpose. > > tjr 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. Certainly the difference is huge if there are 10k items in the set. John =:-> ___ 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
Re: [Python-Dev] Retrieve an arbitrary element from a set without removing it
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(1000): \n\tfor x in s: \n\t\tbreak", "for i in xrange(1000): s.add(s.pop()) ", "for i in xrange(1000): s.get() "] for stat in stats: t = Timer(stat, setup="s=set(range(100))") try: print "Time for %s:\t %f"%(stat, t.timeit(number=1000)) except: t.print_exc() $ ./test_get.py Time for for i in xrange(1000): iter(s).next() : 0.433080 Time for for i in xrange(1000): for x in s: break: 0.148695 Time for for i in xrange(1000): s.add(s.pop()) : 0.317418 Time for for i in xrange(1000): s.get() : 0.146673 In some tests, for/break was even slightly faster then get(). As always, intuition regarding performance bottlenecks is flawed ;-) Anyway, thanks for all the helpful comments, especially to Stefan for the http://comments.gmane.org/gmane.comp.python.ideas/5606 link. Regards, wr Am Freitag, 23. Oktober 2009 19:25:48 schrieb John Arbash Meinel: > 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_set: > >>break > >> > >> 3. > >> x = iter(some_set).next() > >> > >> > >> Of course, the third should be the fastest. It nevertheless goes through > >> all the iterator creation stuff, which costs some time. I wondered, why > >> the builtin set does not provide a more direct and efficient way for > >> retrieving some element without removing it. Is there any reason for > >> this? > >> > >> I imagine something like > >> > >> x = some_set.get() > > > > I see this as being useful for frozensets as well, where you can't get > > an arbitrary element easily due to the obvious lack of .pop(). I ran > > into this recently, when I had a frozenset that I knew had 1 element > > (it was the difference between 2 other sets), but couldn't get to that > > element easily (get the pun?) > > So in my testing (2) was actually the fastest. I assumed because .next() > was a function call overhead, while: > for x in some_set: > break > > Was evaluated inline. It probably still has to call PyObject_GetIter, > however it doesn't have to create a stack frame for it. > > This is what "timeit" tells me. All runs are of the form: > python -m timeit -s "s = set([10])" ... > > 0.101us "for x in s: break; x" > 0.130us "for x in s: pass; x" > 0.234us -s "n = next; i = iter" "x = n(i(s)); x" > 0.248us "x = next(iter(s)); x" > 0.341us "x = iter(s).next(); x" > > 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? > > Note that all of these are significantly < 1us. So this only matters if > it is something you are doing often. > > I don't know your specific timings, but I would guess that: > for x in s: break > > Is actually going to be faster than your > s.get() > > Primarily because s.get() requires an attribute lookup. I would think > your version might be faster for: > stat2 = "g = s.get; for i in xrange(100): g()" > > However, that is still a function call, which may be treated differently > by the interpreter than the for:break loop. I certainly suggest you try > it and compare. > > John > =:-> > ___ 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
Re: [Python-Dev] Retrieve an arbitrary element from a set without removing it
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 you suggested that the difference may have been because of a
potential "else" statement. That won't be it: if there's no "else" in
the code, it's not compiled in:
>>> import dis
>>> dis.dis(compile("for x in s: break", "", "exec"))
1 0 SETUP_LOOP 15 (to 18)
3 LOAD_NAME0 (s)
6 GET_ITER
>>7 FOR_ITER 7 (to 17)
10 STORE_NAME 1 (x)
13 BREAK_LOOP
14 JUMP_ABSOLUTE7
>> 17 POP_BLOCK
>> 18 LOAD_CONST 0 (None)
21 RETURN_VALUE
>>>
>>> dis.dis(compile("for x in s: pass", "", "exec"))
1 0 SETUP_LOOP 14 (to 17)
3 LOAD_NAME0 (s)
6 GET_ITER
>>7 FOR_ITER 6 (to 16)
10 STORE_NAME 1 (x)
13 JUMP_ABSOLUTE7
>> 16 POP_BLOCK
>> 17 LOAD_CONST 0 (None)
20 RETURN_VALUE
The difference is likely to be this:
for x in s: break
retrieves the first (only) element of the set, then immediately breaks
out of the loop. This is very different from:
for x in s: pass
which retrieves the first element of the set, then tries to retrieve a
second element, which fails and raises StopIteration, which is then
caught, ending the loop. That's much more expensive.
--
Steven D'Aprano
___
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
Re: [Python-Dev] Retrieve an arbitrary element from a set without removing it
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 with a potential "else:" > > statement? > > for x in s: pass > > iterates through *all* the elements in s and leaves x bound to the > arbritrary *last* one instead of the arbitrary *first* one. For a > large set, this would be a lot slower, not just a little. > > 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 think it has a use-case. I did ask earlier for a use-case, and the OP hasn't replied, but Vitor Bosshard did point out one of his use-cases: he had the difference between two frozensets, which he knew had only one element, but due to the lack of pop() he had no straightforward way of finding out what that element was. 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 ___ 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
Re: [Python-Dev] time.clock() on windows
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. ___ 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
Re: [Python-Dev] Retrieve an arbitrary element from a set without removing it
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. According to your tests, your implementation of get() is as fast as "for x in set: break", and it's certainly much, much more readable and straightforward. -- Steven D'Aprano ___ 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
Re: [Python-Dev] Retrieve an arbitrary element from a set without removing it
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 think it has a use-case. The desire for this may be obvious, but what seems to be lacking is One Obvious Way to Do It. I agree that ‘for x in foo_set: break’ is not an Obvious Way. > 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’? If it's the value, that makes it rather non-obvious; if I already know about ‘dict.get’ which takes the key, I'm not going to be thinking about the ‘get’ method if I don't have a key to feed it. Once I learn it, I'm going to forget it easily, because it's inconsistent with ‘dict.get’. So I don't think that meets the “obvious way” criterion. By analogy with ‘list.pop’, the method that takes the “top” item off the “stack”, I would expect to see ‘list.peek’ and ‘set.peek’, to see the item without altering the container. -- \“Odious ideas are not entitled to hide from criticism behind | `\ the human shield of their believers' feelings.” —Richard | _o__) Stallman | Ben Finney ___ 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
Re: [Python-Dev] First shot at some_set.get()
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-ins, it is likely to just sit in the tracker, > >> forgotten, until 2013 or later. How likely is it that the patch > >> will still be applicable? > > > > +1 on throwing it away completely even if it's a good idea. I > > suggest Willi go invent a new language (and hope for it to become > > popular :-) if he wants to experiment. > > Careful folks - these kinds of throwaway comments may be clearly > tongue in cheek for anyone following the moratorium discussion on > python-ideas, but will be justifiably confusing to anyone else, > especially newcomers. 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? A lot can change between now and 2013, and I for one wouldn't bother making a patch that I knew wouldn't even be considered for inclusion for four years, and would likely need to be re-done even if it was accepted. Guido has said that the purpose of the moratorium is to discourage changes to the language. If we're discouraging changes, shouldn't we actually discourage them rather than waste people's time and give them false hope by telling them to put them in the tracker? Nick, you made the comparison with C in another thread. I don't think that the comparison with C is apt, for various reasons, but putting that aside, given that C is so stable, what do they do with suggested changes to the language? Is there a C issue tracker with ten years of accumulated patches, or even proposals, in the queue? -- Steven D'Aprano ___ 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
Re: [Python-Dev] Retrieve an arbitrary element from a set without removing it
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, again and again... obviously people > > using sets in code think it has a use-case. > > The desire for this may be obvious, but what seems to be lacking is > One Obvious Way to Do It. > > I agree that ‘for x in foo_set: break’ is not an Obvious Way. > > > 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 take any input. > If it's the value, that makes it rather non-obvious; It makes it pointless if it takes the value. If you already have the value, why would you need to retrieve it from the set? > if I already > know about ‘dict.get’ which takes the key, I'm not going to be > thinking about the ‘get’ method if I don't have a key to feed it. > Once I learn it, I'm going to forget it easily, because it's > inconsistent with ‘dict.get’. So I don't think that meets the > “obvious way” criterion. "get" is such a generic term that I don't believe that is a problem. There are already quite a number of get() methods in the 2.6 std lib: $ grep "def get[(]" *.py _abcoll.py:def get(self, key, default=None): ConfigParser.py:def get(self, section, option): ConfigParser.py:def get(self, section, option, raw=False, vars=None): doctest.py:def get(self): mailbox.py:def get(self, key, default=None): os.py:def get(self, key, failobj=None): pickle.py:def get(self, i, pack=struct.pack): Queue.py:def get(self, block=True, timeout=None): shelve.py:def get(self, key, default=None): sre_parse.py:def get(self): threading.py:def get(self): UserDict.py:def get(self, key, failobj=None): UserDict.py:def get(self, key, default=None): weakref.py:def get(self, key, default=None): weakref.py:def get(self, key, default=None): webbrowser.py:def get(using=None): I think you over-estimate the degree of confusion people suffer from similar sounding methods. I don't think people are confused that dict[key] and list[index] have different semantics, and I don't see why dict.get(key[, default]) and set.get() would be any different. But if you don't like get(), spell it differently. There's plenty of opportunity for bike-shedding: getitem() getelement() get_arbitrary_element() peek() etc. > By analogy with ‘list.pop’, the method that takes the “top” item off > the “stack”, I would expect to see ‘list.peek’ and ‘set.peek’, to see > the item without altering the container. You don't need list.peek() because there already is an obvious way to retrieve an item from a list without removing it: list[index]. -- Steven D'Aprano ___ 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
Re: [Python-Dev] Retrieve an arbitrary element from a set without removing it
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 take any input. That is even less obvious. 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. > "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?”. Whereas ‘foo_set.get()’ doesn't communicate much at all to the reader. If we want a method that gets one item from a set, perhaps the name can make it clearer: name it ‘set.getitem’. But which item should it get? The ‘__getitem__’ special method of lists and dictionaries requires an index or key as parameter. -- \ “Roll dice!” “Why?” “Shut up! I don't need your fucking | `\ *input*, I need you to roll dice!” —Luke Crane, demonstrating | _o__) his refined approach to play testing, 2009 | Ben Finney ___ 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
Re: [Python-Dev] Retrieve an arbitrary element from a set without removing it
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. > > > > > > What would be the input to ‘set.get’? > > > > It wouldn't take any input. > > That is even less obvious. 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 you call that returns the set you already have? A method called "get" obviously gets something, and if it takes no arguments the only thing is has access to is the set. The obvious things it could get are the set as a whole or some part of the set. Since getting the set as a whole would be pointless, and we're allowed to assume that the language designers aren't lunatics who would waste time creating pointless methods, the obvious answer is that it gets some part of the set. Since there's no obvious reason to choose one subset over another subset, the only useful thing it could return is a single arbitrary item. But if you're not willing to guess what it gets, you are permitted to read the docstring. > > "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?”. Whereas ‘foo_set.get()’ doesn't communicate > much at all to the reader. You are demanding a level of intuitiveness that few, if any, functions in the standard library would be able to meet. Consider list.index(x): would you expect it to return the value at index x, or the index of value x? Either description is compatible with the name, and in fact people sometimes mix them up. Or sorted() -- from the name alone, I'd expect this to work, but it doesn't: >>> sorted(1, 2, 3) Traceback (most recent call last): File "", line 1, in TypeError: 'int' object is not iterable That's not a problem with the built-in function. I took a guess about the API, and guessed wrong. I'll learn from this, and get it right next time. > If we want a method that gets one item from a set, perhaps the name > can make it clearer: name it ‘set.getitem’. But which item should it > get? The ‘__getitem__’ special method of lists and dictionaries > requires an index or key as parameter. Neither of which is appropriate for sets -- sets are unordered, so elements don't have indexes, and they don't map keys to values. They just have elements. Sets are not lists, and they're not dicts. Analogies only go so far, and you can't reason about set methods by considering how lists or dicts will behave. -- Steven D'Aprano ___ 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
Re: [Python-Dev] Retrieve an arbitrary element from a set without removing it
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 you call > that returns the set you already have? Exactly, hence the confusion. I think the method name ‘set.get’ is poor for that reason. > A method called "get" obviously gets something, and if it takes no > arguments the only thing is has access to is the set. The obvious > things it could get are the set as a whole or some part of the set. Which then raises the question “what part of the set does it get?”, which the function signature does nothing to answer. I'm proposing that a no-parameters ‘set.get’ is needlessly confusing to think about. > Since there's no obvious reason to choose one subset over another > subset, the only useful thing it could return is a single arbitrary > item. That's not at all obvious, IMO. The name doesn't give much help at all in getting to that conclusion, and isn't easily associated with that connotation. > You are demanding a level of intuitiveness that few, if any, functions > in the standard library would be able to meet. I'm not demanding intuitiveness; all programming interfaces are learned. I'm asking for ease of learning and later recall. > That's not a problem with the built-in function. I took a guess about > the API, and guessed wrong. I'll learn from this, and get it right > next time. Which is partly my point. Such a narrow use case (“get an arbitrary item from the set, without specifying anything about what that item might be”) is a mismatch for such a generic name. It makes it unnecessarily difficult to make the association. Since the use case is so specific, I would expect the name to be specific too, to better match the use case. (Since I know how your mind works, I can anticipate facetious fifty-character-long names bubbling up already in a response from you. Let's just assume that joke is already done :-) -- \ “Holy tintinnabulation, Batman!” —Robin | `\ | _o__) | Ben Finney ___ 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
Re: [Python-Dev] First shot at some_set.get()
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 least in principle) encouraged where the core project decides that the proposed changes are inappropriate (or should be deferred, as here). Nevertheless, isn't the core Python project the obvious common point of contact for sharing such ideas, even if there is a moratorium on the code base itself? I know that a few patches to Mailman have lived for nearly a decade, beloved by their users and not (much) bothering the Mailman maintainers with their obvious pitfalls for naive users. Whether the tracker is the appropriate place is another question, but I think it's easier to search for "serious proposal with patch" than the mailing lists. ___ 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
[Python-Dev] tokenize string literal problem
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 rather and that method automatically
loads everything from the module containing the code.)
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.py:
+
def bar():
"""
A quoted triple quote is not a closing
of this docstring:
>>> print '"""'
"""
""" # <-- this is the closing quote
pass
+
Here is how I tokenize the file:
###
import re, tokenize
DOCSTRING_START_RE = re.compile('\s+[ru]*("""|' + "''')")
o=open('foo.py','r')
for ti in tokenize.generate_tokens(o.next):
typ = ti[0]
text = ti[-1]
if typ == tokenize.STRING:
if DOCSTRING_START_RE.match(text):
print "DOCSTRING:",repr(text)
o.close()
###
which outputs:
DOCSTRING: '"""\nA quoted triple quote is not a closing\nof this
docstring:\n>>> print \'"""\'\n'
DOCSTRING: '"""\n""" # <-- this is the closing quote\n'
There should be only one string tokenized, I believe. The PythonWin editor
parses (and colorizes) this correctly, but tokenize (or I) are making an error.
Thanks for any help,
Chris
___
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
Re: [Python-Dev] Retrieve an arbitrary element from a set without removing it
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?". Whereas 'foo_set.get()' doesn't communicate much > at all to the reader. I agree. This is precisely why a couple of months ago people were proposing names like ".getany()" for this API. The problem brought up then was that pretty clearly people would then do things like x = foo.getany() y = foo.getany() expecting x and y to be different (ie, interpreting "any" as "random"). Pretty soon there was a whole family of proposals for such methods: .getfirst(), .getlast(), .getrandom(), .getonly(), I think it would be better to document the various ways of doing this, and let each program define its own oneliner for the MySet.get() that makes idiomatic sense in its use case. ___ 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
Re: [Python-Dev] tokenize string literal problem
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.py: > + > def bar(): > """ > A quoted triple quote is not a closing > of this docstring: > >>> print '"""' > """ > """ # <-- this is the closing quote > pass > + > I now see that I've created a code snippet that is invalid. Myopia. The thing that pythonWin was doing correctly was displaying my sample STRING not code. I had delimited the code with triple-single-quotes so it showed up correctly. In fact, if entered as code it would show the need to delimit the docstring contents with ''' rather than """. Sorry! /c ___ 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
