[Python-Dev] Long options support
I've just closed a bug report wishing for long option support, pointing to a patch sitting in the patch tracker implementing this. Should we accept at least the very common options "--help" and "--version" in 2.5? Georg ___ 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] Long options support
Georg Brandl wrote: > I've just closed a bug report wishing for long option support, > pointing to a patch sitting in the patch tracker implementing > this. > > Should we accept at least the very common options "--help" and > "--version" in 2.5? Guido pronounced on this in May: "Guido van Rossum" <[EMAIL PROTECTED]> wrote: > On 5/4/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote: > > I'm +1 on adding --help and --version, +1 on adding -? and /? for windows only, > > -0=slightly sceptical if adding a generic long option machinery is worth it, and -1 > > on a guessing machinery. > > I fully support Fredrik's position on this issue. > > --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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] Scoping vs augmented assignment vs sets (Re: 'fast locals' in Python 2.5)
Terry Reedy wrote: > "Boris Borcic" <[EMAIL PROTECTED]> wrote in message > news:[EMAIL PROTECTED] > >> being transformed to profit from simplifications I expected sets to allow. >> There, itemwise augmented assigments in loops very naturally transform to >> wholesale augmented assignments without loops. Except for this wart. > > Your transformation amounted to switching from collection mutation to > object rebinding. In Python, that is a crucial difference. Ok, that is a crucial difference. The question becomes : is that difference in the case of augmented assignment maintained for practical or for purity aka ideological reasons ? > That the > mutation and rebinding were both done with augmented assignments is not > terribly important except as this masks the difference. When *you* read > your code, you know that you will only call the inner function with a > mutable collection object, so you know that the name will be rebound to the > same object after mutation, so you can think of the augmented assignment as > being the same as collection mutation. Not quite. When I read my code (and while I transform it) I know (as an invariant) that nowhere in my function do I initially bind a value to my variable, and I know that it can't be done with augmented assignments, and I know that no working code can /ever/ result from letting a function-local scope capture a name /just/ because it is the target of an augmented assignment. So, when despite this obvious certainty the compiler translates my code to something that can't possibly run while it happily translates x+=1 and x=x+1 to different bytecodes with no qualms about x possibly being bound to an immutable, well, I do feel victim of something like a hidden agenda. > > But the compiler does not know any such thing about the target of the > augmented assignment and must therefore treat the statement as an > assigment. It was a bug for a2 to do otherwise, even though the bug was > locally optimal for this particular usage. I must thank you for the effort of elaborating a polite and consistent explanation that was almost to the point and believable. Regards, Boris Borcic -- "On naît tous les mètres du même monde" ___ 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] Scoping vs augmented assignment vs sets (Re: 'fast locals' in Python 2.5)
Josiah Carlson wrote: > You seem to not realize that these different use-cases. Your new > example involves a global variable that is *shared* among everyone that > knows about this particular module. It also is repaired by a simple > insertion of 'global freebits' at the beginning of the search function. My point here : a simple repair, and by a statement that amounts to a compiler directive with no other effect than obtaining my intent in bytecodes, so that "all other things being equal" comparisons of code versions remain possible (recall that I was studying the impact on working code of adopting sets - including performance). > The closure/class example is merely a method of encapsulating state, > which I find easier to define, describe, and document than the closure > version. Your priviledge of course (and I am not saying it is misguided, although I would in particular argue that the matter gets debatable in the low LOC-count limit). (I am also wondering about performance comparisons). > Back in February, there was a discussion about allowing people to > 'easily' access and modify variables defined in lexically nested scopes, > but I believed then, as I believe now, that such attempted uses of > closures are foolish when given classes. Given the *trivial* conversion > of your closure example to a class, and my previous comments on closures > "I find their use rarely, if ever, truely elegant, [...] more like > kicking a puppy for barking: [...] there are usually better ways of > dealing with the problem (don't kick puppies for barking and don't use > closures).", you are not likely to find me agreeing with you about > augmented assignment and/or lexically nested scopes. I see. Thanks for the background. Background for backround, let me just say that python hadn't yet grown a lambda when I first played with it. May I read your last statement as acknowledging that I am not so much asking for a door to be created, than asking for a naturally builtin door, not to be locked by special efforts ? Regards, Boris Borcic -- "On naît tous les mètres du même monde" ___ 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] High Level Virtual Machine
I thought this announcement was interesting: http://hlvm.org/ ___ 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] Improve error msgs?
Hi Georg,
On Wed, Jun 14, 2006 at 08:51:03AM +0200, Georg Brandl wrote:
> type_error("object does not support item assignment");
>
> It helps debugging if the object's type was prepended.
> Should I go through the code and try to enhance them
> where possible?
I think it's an excellent idea.
Armin
___
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] sqlite3 test errors - was : Re: [Python-checkins] r46936 - in python/trunk: Lib/sqlite3/test/regression.py Lib/sqlite3/test/types.py Lib/sqlite3/test/userfunctions.py Modules/_sqlite/conn
Co-posting to python-dev in the hope of getting help of people verifying my suspicion ... Gerhard Häring wrote: > [...] > For some reason, they don't seem to have picked up the changed tests of > the sqlite3 module. At least the error messages look exactly like the > ones I had when I ran the current code against old tests. That guess was wrong. The failed sqlite3 tests come from an old SQLite version being linked against. Until recently, SQLite was buggy and it was only fixed in http://www.sqlite.org/cvstrac/chngview?cn=2981 that callbacks can throw errors that are usefully returned to the original caller. The tests for the sqlite3 module currently assume a recent version SQLite (3.3.something). Otherwise some tests will fail. Still, it can be built against any SQLite 3 release. Can somebody please also verify if the malloc/free error message goes away (it really only happened on Mac, didn't it?) if you upgrade SQLite to the latest version on the build host? -- Gerhard ___ 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] [Python-checkins] sqlite3 test errors - was : Re: r46936 - in python/trunk: Lib/sqlite3/test/regression.py Lib/sqlite3/test/types.py Lib/sqlite3/test/userfunctions.py Modules/_sqlite/
Gerhard Häring wrote:
Co-posting to python-dev in the hope of getting help of people verifying
my suspicion ...
Gerhard Häring wrote:
[...]
For some reason, they don't seem to have picked up the changed tests of
the sqlite3 module. At least the error messages look exactly like the
ones I had when I ran the current code against old tests.
That guess was wrong. The failed sqlite3 tests come from an old SQLite
version being linked against. Until recently, SQLite was buggy and it
was only fixed in
http://www.sqlite.org/cvstrac/chngview?cn=2981
that callbacks can throw errors that are usefully returned to the
original caller.
The tests for the sqlite3 module currently assume a recent version
SQLite (3.3.something). Otherwise some tests will fail.
Still, it can be built against any SQLite 3 release.
Can somebody please also verify if the malloc/free error message goes
away (it really only happened on Mac, didn't it?) if you upgrade SQLite
to the latest version on the build host?
With SQLite 3.2.8, I also get segfaults on Linux x86 (Ubuntu dapper, gcc).
I've provided a preliminary patch (cannot check in from this place) that
I've attached. Maybe somebody wants to test it, otherwise I'll make a
few other tests in the late evening and probably also selectively
disable certain tests in the test suite if the SQLite version is too old
to pass them.
-- Gerhard
Index: Modules/_sqlite/connection.c
===
--- Modules/_sqlite/connection.c(revision 46958)
+++ Modules/_sqlite/connection.c(working copy)
@@ -34,6 +34,16 @@
static int connection_set_isolation_level(Connection* self, PyObject*
isolation_level);
+
+void _sqlite3_result_error(sqlite3_context* ctx, const char* errmsg, int len)
+{
+#if SQLITE_VERSION_NUMBER >= 3003003
+sqlite3_result_error(ctx, errmsg, len);
+#else
+/* sqlite3_result_null(ctx); */
+#endif
+}
+
int connection_init(Connection* self, PyObject* args, PyObject* kwargs)
{
static char *kwlist[] = {"database", "timeout", "detect_types",
"isolation_level", "check_same_thread", "factory", "cached_statements", NULL,
NULL};
@@ -526,7 +536,7 @@
} else {
PyErr_Clear();
}
-sqlite3_result_error(context, "user-defined function raised
exception", -1);
+_sqlite3_result_error(context, "user-defined function raised
exception", -1);
}
PyGILState_Release(threadstate);
@@ -558,7 +568,7 @@
} else {
PyErr_Clear();
}
-sqlite3_result_error(context, "user-defined aggregate's '__init__'
method raised error", -1);
+_sqlite3_result_error(context, "user-defined aggregate's
'__init__' method raised error", -1);
goto error;
}
}
@@ -582,7 +592,7 @@
} else {
PyErr_Clear();
}
-sqlite3_result_error(context, "user-defined aggregate's 'step' method
raised error", -1);
+_sqlite3_result_error(context, "user-defined aggregate's 'step' method
raised error", -1);
}
error:
@@ -619,7 +629,7 @@
} else {
PyErr_Clear();
}
-sqlite3_result_error(context, "user-defined aggregate's 'finalize'
method raised error", -1);
+_sqlite3_result_error(context, "user-defined aggregate's 'finalize'
method raised error", -1);
} else {
_set_result(context, function_result);
}
___
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] Scoping vs augmented assignment vs sets (Re: 'fast locals' in Python 2.5)
"Boris Borcic" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] Terry Reedy wrote: >> Your transformation amounted to switching from collection mutation to >> object rebinding. In Python, that is a crucial difference. >Ok, that is a crucial difference. The question becomes : is that >difference in >the case of augmented assignment maintained for practical or for purity >aka >ideological reasons ? Consistency. a op=b is almost the same as a = a op b except 1) 'a' is computed only once and 2) if a is mutable, type(a) may choose to do op in place via the call to __iop__ instead of __op__. But in any case, the assigment is made and 'a', if a name, is bound to the result. Anyway, this will not change for 2.x and further discussion is really c.l.p. material. Terry Jan Reedy ___ 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] Scoping vs augmented assignment vs sets (Re: 'fast locals' in Python 2.5)
Josiah Carlson wrote: > The closure/class example is merely a method of encapsulating state, > which I find easier to define, describe, and document than the closure > version. In the case of the code discussed, eg the actual model of def solve(problem) : freebits = set(range(N)) def search(data) : freebits ^= swap ... search(initial_data) ... the closure isn't used to encapsulate state if what you mean is passing "search" around as an interface to said state - search() is only for internal consumption and in fact exists only because of a quite opposite reason. Namely, the search requires copying parts of the state and this is most easily expressed with a recursive "search" inner function whose parameters are the copied parts. Whatever you say, it doesn't feel adequate to me nor particularly clear to reify such a recursive inner abstraction as an object method. Especially in Python, I can't help reading the methods of a class declaration as intended primarily to define an external interface, which is misleading in this case. I'd say a first step in convincing me I am wrong would be to show me examples of object methods of the standard library that are recursive, and cut out for recursion. Regards, Boris Borcic -- "On naît tous les mètres du même monde" ___ 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] Switch statement
Thomas Lee wrote: > On Mon, Jun 12, 2006 at 11:33:49PM +0200, Michael Walter wrote: >> Maybe "switch" became a keyword with the patch.. >> >> Regards, >> Michael >> > > That's correct. > >> On 6/12/06, M.-A. Lemburg <[EMAIL PROTECTED]> wrote: >>> Could you upload your patch to SourceForge ? Then I could add >>> it to the PEP. >>> > > It's already up there :) I thought I sent that through in another > e-mail, but maybe not: > > http://sourceforge.net/tracker/index.php?func=detail&aid=1504199&group_id=5470&atid=305470 > > Complete with documentation changes and a unit test. Thanks. Please CC me on these emails. It would also help if your mailer wouldn't add Mail-Followup-To: python-dev@python.org to the messages, since then a Reply-All will not include any other folks on CC in this thread. >>> Thomas wrote a patch which implemented the switch statement >>> using an opcode. The reason was probably that switch works >>> a lot like e.g. the for-loop which also opens a new block. >>> > > No, Skip explained this in an earlier e-mail: apparently some > programming languages use a compile-time generated lookup table > for switch statements rather than COMPARE_OP for each case. The > restriction is, of course, that you're stuck with constants for each > case statement. > > In a programming language like Python, where there are no named > constants, the usefulness of such a construct might be questioned. > Again, see Skip's earlier e-mails. > >>> Could you explain how your patch works ? >>> > > 1. Evaluate the "switch" expression so that it's at the top of the stack > 2. For each case clause: > 2.1. Generate a DUP_TOP to duplicate the switch value for a comparison > 2.2. Evaluate the "case" expression > 2.3. COMPARE_OP(PyCmp_EQ) > 2.4. Jump to the next case statement if false > 2.5. Otherwise, POP_TOP and execute the suite for the case clause > 2.6. Then jump to 3 > 3. POP_TOP to remove the evaluated switch expression from the stack > > As you can see from the above, my patch generates a COMPARE_OP for each > case, so you can use expressions - not just constants - for cases. > > All of this is in the code found in Python/compile.c. Thanks for the explanation, but the original motivation for adding a switch statement was to be able to use a lookup table for the switching in order to speed up branching code, e.g. in parsers which typically use constants to identify tokens (see the "Problem" section of the PEP for the motivation). The standard if ... elif ... efif ... else: ... scheme already provides the above logic. There's really no need to invent yet another syntax to write such constructs, IMHO. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jun 14 2006) >>> Python/Zope Consulting and Support ...http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ___ 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] [Python-checkins] sqlite3 test errors - was : Re: r46936 - in python/trunk: Lib/sqlite3/test/regression.py Lib/sqlite3/test/types.py Lib/sqlite3/test/userfunctions.py Modules/_sqlite/
On 6/14/06, Gerhard Häring <[EMAIL PROTECTED]> wrote: Co-posting to python-dev in the hope of getting help of people verifyingmy suspicion ...Gerhard Häring wrote:> [...]> For some reason, they don't seem to have picked up the changed tests of> the sqlite3 module. At least the error messages look exactly like the > ones I had when I ran the current code against old tests.That guess was wrong. The failed sqlite3 tests come from an old SQLiteversion being linked against. Until recently, SQLite was buggy and it was only fixed inhttp://www.sqlite.org/cvstrac/chngview?cn=2981that callbacks can throw errors that are usefully returned to theoriginal caller. The tests for the sqlite3 module currently assume a recent versionSQLite (3.3.something). Otherwise some tests will fail.Still, it can be built against any SQLite 3 release.Perhaps this is the wrong thing to do. Either sqlite3 should not build or raise an exception if it is built against a buggy version. The other option is to not run those known failing tests or error out immediately with a message stating that this tests fails on known versions of sqlite. -BrettCan somebody please also verify if the malloc/free error message goes away (it really only happened on Mac, didn't it?) if you upgrade SQLiteto the latest version on the build host?-- Gerhard___Python-checkins mailing list [EMAIL PROTECTED]http://mail.python.org/mailman/listinfo/python-checkins ___ 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] Scoping vs augmented assignment vs sets (Re: 'fast locals' in Python 2.5)
Boris Borcic <[EMAIL PROTECTED]> wrote: > Josiah Carlson wrote: > > > You seem to not realize that these different use-cases. Your new > > example involves a global variable that is *shared* among everyone that > > knows about this particular module. It also is repaired by a simple > > insertion of 'global freebits' at the beginning of the search function. > > My point here : a simple repair, and by a statement that amounts to a > compiler > directive with no other effect than obtaining my intent in bytecodes, so that > "all other things being equal" comparisons of code versions remain possible > (recall that I was studying the impact on working code of adopting sets - > including performance). Time to access and/or modify a particular variable is only important if you are performing the operation often enough to matter. Have you profiled your code to show that the fetch/assignment portion of x ^= y is slowing you down? Have you tested to see if x[0] ^= y slows you down significantly (embed your set in a list of size 1)? Have you tested to see if x.a ^= y slows you down significantly? If not, then you haven't really profiled your code. If you have, I'm curious as to your results; as my results have shown that for the two functions... def foo1(x): a = 0 for i in xrange(x): a += 1 def foo2(x) a = [0] def bar(x): for i in xrange(x): a[0] += 1 return bar(x) ... and an x of 100, foo1(x) runs in .15 seconds, while foo2(x) runs in .30 seconds. So the overhead of 1 million fetch/assignment to the first item in a list is ~.15 seconds, or 150 ns each. Further, I can almost guarantee that your set manipulations are going to dwarf the assignment/fetch times in either of these cases, so it seems to me that your desired Python change, for the sake of speed as you claim, is arbitrarily insignificant to your application, and likely so in many applications (being roughly equivalent to the cost of an iterator.next(), a name binding, and an int.__iadd__). > > The closure/class example is merely a method of encapsulating state, > > which I find easier to define, describe, and document than the closure > > version. > > Your priviledge of course (and I am not saying it is misguided, although I > would > in particular argue that the matter gets debatable in the low LOC-count > limit). > (I am also wondering about performance comparisons). Unless your code profiling has shown that such assignments are a limiting factor (if 150 ns per pass is a limiting factor, please let us know), then performance comparisons are moot. Further, code length is almost immaterial to this discussion, because even if you didn't want to bite the bullet and convert to a class-based approach, using a list of length 1, just for the sake of set modification, would solve your problem. def solve(problem) : freebits = set(range(N)) fb = [freebits] def search(data) : fb[0] ^= swap ... search(initial_data) ... > > Back in February, there was a discussion about allowing people to > > 'easily' access and modify variables defined in lexically nested scopes, > > but I believed then, as I believe now, that such attempted uses of > > closures are foolish when given classes. Given the *trivial* conversion > > of your closure example to a class, and my previous comments on closures > > "I find their use rarely, if ever, truely elegant, [...] more like > > kicking a puppy for barking: [...] there are usually better ways of > > dealing with the problem (don't kick puppies for barking and don't use > > closures).", you are not likely to find me agreeing with you about > > augmented assignment and/or lexically nested scopes. > > I see. Thanks for the background. Background for backround, let me just say > that > python hadn't yet grown a lambda when I first played with it. May I read your > last statement as acknowledging that I am not so much asking for a door to be > created, than asking for a naturally builtin door, not to be locked by > special > efforts ? No, you may not. There are two options for the Python compiler/runtime behavior when faced with an augmented assignment for a name not yet known in this particular lexical scope but known in a parent scope: assume you meant the name in the parent scope, or assume you made a mistake. The current state of affairs (for all released Pythons with augmented assignment) is to assume that you meant the local scope. Why? Because while allowing the augmented assignment would make your life easier in this case, the error would "pass silently" when it was an actual error (a not uncommon case), which is a bit of a no-no, and the case when you meant the parent scope is easily worked around. - Josiah ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev
Re: [Python-Dev] Scoping vs augmented assignment vs sets (Re: 'fast locals' in Python 2.5)
Boris Borcic <[EMAIL PROTECTED]> wrote: > Josiah Carlson wrote: > > > The closure/class example is merely a method of encapsulating state, > > which I find easier to define, describe, and document than the closure > > version. > > In the case of the code discussed, eg the actual model of > > def solve(problem) : > freebits = set(range(N)) > def search(data) : > > freebits ^= swap > ... > search(initial_data) > ... > > the closure isn't used to encapsulate state if what you mean is passing > "search" > around as an interface to said state - search() is only for internal > consumption > and in fact exists only because of a quite opposite reason. Namely, the > search > requires copying parts of the state and this is most easily expressed with a > recursive "search" inner function whose parameters are the copied parts. Ok, so here's a bit of a benchmark for you. def helper(x,y): return y def fcn1(x): _helper = helper y = x+1 for i in xrange(x): y = _helper(x,y) def fcn2(x): y = x+1 def _helper(x): return y for i in xrange(x): y = _helper(x) Can you guess which one is faster? I guessed, but I was wrong ;). >>> x = 100 >>> min([fcn1(x) for i in xrange(10)]), min([fcn2(x) for i in xrange(10)]) (0.5326484985352, 0.5923515014648) It turns out that passing two arguments to a helper function is actually faster than passing one argument and pulling a second out of an enclosing scope. >From here on out, I'll consider the speed discussion closed. > Whatever you say, it doesn't feel adequate to me nor particularly clear to > reify > such a recursive inner abstraction as an object method. Especially in Python, > I > can't help reading the methods of a class declaration as intended primarily > to > define an external interface, which is misleading in this case. I agree. If one is not seeking to offer an external interface, one shouldn't, and classes may be overkill. > I'd say a first step in convincing me I am wrong would be to show me examples > of > object methods of the standard library that are recursive, and cut out for > recursion. Actually, I don't believe that is necessary. I've shown that you would get better performance with a non-recursive function and passing two arguments, than you would passing one argument with scoping tricks to get the second. Also, given a recursive function that provides an external interface, I'm confident in my statement that a class would likely be more suitable, though I agree that recursive functions without an external interface may not be better as classes. - Josiah ___ 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] Scoping vs augmented assignment vs sets (Re: 'fast locals' in Python 2.5)
Is it perhaps time to move this discussion to c.l.py? The behavior isn't going to change. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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] Comparing closures and arguments (was Re: Scoping vs augmented assignment vs sets (Re: 'fast locals' in Python 2.5)
At 11:26 AM 6/14/2006 -0700, Josiah Carlson wrote: >Ok, so here's a bit of a benchmark for you. > > def helper(x,y): > return y > > def fcn1(x): > _helper = helper > y = x+1 > for i in xrange(x): > y = _helper(x,y) > > def fcn2(x): > y = x+1 > def _helper(x): > return y > for i in xrange(x): > y = _helper(x) > > >Can you guess which one is faster? I guessed, but I was wrong ;). > > >>> x = 100 > >>> min([fcn1(x) for i in xrange(10)]), min([fcn2(x) for i in xrange(10)]) >(0.5326484985352, 0.5923515014648) > >It turns out that passing two arguments to a helper function is actually >faster than passing one argument and pulling a second out of an >enclosing scope. That claim isn't necessarily supported by your benchmark, which includes the time to *define* the nested function 10 times, but calls it only 45 times! Try comparing fcn1(1000) and fcn2(1000) - I suspect the results will be somewhat closer, but probably still in favor of fcn1. However, I suspect that the remaining difference in the results would be due to the fact that the interpreter loop has a "fast path" function call implementation that doesn't work with closures IIRC. Perhaps someone who's curious might try adjusting the fast path to support closures, and see if it can be made to speed them up without slowing down other "fast path" calls. ___ 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] Comparing closures and arguments (was Re: Scoping vs augmented assignment vs sets (Re: 'fast locals' in Python 2.5)
"Phillip J. Eby" <[EMAIL PROTECTED]> wrote: > At 11:26 AM 6/14/2006 -0700, Josiah Carlson wrote: > >Ok, so here's a bit of a benchmark for you. > > > > def helper(x,y): > > return y > > > > def fcn1(x): > > _helper = helper > > y = x+1 > > for i in xrange(x): > > y = _helper(x,y) > > > > def fcn2(x): > > y = x+1 > > def _helper(x): > > return y > > for i in xrange(x): > > y = _helper(x) > > > > > >Can you guess which one is faster? I guessed, but I was wrong ;). > > > > >>> x = 100 > > >>> min([fcn1(x) for i in xrange(10)]), min([fcn2(x) for i in xrange(10)]) > >(0.5326484985352, 0.5923515014648) > > > >It turns out that passing two arguments to a helper function is actually > >faster than passing one argument and pulling a second out of an > >enclosing scope. > > That claim isn't necessarily supported by your benchmark, which includes > the time to *define* the nested function 10 times, but calls it only 45 > times! Try comparing fcn1(1000) and fcn2(1000) - I suspect the results > will be somewhat closer, but probably still in favor of fcn1. Please re-read the code and test as I have specified. You seem to have misunderstood something in there, as in the example I provide, _helper is called 1,000,000 times (and is defined only once for each call of fcn2) during each fcn1 or fcn2 call, and _helper is only defined once inside of fcn2. Further, reducing the passes to 1000 preserves the relative performance measures as I had previously stated. >>> x = 1000 >>> min([fcn1(x) for i in xrange(10)]), min([fcn2(x) for i in xrange(10)]) (0.00051907656835226135, 0.00056413073832572991) >>> x = 1 >>> min([fcn1(x) for i in xrange(10)]), min([fcn2(x) for i in xrange(10)]) (0.0037536511925964078, 0.0044071910377851964) >>> x = 10 >>> min([fcn1(x) for i in xrange(10)]), min([fcn2(x) for i in xrange(10)]) (0.053770416317590275, 0.057610581942384442) >>> x = 100 >>> min([fcn1(x) for i in xrange(10)]), min([fcn2(x) for i in xrange(10)]) (0.54333500712479577, 0.58664054298870383) > However, I suspect that the remaining difference in the results would be > due to the fact that the interpreter loop has a "fast path" function call > implementation that doesn't work with closures IIRC. Perhaps someone who's > curious might try adjusting the fast path to support closures, and see if > it can be made to speed them up without slowing down other "fast path" calls. That would be an interesting direction for improving speed. - Josiah ___ 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] Comparing closures and arguments (was Re: Scoping vs augmented assignment vs sets (Re: 'fast locals' in Python 2.5)
At 01:00 PM 6/14/2006 -0700, Josiah Carlson wrote: > > That claim isn't necessarily supported by your benchmark, which includes > > the time to *define* the nested function 10 times, but calls it only 45 > > times! Try comparing fcn1(1000) and fcn2(1000) - I suspect the results > > will be somewhat closer, but probably still in favor of fcn1. > >Please re-read the code and test as I have specified. You seem to have >misunderstood something in there, as in the example I provide, _helper >is called 1,000,000 times (and is defined only once for each call of >fcn2) during each fcn1 or fcn2 call, and _helper is only defined once >inside of fcn2. Oops. I misread "[fcn2(x) for i in xrange(10)]" as "[fcn2(x) for x in xrange(10)]". The latter is so much more common of a pattern that I guess I didn't even *look* at what the loop variable was. Weird. I guess the mind is a terrible thing. :) ___ 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] beta1 coming real soon
Neal Norwitz wrote: > It's June 9 in most parts of the world. The schedule calls for beta 1 > on June 14. It*s June 14 no longer in too many parts of the world ;-). Any *official* news about beta1? I guess the release will not be started as long as the tests fail, but is there a new plan? Thomas ___ 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] [Python-checkins] sqlite3 test errors - was : Re: r46936 - in python/trunk: Lib/sqlite3/test/regression.py Lib/sqlite3/test/types.py Lib/sqlite3/test/userfunctions.py Modules/_sqlite/
[Gerhard Häring] >> ... >> Until recently, SQLite was buggy and it was only fixed in >> >> http://www.sqlite.org/cvstrac/chngview?cn=2981 >> >> that callbacks can throw errors that are usefully returned to the >> original caller. >> >> The tests for the sqlite3 module currently assume a recent version >> SQLite (3.3.something). Otherwise some tests will fail. Sounds like that explains why none of the Windows buildbots failed (on Windows, Python currently uses the sqlite checked in at http://svn.python.org/projects/external/sqlite-source-3.3.4 ). I suppose some OSes think they're doing you a favor by forcing you to be the system SQLite admin ;-) ___ 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] [Python-checkins] sqlite3 test errors - was : Re: r46936 - in python/trunk: Lib/sqlite3/test/regression.py Lib/sqlite3/test/types.py Lib/sqlite3/test/userfunctions.py Modules/_sqlite/
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tim Peters wrote: > [Gerhard Häring] >>> ... >>> Until recently, SQLite was buggy and it was only fixed in >>> >>> http://www.sqlite.org/cvstrac/chngview?cn=2981 >>> >>> that callbacks can throw errors that are usefully returned to the >>> original caller. >>> >>> The tests for the sqlite3 module currently assume a recent version >>> SQLite (3.3.something). Otherwise some tests will fail. > > Sounds like that explains why none of the Windows buildbots failed (on > Windows, Python currently uses the sqlite checked in at > > http://svn.python.org/projects/external/sqlite-source-3.3.4 > > ). I suppose some OSes think they're doing you a favor by forcing you > to be the system SQLite admin ;-) Yes, this issue made development of the SQLite module a bit more "interesting" for me. And I deserved no better for committing changes so late before beta1. Anyway, I verified my theory about the SQLite bugs (that's what they are), and added version checks to the C code and to the test suite, so now Everything Should Work (*crossing fingers*). If anything should still fail, I'll ruthlessly blame Anthony, he brought the idea up of supporting older SQLite versions in the first place :-P - -- Gerhard -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEkI+hdIO4ozGCH14RAlW/AJ4uQVZrvWC7265+9wshxaBotyLolgCgstKd 5xU5DZm1EC/G9qNctPlMcGc= =gaaO -END PGP SIGNATURE- ___ 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] [Python-checkins] sqlite3 test er rors - was : Re: r46936 - in python/trunk: Lib/sqlit e3/test/regression.py Lib/sqlite3/test/types.py Lib/ sqlite3/test/userfunctions.py Modules/_sqli
Well, the just-released Ubuntu 06.06 LTS (Long Term Support) ships with sqlite 3.2.8. I'd suggest that whatever version ships with Python should _at_ _least_ work with this version. 06.06 is supposed to be supported for a couple of years, at least. Since this is the latest and greatest version of what's probably the most rapidly updating Linux (I don't include gentoo, obviously, because gentoo scares me (ObBarryBaiting: funroll-loops.org)), I don't think we can expect many people's platforms to have the absolute latest 3.4.4 or whatever. Alternately, we ship the sqlite3 code with Python. I'm deeply unthrilled with this idea, as it means more emergency security releases to fix sqlite3 security bugs, as well as bloating out the size of the release. In the meantime, I'd suggest the appropriate fix is to roll back to the previous version of the python-sqlite bindings on the trunk. Anthony ___ 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] beta1 coming real soon
Thomas Heller <[EMAIL PROTECTED]> wrote: > Neal Norwitz wrote: > > It's June 9 in most parts of the world. The schedule calls for beta 1 > > on June 14. > > It*s June 14 no longer in too many parts of the world ;-). Apparently it's still 1999 in some parts of the world. From your message: > From: Thomas Heller <[EMAIL PROTECTED]> > To: python-dev@python.org > Date: Fri, 31 Dec 1999 23:11:35 +0100 > Subject: Re: [Python-Dev] beta1 coming real soon Stolen Guido's time machine, have we? Charles -- --- Charles Cazabon <[EMAIL PROTECTED]> GPL'ed software available at: http://pyropus.ca/software/ --- ___ 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] beta1 coming real soon
On Saturday 01 January 2000 09:11, Thomas Heller wrote: > Neal Norwitz wrote: > > It's June 9 in most parts of the world. The schedule calls for > > beta 1 on June 14. > > It*s June 14 no longer in too many parts of the world ;-). > Any *official* news about beta1? I guess the release will not be > started as long as the tests fail, but is there a new plan? I want to be confident we've got this sqlite issue resolved. Since it might involve API changes, I'm stalling a little. Anthony -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ 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] pychecker warnings in Lib/encodings
On 6/13/06, Walter Dörwald <[EMAIL PROTECTED]> wrote: > > > IIUC (and I probably don't), mbcs is on windows only. But should I be > > able to import encodings.mbcs on Linux or is this expected? > > > import encodings.mbcs > > Traceback (most recent call last): > > File "", line 1, in > > File "Lib/encodings/mbcs.py", line 14, in > > class Codec(codecs.Codec): > > File "Lib/encodings/mbcs.py", line 18, in Codec > > encode = codecs.mbcs_encode > > AttributeError: 'module' object has no attribute 'mbcs_encode' > > mbcs_encode() is compiled conditionally in Modules/_codecsmodule.c with > "#if defined(MS_WINDOWS) && defined(HAVE_USABLE_WCHAR_T)". > > Should encodings/mbcs.py be made unimportable on non-Windows? That's what I was thinking. It makes sense to this non-unicode, non-windows luser. :-) n ___ 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] [Python-checkins] sqlite3 test errors - was : Re: r46936 - in python/trunk: Lib/sqlite3/test/regression.py Lib/sqlite3/test/types.py Lib/sqlite3/test/userfunctions.py Modules/_sqlite/
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Anthony Baxter wrote: > Well, the just-released Ubuntu 06.06 LTS (Long Term Support) ships > with sqlite 3.2.8. I'd suggest that whatever version ships with > Python should _at_ _least_ work with this version. I have no problems continuing to support any halfway sane version, and that is 3.0.8 or later (AFAIR the first non-beta SQLite 3.x release anyway). It just requires a bit more testing. > [...] > Alternately, we ship the sqlite3 code with Python. I'm deeply > unthrilled with this idea, as it means more emergency security > releases to fix sqlite3 security bugs, as well as bloating out the > size of the release. No, that's not an option. > In the meantime, I'd suggest the appropriate fix is to roll back to > the previous version of the python-sqlite bindings on the trunk. Why? The previous version is really no better, except it ignores errors in callbacks for all SQLite versions, instead of doing something useful and aborting the query with a useful error message for those SQLite versions that support it. - -- Gerhard -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD4DBQFEkPfYdIO4ozGCH14RAvQ+AJdxy8Iy0sfkSQVxShmGbq/HGKRzAKCPKMtG ZoEqmcNrgMX6k/7xzy0HKA== =OeDy -END PGP SIGNATURE- ___ 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
