[Python-Dev] possible memory leak on windows (valgrind report)
I ran 2.4.x through valgrind and found two small problems on Linux
that have been fixed. There may be some other issues which could
benefit from more eyes (small, probably one time memory leaks). The
entire run is here:
http://python.org/valgrind-2.4.2.out
(I need to write a lot more suppression rules for gentoo.)
I think I see a memory leak in win32_startfile. Since I don't run
windows I can't test it.
filepath should be allocated with the et flag to PyArgs_ParseTuple(),
but it wasn't freed without this patch. Does this make sense? See
the attached patch.
n
Index: Modules/posixmodule.c
===
RCS file: /cvsroot/python/python/dist/src/Modules/posixmodule.c,v
retrieving revision 2.342
diff -w -u -u -8 -r2.342 posixmodule.c
--- Modules/posixmodule.c 19 Sep 2005 06:45:53 - 2.342
+++ Modules/posixmodule.c 19 Sep 2005 07:47:44 -
@@ -7250,18 +7250,22 @@
char *filepath;
HINSTANCE rc;
if (!PyArg_ParseTuple(args, "et:startfile",
Py_FileSystemDefaultEncoding, &filepath))
return NULL;
Py_BEGIN_ALLOW_THREADS
rc = ShellExecute((HWND)0, NULL, filepath, NULL, NULL, SW_SHOWNORMAL);
Py_END_ALLOW_THREADS
- if (rc <= (HINSTANCE)32)
- return win32_error("startfile", filepath);
+ if (rc <= (HINSTANCE)32) {
+ PyObject *value = win32_error("startfile", filepath);
+ PyMem_Free(filepath);
+ return value;
+ }
+ PyMem_Free(filepath);
Py_INCREF(Py_None);
return Py_None;
}
#endif
#ifdef HAVE_GETLOADAVG
PyDoc_STRVAR(posix_getloadavg__doc__,
"getloadavg() -> (float, float, float)\n\n\
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] os.path.diff(path1, path2)
Hi,
> This function would take two paths: A and B and give
> the relation between them. Here are a few of examples.
>
> os.path.diff("/A/C/D/", "/A/D/F/")
> ==> "../../D/F"
>
> os.path.diff("/A/", "/A/B/C/")
> ==> "B/C"
>
> os.path.diff("/A/B/C/", "/A/")
> ==> "../.."
I'm not sure whether something like this is generally non-trivial.
Suppose you have the following directory structure:
/home -> usr/home
/usr
/usr/home
What does os.path.diff("/home/", "/usr/") yield? "../usr/", I would
presume? But that's obviously wrong:
>>> import os
>>> os.stat("/home/../usr")
Traceback (most recent call last):
File "", line 1, in ?
OSError: [Errno 2] No such file or directory: '/home/../usr'
I've not thought about this long enough to say if there's a trivial
solution to this, though :)
Bye,
Matthias A. Benkard
Matthias Andreas Benkard, Anarchokommunist und Pythonprogrammierer
Persönliche Website: http://www.mulk.de.vu/
Persönlicher Weblog: http://www.kompottkin.de.vu/
Flames bitte nach /dev/null schicken.
signature.asc
Description: This is a digitally signed message part
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] os.path.diff(path1, path2)
Hi, > /home -> usr/home Sorry, I forgot to mention what I meant by this: /home is a symlink pointing to usr/home (that is, /usr/home). Bye, Matthias Matthias Andreas Benkard, Anarchokommunist und Pythonprogrammierer Persönliche Website: http://www.mulk.de.vu/ Persönlicher Weblog: http://www.kompottkin.de.vu/ Flames bitte nach /dev/null schicken. signature.asc Description: This is a digitally signed message part ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Mixins.
Excuse my english. Is there any pythonic way to make real mixin into a class? Problem: Django model (and may be SQLObject). I have a common peaces of model declaration. Sometimes they are in table definition together, sometimes table have just one of them. I cannot use inheritance, cause Django doesn't handle it in right way (like mixins). Would it be usefull to define new magic class variable __mixins__ for a new style classes, which will accept list of classes and will drop all members of them into definition of class before they went to metaclass. Possible example (my wish in Django's Model): class time_from_to: time_from=meta.DateTimeField(default=datetime(1900,1,1,0,0,0)) time_to=meta.DateTimeField(default=datetime(3000,1,1,0,0,0)) class ident(meta.Model): __mixin__=[time_from_to] ident = meta.TextField() Or, as alternative: class time_from_to(mixin): time_from=meta.DateTimeField(default=datetime(1900,1,1,0,0,0)) time_to=meta.DateTimeField(default=datetime(3000,1,1,0,0,0)) class ident(time_from_to,meta.Model): ident = meta.TextField() You say: "It is problem of Django". Yes, you are right. It is common to use multiple inheritace in place of mixin. But it is handled not all time. Django does not at the moment (I hope, it would). To handle it, library writers, who implements their metaclasses, ought to write similar code again and again. I think, it would be simpler to make mixins in one true standart way. I can be mistaken. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mixins.
Sokolov Yura wrote: > Would it be usefull to define new magic class variable __mixins__ for a > new style classes, which > will accept list of classes and will drop all members of them into > definition of class before they went to metaclass. First off, this is probably more appropriate for comp.lang.python. Work it out there first, and if you still think it's a valid idea, then present it to python-dev. Secondly, no, I don't think it's useful to provide two ways (multiple inheritance and a __mixins__ attribute) to support mixins. Remember, TOOWTDI. STeVe -- You can wordify anything if you just verb it. --- Bucky Katt, Get Fuzzy ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] list splicing
On Monday 2005-09-19 06:38, Josiah Carlson wrote: > > > [ 'x', *a, 'y'] > > > > > > as syntactic sugar for > > > > > > [ 'x' ] + a + [ 'y' ]. > > > > > > Notes: > > > - This is a common operation > > > > is it? > > Not in the code that I read/use. While "not all 3 line functions should > be a builtin", "not all <5 character typing savings should be made > syntax". The problems with syntax are 1 It adds cognitive load. 2 It makes your code look like line noise. 3 It reduces options for future development. 4 It complicates the parser. In this instance, I don't think #1 applies; the rule "Putting *foo into a comma-separated list is the same as putting all the elements of foo into that list" isn't actually any harder to remember than the current rule concerning the prefix-* operator. #2 is always debatable. In this instance the proposed new form doesn't look any uglier to me (I speak for no one else) than its predecessor. #3 surely isn't true here; there isn't anything else sensible to do with prefix-* in lists, given the existing use specifically in argument lists. I don't know about #4, but I suspect it (along with the related "it requires work, and there isn't much benefit from it") is the best argument against this proposal. -- g ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] removing nested tuple function parameters
Greg Ewing wrote: > François Pinard wrote: > > > The only practical reason to like this feature is sparing the need of > > finding an otherwise useless name for the formal argument. > > If the argument represents a coherent enough concept > to be passed in as a tuple in the first place, it > should be possible to find a meaningful name for it. > Otherwise the elements should probably be passed in > as separate arguments. But sometimes you don't have this option. If I have a class that I'd like to support an indexing operation like: obj[x, y] then the natural __getitem__ signature will look like: def __getitem__(self, (x, y)): ... Note that I definitely can't write this as: def __getitem__(self, x, y): ... because __getitem__ is always called with a single argument, not two. Of course, I can give the parameter a name and do the tuple unpacking manually (e.g. x, y = x_y), but I'm not sure I understand yet what we gain by making __getitem__ harder to use with tuples. I guess if tuple unpacking in function parameters goes away, I think we should change the __getitem__ machinery so that: obj[x1, x2, ..., xN] is translated to: obj.__getitem__(x1, x2, ..., xN) where __getitem__ would now have to take a *args when called with tuples. STeVe -- You can wordify anything if you just verb it. --- Bucky Katt, Get Fuzzy ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] GIL, Python 3, and MP vs. UP (was Re: Variant of removing GIL.)
On 9/18/05, Guido van Rossum <[EMAIL PROTECTED]> wrote: > On 9/17/05, John J Lee <[EMAIL PROTECTED]> wrote: > > c. Since time is needed to iron out bugs (and perhaps also to reimplememt > >some pieces of code "from scratch"), very early in the life of Python 3 > >seems like the least-worst time to begin work on such a change. > > > > I realize that not all algorithms (nor all computational problems) scale > > well to MP hardware. Is it feasible to usefully compile both MP and a UP > > binaries from one Python source code base? > > That's an understatement. I expect that *most* problems (even most > problems that we will be programming 10-20 years from now) get little > benefit out of MP. Some are saying it won't be a matter of choice if we want to get the software to run faster (you know, that "MORE MORE MORE!" thing we all seem to suffer from): http://www.gotw.ca/publications/concurrency-ddj.htm The Free Lunch Is Over: A Fundamental Turn Toward Concurrency in Software Herb Sutter March 2005 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] possible memory leak on windows (valgrind report)
On 9/19/05, Neal Norwitz <[EMAIL PROTECTED]> wrote: > I ran 2.4.x through valgrind and found two small problems on Linux > that have been fixed. There may be some other issues which could > benefit from more eyes (small, probably one time memory leaks). The > entire run is here: > > http://python.org/valgrind-2.4.2.out > > (I need to write a lot more suppression rules for gentoo.) > > I think I see a memory leak in win32_startfile. Since I don't run > windows I can't test it. > filepath should be allocated with the et flag to PyArgs_ParseTuple(), > but it wasn't freed without this patch. Does this make sense? See > the attached patch. That patch doesn't make sense to me -- the "s" code to PyArg_ParseTuple doesn't return newly allocated memory, it just returns a pointer into a string object that is owned by the caller (really by the call machinery I suppose). Compare other places using PyArg_ParseTuple(args, "s:..."). -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] possible memory leak on windows (valgrind report)
On 9/19/05, Guido van Rossum <[EMAIL PROTECTED]> wrote: > > That patch doesn't make sense to me -- the "s" code to > PyArg_ParseTuple doesn't return newly allocated memory, it just > returns a pointer into a string object that is owned by the caller > (really by the call machinery I suppose). Compare other places using > PyArg_ParseTuple(args, "s:..."). "s"? The format passed to ParseTuple is "et". At least it is in the patch I'm looking at. n ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] possible memory leak on windows (valgrind report)
So it is. I swear I saw "s"; I must've had an out of date version. The change to "et" is less than a week old, but that's no excuse. :-( It does look like the patch is correct then (but I can't build on Windows any more either). Sorry for the confusion. On 9/19/05, Neal Norwitz <[EMAIL PROTECTED]> wrote: > On 9/19/05, Guido van Rossum <[EMAIL PROTECTED]> wrote: > > > > That patch doesn't make sense to me -- the "s" code to > > PyArg_ParseTuple doesn't return newly allocated memory, it just > > returns a pointer into a string object that is owned by the caller > > (really by the call machinery I suppose). Compare other places using > > PyArg_ParseTuple(args, "s:..."). > > "s"? The format passed to ParseTuple is "et". At least it is in the > patch I'm looking at. > > n > -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] removing nested tuple function parameters
I consider the current situation to be a consistency feature. To a first approximation, Python function calls 'pass' objects by name-binding: param_name_list = arg_object_list Disabling structure unpacking in this assignment would make the language slightly more complex. Someone else posted the same observation in c.l.p. Another thought. By directly unpacking and not naming a sequence, one 'announces' that only the components are of interest and that nothing will be done with the sequence object itself. Terry J. Reedy ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] removing nested tuple function parameters
On 9/19/05, Terry Reedy <[EMAIL PROTECTED]> wrote: > > I consider the current situation to be a consistency feature. To a first > approximation, Python function calls 'pass' objects by name-binding: > > param_name_list = arg_object_list > > Disabling structure unpacking in this assignment would make the language > slightly more complex. Someone else posted the same observation in c.l.p. Maybe, but there are enough differences between parameter/argument lists and sequences that this consistency sounds rather foolish to me. In fact, the feature came from a similar feature in ABC, but in ABC, parameter lists *were* considered assignment targets -- the outer level of parentheses was just a special case of tuple unpacking. Not so in Python, which has keyword parameters, *varargs, **keywords, and where f(x,) is the same as f(x) -- even though (x,) is a tuple and (x) is not. Also, I bet many people will be surprised to know that this code doesn't work: add = lambda (x, y): x+y print add(1, 2) > Another thought. By directly unpacking and not naming a sequence, one > 'announces' that only the components are of interest and that nothing will > be done with the sequence object itself. Fair enough, though I'm not sure what use we can make of that information. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] removing nested tuple function parameters
Guido van Rossum wrote: > Also, I bet many people will be surprised to know that this code doesn't work: > > add = lambda (x, y): x+y > print add(1, 2) What, an example using lambda syntax that's unintuitive? Never! ;-) STeVe -- You can wordify anything if you just verb it. --- Bucky Katt, Get Fuzzy ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] list splicing
Gareth McCaughan <[EMAIL PROTECTED]> wrote: > The problems with syntax are > > 1 It adds cognitive load. > 2 It makes your code look like line noise. > 3 It reduces options for future development. > 4 It complicates the parser. > > I don't know about #4, but I suspect it (along with the related > "it requires work, and there isn't much benefit from it") is the > best argument against this proposal. I don't think the parser would get measureably more complex, but I believe that any work to support this uncommon (from my experience) operation, rather than the dozens of other usable RFEs in the tracker, would be misspent time. - Josiah ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] removing nested tuple function parameters
> I agree that we shouldn't mess with them in 2.x. Yet I think they are > a candidate for being dropped from Py3K. While every feature is used > by *someone* (as the feedback to Brett's query clearly shows) this one > has several things against it. For every user who is fond of them > there are probably ten who have never even heard of it. It's purely > syntactic sugar (the only place where it's not trivial to replace is > in a lambda). I've encountered quite a few people who had a hard time > reading code that uses it. I personally prefer reading code that > doesn't use this feature; for one thing, when this is used, you can't > refer to a parameter by name. I don't know whether this qualifies as an argument for or against the feature, but ML has a nice way of referring to such a parameter by name: fun f(x as (y, z)) = (* ... *) This defines f as a function with an argument that is a 2-element tuple. The name x is bound to the argument, and the names y and z are bound to the two components of the argument. This example is syntactic sugar for fun f x = let val (y, z) = x in (* ... *) end but it I find the sugared version easier and more natural to write and understand. If you don't know ML, the unsugared version might be easier to follow if I indent it Pythonically: fun f x = let val (y, z) = x in (* ... *) end The idea is that the stuff between "in" and "end" is executed in the scope of the bindings between "let" and "in", after which those bindings are discarded. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] removing nested tuple function parameters
> The only practical reason to like this feature is sparing the need of > finding an otherwise useless name for the formal argument. Another > reason, but not practical at all, is that the concept conveys some > elegance and originality (each programming language should ideally have > a few of these) and is enforced in other places in Python, like in the > `for' statement -- where I find implied unpacking very, very useful. One other reason: It is possible to imagine using the feature to catch some type errors at the point of call, rather than having to get into the function itself before detecting them. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] possible memory leak on windows (valgrind report)
Neal Norwitz wrote: > I ran 2.4.x through valgrind and found two small problems on Linux > that have been fixed. There may be some other issues which could > benefit from more eyes (small, probably one time memory leaks). The > entire run is here: > > http://python.org/valgrind-2.4.2.out > > (I need to write a lot more suppression rules for gentoo.) > > I think I see a memory leak in win32_startfile. Since I don't run > windows I can't test it. > filepath should be allocated with the et flag to PyArgs_ParseTuple(), > but it wasn't freed without this patch. Does this make sense? See > the attached patch. Applied the patch, this was my fault. Reinhold -- Mail address is perfectly valid! ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] removing nested tuple function parameters
Andrew Koenig wrote: > It is possible to imagine using the feature to catch some > type errors at the point of call, rather than having to get into the > function itself before detecting them. There can certainly be value in type-checking parameters and return values, but in this case, I think the (mental) cost is too high. With nested tuples, it hasn't actually ever helped me, but I have been burned by the extra fragility it introduces. Nesting encourages complicated parameter lists. Nested variables can (wrongly) match if your data itself is made of tuples. If the function signature changes, it is a lot harder to notice or track down. Normally, I can defend against some of this by using keywords -- but not if the parameter list is nested. Sure, it makes def __getitem__(self, (x, y)) easier -- but I don't think that is a good thing. When working with someone else's code, I would much rather *read* def __getitem__(self, keytuple): x, y = keytuple -jJ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] removing nested tuple function parameters
"Andrew Koenig" <[EMAIL PROTECTED]> writes: >> The only practical reason to like this feature is sparing the need of >> finding an otherwise useless name for the formal argument. Another >> reason, but not practical at all, is that the concept conveys some >> elegance and originality (each programming language should ideally have >> a few of these) and is enforced in other places in Python, like in the >> `for' statement -- where I find implied unpacking very, very useful. > > One other reason: It is possible to imagine using the feature to catch some > type errors at the point of call, rather than having to get into the > function itself before detecting them. Conceptually, maybe, but implementation wise, that's not how things work. Cheers, mwh -- I love the way Microsoft follows standards. In much the same manner that fish follow migrating caribou. -- Paul Tomblin -- http://home.xnet.com/~raven/Sysadmin/ASR.Quotes.html ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] GIL, Python 3, and MP vs. UP
Martin Blais <[EMAIL PROTECTED]> writes: > On 9/18/05, Guido van Rossum <[EMAIL PROTECTED]> wrote: >> On 9/17/05, John J Lee <[EMAIL PROTECTED]> wrote: >> > c. Since time is needed to iron out bugs (and perhaps also to reimplememt >> >some pieces of code "from scratch"), very early in the life of Python 3 >> >seems like the least-worst time to begin work on such a change. >> > >> > I realize that not all algorithms (nor all computational problems) scale >> > well to MP hardware. Is it feasible to usefully compile both MP and a UP >> > binaries from one Python source code base? >> >> That's an understatement. I expect that *most* problems (even most >> problems that we will be programming 10-20 years from now) get little >> benefit out of MP. > > Some are saying it won't be a matter of choice if we want to get the > software to run faster (you know, that "MORE MORE MORE!" thing we all > seem to suffer from): People have been saying this for _years_, and it hasn't happened yet. This time around it's a bit more convincing, but I reserve the right to remain a touch skeptical. > http://www.gotw.ca/publications/concurrency-ddj.htm > The Free Lunch Is Over: A Fundamental Turn Toward Concurrency in Software > Herb Sutter > March 2005 I was disappointed that that article (hey, it was the only issue of ddj I've ever actually bought! :) didn't consider any concurrency models other than shared memory threading. Cheers, mwh -- . <- the pointyour article -> . |- a long way | -- Christophe Rhodes, ucam.chat ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] GIL, Python 3, and MP vs. UP
On 9/19/05, Michael Hudson <[EMAIL PROTECTED]> wrote: > I was disappointed that that article (hey, it was the only issue of > ddj I've ever actually bought! :) didn't consider any concurrency > models other than shared memory threading. The problem is that, for all its limitations, shared-memory threading is the most popular concurrency model on the most popular operating system, so future hardware platforms targeting that system will be optimizing for that case. We can either rail against the sea, or accept it. -- Tim Lesher <[EMAIL PROTECTED]> ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] GIL, Python 3, and MP vs. UP
* Martin Blais: > http://www.gotw.ca/publications/concurrency-ddj.htm > The Free Lunch Is Over: A Fundamental Turn Toward Concurrency in Software > Herb Sutter > March 2005 This piece is fundamentally wrong. We all have been writing concurrent server-side software for eons. I don't know what Herb was thinking when he wrote that piece. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] GIL, Python 3, and MP vs. UP
* Guido van Rossum: > That assumes a very specific model for how all that MP power is going > to be used. Indeed. > I personally don't think the threaded programming model as found in > Java works all that well; without locks you end up with concurrent > modification errors, with locks you get deadlocks and livelocks. Java is bascially forced into that model because VM startup costs are so high. To some extent, Python has similar problems, but you don't have to care about preserving class loader semantics, so you should be in a better position to cut down process creation time. > Be my guest. Prove me wrong. Talk is cheap; instead of arguing my > points (all of which can be argued ad infinitum), come back when > you've got a working GIL-free Python. Doesn't have to be CPython-based > -- C# would be fine too. By the way, has anybody ever tried to create a CPython variant which uses a (mostly) copying garbage collector (or something else except reference counting or Boehm GC)? Copying GC might help to get rid of the GIL *and* improve performance in the accept+fork model (because read-only object access does not trigger copy-on-write anymore). ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] list splicing
Karl Chen writes: > Hi, has anybody considered adding something like this: > a = [1, 2] > [ 'x', *a, 'y'] > > as syntactic sugar for > a = [1, 2] > [ 'x' ] + a + [ 'y' ]. A bit later in the thread, Josiah Carlson replies: > I don't think the parser would get measureably more complex, but I > believe that any work to support this uncommon (from my experience) > operation, rather than the dozens of other usable RFEs in the tracker, > would be misspent time. I'd just like to point out that this is a FRF (Frequently Requested Feature). I'm not arguing in favor of it, just pointing out that using "star unpacking" in tuple and list literals is an idea that I'm sure I've seen proposed at least a couple of times before. This doesn't necessarily make it a good idea, nor a bad one. -- Michael Chermside ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] list splicing
On Monday 19 September 2005 16:36, Michael Chermside wrote: > I'd just like to point out that this is a FRF (Frequently Requested > Feature). I'm not arguing in favor of it, just pointing out that > using "star unpacking" in tuple and list literals is an idea that > I'm sure I've seen proposed at least a couple of times before. Indeed, "star unpacking" has been brought up many times; I think it would be really cool myself. (Regardless of whether it's the best use of development effort; that would be up to the contributor.) I haven't seen "star packing" proposed before, as best as I can recall. That's what strikes me as different in this discussion. -Fred -- Fred L. Drake, Jr. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] GIL, Python 3, and MP vs. UP
Florian Weimer <[EMAIL PROTECTED]> writes: > By the way, has anybody ever tried to create a CPython variant which > uses a (mostly) copying garbage collector (or something else except > reference counting or Boehm GC)? Not to my knowledge. I've always thought that it would be pretty hard. I'd be interested in being proved wrong. PyPy will hopefully experiment with this sort of thing. > Copying GC might help to get rid of the GIL *and* improve performance > in the accept+fork model (because read-only object access does not > trigger copy-on-write anymore). How does a copying gc differ much from a non-copying non-refcounted gc here? Cheers, mwh -- Darn! I've only got 10 minutes left to get falling-down drunk! I suppose I'll have to smoke crack instead now. -- Tim Peters is checking things in on 2002-12-31 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] GIL, Python 3, and MP vs. UP
* Michael Hudson: > Not to my knowledge. I've always thought that it would be pretty > hard. I'd be interested in being proved wrong. The real problem is that you can ditch most extension modules. 8-( It sounds more like a fun project for the Python core, though. >> Copying GC might help to get rid of the GIL *and* improve performance >> in the accept+fork model (because read-only object access does not >> trigger copy-on-write anymore). > > How does a copying gc differ much from a non-copying non-refcounted gc > here? You could copy immutable objects to a separate set of pages and never collect them (especially if recursively refer to immutable objects only). ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] GIL, Python 3, and MP vs. UP
Michael Hudson wrote: > How does a copying gc differ much from a non-copying non-refcounted gc > here? One important issue for C coded modules is that addresses may change when a GC is invoked, so no remembering addresses in your module; you must recalculate before each use. -- Scott David Daniels [EMAIL PROTECTED] ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] GIL, Python 3, and MP vs. UP
On Mon, 2005-09-19 at 17:52, Scott David Daniels wrote: > Michael Hudson wrote: > > > How does a copying gc differ much from a non-copying non-refcounted gc > > here? > > One important issue for C coded modules is that addresses may change > when a GC is invoked, so no remembering addresses in your module; you > must recalculate before each use. And then you're left with "fun" like JNI's pining and such. That won't suck at all! :) -Barry signature.asc Description: This is a digitally signed message part ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] For/while/if statements/comprehension/generator expressions unification
Hello, Well, we have "for", "while" and "if". We also have statements, list generator expressions and list comprehensions. In comprehensions we have the opportunity to use several for-s and in a same expression (for i in range (0, 640) for j in range (0, 640)), in loops we cannot; in comprehensions, we can use if-s to filter the items; in loops, we cannot, and we have to write an inner comparison instead. My opinion is that in so smart language as Python is, it would be great to have them generalized, so that the features available in list comprehensions should be available in statements, vice versa. All three statements (for/while/if) could be joined together into a single common one, where any of these could be combined and used multiple times (but for the cases when a "else"/"elif" etc causes are required, old-school one-statements should be left); and for such common expressions, they should be equal for both loop statements and list comprehensions/generator expressions. That is, the following loops should be possible: --- # This gives us some sugar to get rid of unnecessary indentations for x in range (0, 640) for y in range (0, 480): --- for x in range (0, 640) if should_handle_this_column(x) \ for y in range (0, 480) if should_handle_this_row(y): --- for nX, nY in ( f(x), f(y) for x in range (0, 640) if should_handle_this_column(x) for y in range (0, 480) if should_handle_this_row(y) ): --- for x in range (0, 640) for y in range (0, 480) while(!timeout()): --- for x in range (0, 640) while(!timeout_pos_in_row()) for y in range (0, 480) while(!timeout_rows()): --- # And the latest and the hugest one: for x in range (0, 640) if should_handle_this_column(x) while(!timeout_pos_in_row()) \ for y in range (0, 480) if should_handle_this_row(y) while(!timeout_rows() : --- # And almost the same as generator expression: for x, y in ( f(x), f(y) for x in range (0, 640) if should_handle_this_column(x) while(!timeout_pos_in_row()) for y in range (0, 480) if should_handle_this_row(y) while(!timeout_rows() ) --- Hope I didn't miss something important... -- With best regards, Alexander mailto:[EMAIL PROTECTED] ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] list splicing
[Fred L. Drake] > Indeed, "star unpacking" has been brought up many times; I think it would > be > really cool myself. It might have a chance of acceptance this time if the proponents stick with unpacking at the end: a,b,*c=sometup instead of a,*b,c=sometup. The latter has usually gotten shot down quickly, taking the former down with it. Raymond ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] "and" and "or" operators in Py3.0
I propose that in Py3.0, the "and" and "or" operators be simplified to always return a Boolean value instead of returning the last evaluated argument. 1) The construct can be error-prone. When an error occurs it can be invisible to the person who wrote it. I got bitten in published code that had survived testing and code review: def real(self): 'Return a vector with the real part of each input element' # do not convert integer inputs to floats return self.map(lambda z: type(z)==types.ComplexType and z.real or z) The code fails silently when z is (0+4i). It took a good while to trace down a user reported error (when Matlab results disagreed with my matrix module results) and determine that the real() method contained an error. Even when traced down, I found it hard to see the error in the code. Now that I know what to look for, it has not happened again, but I do always have to stare hard at any "and/or" group to mentally verify each case. 2) When going back and forth between languages, it is easy to forget that only Python returns something other than a boolean. 3) Even when it isn't being used, the possibility of non-boolean return value complicates the bytecode and parser. To allow for "and/or", the conditional opcodes leave the tested value on the stack. In most cases both branches go directly to a POP_TOP instruction. Since the POP_TOP shouldn't be executed twice, the body of the positive branch has to close with a jump over the other branch even when it is empty. For instance, the simplest case: if a: b compiles to: 1 0 LOAD_NAME0 (a) 3 JUMP_IF_FALSE8 (to 14) 6 POP_TOP 2 7 LOAD_NAME1 (b) 10 POP_TOP 11 JUMP_FORWARD 1 (to 15) >> 14 POP_TOP >> 15 LOAD_CONST 0 (None) 18 RETURN_VALUE this could be simpler and faster: 1 0 LOAD_NAME0 (a) 3 JUMP_IF_FALSE8 (to 10) 2 6 LOAD_NAME1 (b) 9 POP_TOP >> 10 LOAD_CONST 0 (None) 13 RETURN_VALUE Executive summary. Returning only Booleans reduces errors, makes the code easier to review, follows other language norms, and simplifies/speeds-up the generated code. Raymond P.S. Simplifying "and" and "or" may create a need to introduce a conditional operator but that is a discussion for another day. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] "and" and "or" operators in Py3.0
On 9/19/05, Raymond Hettinger <[EMAIL PROTECTED]> wrote: > I propose that in Py3.0, the "and" and "or" operators be simplified to > always return a Boolean value instead of returning the last evaluated > argument. While you're at it, maybe we should switch to && and || as well? That's another thing I always mistype when switching between languages... Also, this proposal needs to be considered together with the addition of a proper conditional operator, like x?y:z. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] "and" and "or" operators in Py3.0
[Raymond Hettinger] > I propose that in Py3.0, the "and" and "or" operators be simplified to > always return a Boolean value instead of returning the last evaluated > argument. > 1) The construct can be error-prone. When an error occurs it can be > invisible to the person who wrote it. I got bitten in published code > that had survived testing and code review: > def real(self): > 'Return a vector with the real part of each input element' > # do not convert integer inputs to floats > return self.map(lambda z: type(z)==types.ComplexType and z.real or z) The real problem, above, is the starve for using `lambda'. The abuse of `and' and `or' is a mere consequence of this. Remove `lambda' from Python, and most reasonable people would spontaneously write more legible code instead. I do not perceive Python as designed to prevent unreasonable people from "outclevering" themselves. > 2) When going back and forth between languages, it is easy to forget > that only Python returns something other than a boolean. C, C++, Lisp, and shells do the same as Python. Or maybe more correctly, Python borrowed short-circuiting booleans from other languages. > 3) Even when it isn't being used, the possibility of non-boolean > return value complicates the bytecode and parser. [...] P.S. > Simplifying "and" and "or" may create a need to introduce a > conditional operator but that is a discussion for another day. If removed, to be re-introduced differently, the bytecode and parser would not have gained simplicity overall. > Executive summary. Returning only Booleans reduces errors, makes > the code easier to review, follows other language norms, and > simplifies/speeds-up the generated code. The summary reduces to: "Returning only Booleans would speed-up the generated code, once in a while." Now, could we evaluate that speed up on the average code, like on the Python library say? It might not be worth the change... -- François Pinard http://pinard.progiciels-bpi.ca ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] For/while/if statements/comprehension/generator expressions unification
Alexander, The essence of what you have proposed has been proposed (multiple times) before, and I seem to remember it was shot down. The below functions offer the equivalent of list comprehensions with a final post-processing step. def cross(*args): if len(args) == 1: for i in args[0]: yield i elif len(args) == 2: for i in args[0]: for j in args[1]: yield i,j else: for i in args[0]: for j in cross(*args[1:]): yield (i,) + j def cross_with_predicate(*args, **kwargs): if not 'pred' in kwargs: for i in cross(*args): yield i pred = kwargs['pred'] if len(args) > 1: for i in cross(*args): if pred(*i): yield i else: for i in cross(*args): if pred(i): yield i Feel free to use that code and/or modify it to your heart's content (be careful of attempting to simplify cross, . - Josiah Alexander Myodov <[EMAIL PROTECTED]> wrote: > Hello, > > Well, we have "for", "while" and "if". We also have statements, > list generator expressions and list comprehensions. In > comprehensions we have the opportunity to use several for-s and in a > same expression (for i in range (0, 640) for j in range (0, 640)), > in loops we cannot; in comprehensions, we can use if-s to filter the > items; in loops, we cannot, and we have to write an inner comparison > instead. > > My opinion is that in so smart language as Python is, it would be > great to have them generalized, so that the features available in > list comprehensions should be available in statements, vice versa. > All three statements (for/while/if) could be joined > together into a single common one, where any of these could be > combined and used multiple times (but for the cases when a > "else"/"elif" etc causes are required, old-school one-statements > should be left); and for such common expressions, they should be > equal for both loop statements and list comprehensions/generator > expressions. > That is, the following loops should be possible: > --- > # This gives us some sugar to get rid of unnecessary indentations > for x in range (0, 640) for y in range (0, 480): > --- > for x in range (0, 640) if should_handle_this_column(x) \ > for y in range (0, 480) if should_handle_this_row(y): > --- > for nX, nY in ( > f(x), f(y) > for x in range (0, 640) if should_handle_this_column(x) > for y in range (0, 480) if should_handle_this_row(y) > ): > --- > for x in range (0, 640) for y in range (0, 480) while(!timeout()): > --- > for x in range (0, 640) while(!timeout_pos_in_row()) for y in range (0, 480) > while(!timeout_rows()): > --- > # And the latest and the hugest one: > for x in range (0, 640) if should_handle_this_column(x) > while(!timeout_pos_in_row()) \ > for y in range (0, 480) if should_handle_this_row(y) while(!timeout_rows() : > --- > # And almost the same as generator expression: > for x, y in ( > f(x), f(y) > for x in range (0, 640) if should_handle_this_column(x) > while(!timeout_pos_in_row()) > for y in range (0, 480) if should_handle_this_row(y) > while(!timeout_rows() > ) > --- > > Hope I didn't miss something important... > > -- > With best regards, > Alexander mailto:[EMAIL PROTECTED] > > > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/jcarlson%40uci.edu ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] "and" and "or" operators in Py3.0
Raymond Hettinger wrote: > I propose that in Py3.0, the "and" and "or" operators be simplified to > always return a Boolean value instead of returning the last evaluated > argument. > > 1) The construct can be error-prone. When an error occurs it can be > invisible to the person who wrote it. I got bitten in published code > that had survived testing and code review: Yes, I wondered about that possibility myself. +1 > P.S. Simplifying "and" and "or" may create a need to introduce a > conditional operator but that is a discussion for another day. You would still be able to use multiply to covert a comparison to a value. Cheers, Ron ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] "and" and "or" operators in Py3.0
On Mon, 2005-09-19 at 20:03, Guido van Rossum wrote: > While you're at it, maybe we should switch to && and || as well? > That's another thing I always mistype when switching between > languages... Please no! 'and' and 'or' is so readably beautiful. > Also, this proposal needs to be considered together with the addition > of a proper conditional operator, like x?y:z. Definitely. -Barry signature.asc Description: This is a digitally signed message part ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] "and" and "or" operators in Py3.0
> P.S. Simplifying "and" and "or" may create a need to introduce a
> conditional operator but that is a discussion for another day.
While I don't disagree with some of your main points, I do think that
your proposal would eliminate a natural and easy to understand use of
the current behavior of "or" that I tend to use quite a bit. Your
proposal would break a lot of code, and I can't think of a better
"conditional operator" than the one thats already there.
I often find myself using 'or' to conditionally select a meaningful
value in the absence of a real value:
person = Person.fetch(id=5)
name = person.name or 'John Doe'
birth_date = person.birth_date or '00-00-'
ssn = person.social_security or 'not provided'
logger.log_msg('%s born on %s with SSN %s' % (name, birth_date,
ssn))
To me, its just as natural as:
{ 'key' : value }.get('not_there', 'default')
but more general purpose. I like the current behavior, and I think
it makes a whole lot of sense.
Jonathan LaCour
http://cleverdevil.org
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] "and" and "or" operators in Py3.0
>While I don't disagree with some of your main points, I do think that >your proposal would eliminate a natural and easy to understand use of >the current behavior of "or" that I tend to use quite a bit. Your >proposal would break a lot of code, and I can't think of a better >"conditional operator" than the one thats already there. > >I often find myself using 'or' to conditionally select a meaningful >value in the absence of a real value: I agree. I find I often have an object with an optional friendly name (label) and a manditory system name. So this sort of thing becomes common: '%s blah blah' % (foo.label or foo.name) The if-else-expression alternative works, but isn't quite as readable: '%s blah blah' % (foo.label ? foo.label : foo.name) -- Andrew McNamara, Senior Developer, Object Craft http://www.object-craft.com.au/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] os.path.diff(path1, path2)
Matthias Andreas Benkard wrote:
> /home -> usr/home
> /usr
> /usr/home
>
> What does os.path.diff("/home/", "/usr/") yield? "../usr/", I would
> presume? But that's obviously wrong:
IMO, the relpath method should just work textually on
the pathnames. It's up to the user to ensure it makes
sense to do so, e.g. by resolving symlinks beforehand
if necessary.
The alternative would be for relpath to do this itself,
but that would make it very unusual compared to the
other path-munging functions, none of which touch the file
system.
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | A citizen of NewZealandCorp, a |
Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. |
[EMAIL PROTECTED] +--+
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] os.path.diff(path1, path2)
Greg Ewing wrote:
> Matthias Andreas Benkard wrote:
>
>> /home -> usr/home
>> /usr
>> /usr/home
>>
>> What does os.path.diff("/home/", "/usr/") yield? "../usr/", I would
>> presume? But that's obviously wrong:
>
> IMO, the relpath method should just work textually on
> the pathnames. It's up to the user to ensure it makes
> sense to do so, e.g. by resolving symlinks beforehand
> if necessary.
In addition, I would presume that relpath would just return the absolute
path if passed an absolute path as the second parameter.
So the above would simply return "/usr/" IMO.
Tim Delaney
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] list splicing
On Monday 19 September 2005 19:20, Raymond Hettinger wrote: > It might have a chance of acceptance this time if the proponents stick > with unpacking at the end: a,b,*c=sometup instead of a,*b,c=sometup. > The latter has usually gotten shot down quickly, taking the former down > with it. True. I'd be happy with it either way, since most of the time a, b, *rest = stuff_to_unpack is all I really want. -Fred -- Fred L. Drake, Jr. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] removing nested tuple function parameters
Steven Bethard wrote: > I guess if tuple unpacking in function parameters goes away, I think > we should change the __getitem__ machinery so that: > > obj[x1, x2, ..., xN] > > is translated to: > > obj.__getitem__(x1, x2, ..., xN) > > where __getitem__ would now have to take a *args when called with tuples. That might be a reasonable idea to consider for Py3k in any case. -- Greg Ewing, Computer Science Dept, +--+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | [EMAIL PROTECTED] +--+ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] removing nested tuple function parameters
Terry Reedy wrote: > I consider the current situation to be a consistency feature. To a first > approximation, Python function calls 'pass' objects by name-binding: > > param_name_list = arg_object_list > > Disabling structure unpacking in this assignment would make the language > slightly more complex. But it's a rather selective kind of consistency. To be truly consistent in this sense, arbitrary lvalues would have to be allowed in the parameter list. -- Greg Ewing, Computer Science Dept, +--+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | [EMAIL PROTECTED] +--+ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] removing nested tuple function parameters
Andrew Koenig wrote: > One other reason: It is possible to imagine using the feature to catch some > type errors at the point of call, rather than having to get into the > function itself before detecting them. Not a big deal - you just need to look one line further up in the traceback to find where the call was. -- Greg Ewing, Computer Science Dept, +--+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | [EMAIL PROTECTED] +--+ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] "and" and "or" operators in Py3.0
On Mon, Sep 19, 2005, Jonathan LaCour wrote: > Raymond Hettinger: >> >> P.S. Simplifying "and" and "or" may create a need to introduce a >> conditional operator but that is a discussion for another day. > > While I don't disagree with some of your main points, I do think that > your proposal would eliminate a natural and easy to understand use of > the current behavior of "or" that I tend to use quite a bit. Your > proposal would break a lot of code, and I can't think of a better > "conditional operator" than the one thats already there. > > I often find myself using 'or' to conditionally select a meaningful > value in the absence of a real value: > > person = Person.fetch(id=5) > name = person.name or 'John Doe' > birth_date = person.birth_date or '00-00-' > ssn = person.social_security or 'not provided' While I'm in philosophical agreement with Raymond, it's also true that my current company's code is littered with constructs like yours. So I have to say that it would break too much code. -- Aahz ([EMAIL PROTECTED]) <*> http://www.pythoncraft.com/ The way to build large Python applications is to componentize and loosely-couple the hell out of everything. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] "and" and "or" operators in Py3.0
Raymond Hettinger wrote: > I propose that in Py3.0, the "and" and "or" operators be simplified to > always return a Boolean value instead of returning the last evaluated > argument. But then I would no longer be able to write foo = something or default_value which is one of my favourite Pythonisms! > 3) Even when it isn't being used, the possibility of non-boolean return > value complicates the bytecode and parser. To allow for "and/or", the > conditional opcodes leave the tested value on the stack. In most cases > both branches go directly to a POP_TOP instruction. Since the POP_TOP > shouldn't be executed twice, the body of the positive branch has to > close with a jump over the other branch even when it is empty. The solution to that is for the normal conditional opcodes to pop the stack, and to introduce separate bytecodes for implementing 'and' and 'or'. No need to change the language because of this. -- Greg Ewing, Computer Science Dept, +--+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | [EMAIL PROTECTED] +--+ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] os.path.diff(path1, path2)
Delaney, Timothy (Tim) wrote:
>
> In addition, I would presume that relpath would just return the absolute
> path if passed an absolute path as the second parameter.
I don't think so. Wouldn't you expect the
result of
relpath("/usr/local/foo/bax/grump.c", "/usr/local/flump/grump.c")
to be "../../flump/grump.c" rather than
"/usr/local/flump/grump.c"?
>
> So the above would simply return "/usr/" IMO.
>
> Tim Delaney
> ___
> Python-Dev mailing list
> [email protected]
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/greg.ewing%40canterbury.ac.nz
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | A citizen of NewZealandCorp, a |
Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. |
[EMAIL PROTECTED] +--+
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] "and" and "or" operators in Py3.0
On 9/19/05, Barry Warsaw <[EMAIL PROTECTED]> wrote: > On Mon, 2005-09-19 at 20:03, Guido van Rossum wrote: > > > While you're at it, maybe we should switch to && and || as well? > > That's another thing I always mistype when switching between > > languages... > > Please no! 'and' and 'or' is so readably beautiful. > I completely agree. > > Also, this proposal needs to be considered together with the addition > > of a proper conditional operator, like x?y:z. > > Definitely. Yep. -Brett ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] "and" and "or" operators in Py3.0
On 9/19/05, Raymond Hettinger <[EMAIL PROTECTED]> wrote: > I propose that in Py3.0, the "and" and "or" operators be simplified to > always return a Boolean value instead of returning the last evaluated > argument. > > 1) The construct can be error-prone. When an error occurs it can be > invisible to the person who wrote it. I got bitten in published code > that had survived testing and code review: > > def real(self): > 'Return a vector with the real part of each input element' > # do not convert integer inputs to floats > return self.map(lambda z: type(z)==types.ComplexType and z.real or > z) > > The code fails silently when z is (0+4i). It took a good while to trace > down a user reported error (when Matlab results disagreed with my matrix > module results) and determine that the real() method contained an error. > Even when traced down, I found it hard to see the error in the code. > Now that I know what to look for, it has not happened again, but I do > always have to stare hard at any "and/or" group to mentally verify each > case. > I agree. While I have used the short-circuiting and the return value myself, it has often been for just fun one-liners or when it is extemely simple and I was just too lazy to write out an 'if' statement. A conditional operator is much more proper for this (and, as Guido has said in another email, should be considered as well). > > 2) When going back and forth between languages, it is easy to forget > that only Python returns something other than a boolean. > > > 3) Even when it isn't being used, the possibility of non-boolean return > value complicates the bytecode and parser. To allow for "and/or", the > conditional opcodes leave the tested value on the stack. In most cases > both branches go directly to a POP_TOP instruction. Since the POP_TOP > shouldn't be executed twice, the body of the positive branch has to > close with a jump over the other branch even when it is empty. For > instance, the simplest case: > > if a: > b > > compiles to: > > 1 0 LOAD_NAME0 (a) > 3 JUMP_IF_FALSE8 (to 14) > 6 POP_TOP > > 2 7 LOAD_NAME1 (b) > 10 POP_TOP > 11 JUMP_FORWARD 1 (to 15) > >> 14 POP_TOP > >> 15 LOAD_CONST 0 (None) > 18 RETURN_VALUE > > this could be simpler and faster: > > 1 0 LOAD_NAME0 (a) > 3 JUMP_IF_FALSE8 (to 10) > 2 6 LOAD_NAME1 (b) > 9 POP_TOP > >> 10 LOAD_CONST 0 (None) > 13 RETURN_VALUE > > > Executive summary. Returning only Booleans reduces errors, makes the > code easier to review, follows other language norms, and > simplifies/speeds-up the generated code. Glad the simplification of the bytecode is not the only part of your proposal. =) -Brett ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] "and" and "or" operators in Py3.0
> > 3) Even when it isn't being used, the possibility of non-boolean return > > value complicates the bytecode and parser. To allow for "and/or", the > > conditional opcodes leave the tested value on the stack. In most cases > > both branches go directly to a POP_TOP instruction. Since the POP_TOP > > shouldn't be executed twice, the body of the positive branch has to > > close with a jump over the other branch even when it is empty. > > The solution to that is for the normal conditional opcodes > to pop the stack, and to introduce separate bytecodes for > implementing 'and' and 'or'. You're right. The bytecode code be fixed-up right now with no change to the language :-) That leaves error reduction and clarity as the main motivations for changing 'and' and 'or' to act like '&&' and '||' and for introducing a conditional operator to handle everyone's favorite use cases. Raymond ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] "and" and "or" operators in Py3.0
Raymond Hettinger wrote: > I propose that in Py3.0, the "and" and "or" operators be simplified to > always return a Boolean value instead of returning the last evaluated > argument. Please no. I find things like: def __cmp__(self, other): return (cmp(self.a, other.a) or cmp(self.b, other.b) or cmp(self.c, other.c)) somehow elegant... But I don't know how this can be useful for "and" however. > 1) The construct can be error-prone. When an error occurs it can be > invisible to the person who wrote it. I got bitten in published code > that had survived testing and code review: > > def real(self): > 'Return a vector with the real part of each input element' > # do not convert integer inputs to floats > return self.map(lambda z: type(z)==types.ComplexType and z.real or > z) As others pointed, if lambda is to be possibly removed in py3.0, it would be better to have an example not using it. FWIW, I've never had a problem with that, but however I use the feature... Quite the opposite actually, I even though about overriding and and or to build event-driving expression, which I can't... well, forget about that;) > 2) When going back and forth between languages, it is easy to forget > that only Python returns something other than a boolean. Well, there's a lot of things I miss from Python when going back and forth between languages. You need a better argument to convince me to also miss that one in Python;) I think it's not reasonable to remove the feature without adding a ?: syntax. I personally like the status quo. Regards, Nicolas ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] For/while/if statements/comprehension/generator expressions unification
Hello Josiah, JC> Alexander, JC> The essence of what you have proposed has been proposed (multiple times) before, JC> and I seem to remember it was shot down. To increase my understanding of Python-way, can you (or someone else) explain the reasons why such proposals were rejected? JC> The below functions offer the equivalent of list comprehensions with a JC> final post-processing step. Well, what I was suggesting is not just a cross of two lists but the syntax sugar which would make statements more consistent to the generators/comprehensions and also give some new opportunities. I think that my large proposal can be splitted to several almost-independent ones, each carrying separate features, able to be implemented independently and worth independent reconsidering: 1. Bring 'if'-s from generator/comprehension 'for' syntax to 'for' statement. That's truly inconsistent that one may write list2 = [i for i in list if cond(i)] but cannot write for i in list if cond(i): 2. Bring "several for-s in a row" ability from generators/comprehensions to the statement (and expand it to "several for-s and if-s", of course). We can write list2 = [f(i, j) for i in list1 for j in list2] but cannot write for i in list1 for j in list2: yield f(i, j) That looks inconsistent as well. Yes, for this little case we could do some kind of cross, but what if there are more loops, and/or some of them require filtering by if-s? 3. Bring 'while' into the loops, both statements and iterators. Now no need to worry about "hidden-goto" 'break', especially for the cases of nested loops, while it can be easily checked right inside the looping condition? Now we can easily do for i in largelist while !found: , isn't it nice and simple? -- С уважением, Alexander mailto:[EMAIL PROTECTED] ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] "and" and "or" operators in Py3.0
"Raymond Hettinger" <[EMAIL PROTECTED]> writes: > 2) When going back and forth between languages, it is easy to forget > that only Python returns something other than a boolean. Perl certainly works the same way and I've never heared anybody have problems with that, but that might be because Perl do have the expr?v1:v2 triary operator as well. Most Perl programs use constructs like "a = v1 or v2 or v3" (or even "a ||= v") to its advantage. Regards, Gisle ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
