Re: [Python-Dev] Adding a conditional expression in Py3.0
Jason Orendorff wrote: > Honestly, I think I would prefer this syntax. Examples from real > code, before and after: > > lines = [line for line in pr.block.body > if line.logical_line.strip() != ''] > lines = [for line in pr.block.body: > if line.logical_line.strip() != '': > line] > > row.values = \ > [line[col.start:col.end].strip() for col in columns] > row.values = \ > [for col in columns: line[col.start:col.end].rstrip()] > > return [p for p in self.listdir(pattern) if p.isdir()] > return [for p in self.listdir(pattern): if p.isdir(): p] -1. Too much similarity with the for/if statement. People would say "why can we put a for statement in brackets but not a try statement". 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
Re: [Python-Dev] "and" and "or" operators in Py3.0
Brett Cannon <[EMAIL PROTECTED]> writes: > On 9/20/05, Michael Hudson <[EMAIL PROTECTED]> wrote: > [SNIP] >> I _like_ the explanation of 'and' and 'or' as they are now. They are >> basically control flow constructs -- and have to be to get >> short-circuiting to work -- and adding a coercion to bool at the end >> seems to add complexity, not reduce it (on some levels, anyway). >> > > If you change the definition of 'and' and 'or' to be boolean > comparison operators (as Raymond is proposing) and not as control flow > constructs then is it really that complicated? If you eliminate the short circuiting behaviour of 'or' and 'and' the mobs will be after you with torches and pitchforks (and I'll be with them). > I think it would actually simplify things very slightly since you > just say a boolean is returned instead of the last executed > expression by the operator. You might as well have 'and' be a builtin, then -- or do I misread you? >> > P.S. Simplifying "and" and "or" may create a need to introduce a >> > conditional operator but that is a discussion for another day. >> >> ... which was in the past, I thought. > > It was, but changing 'and' and 'or' does tweak the usefulness of a > conditional operator. Another reason why it's a bad idea :) Cheers, mwh -- I've reinvented the idea of variables and types as in a programming language, something I do on every project. -- Greg Ward, September 1998 ___ 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] Adding a conditional expression in Py3.0
> I think I'd prefer (if then else ) i.e. no > colons. None of the other expression forms (list comprehensions and > generator expressions) involving statement keywords use colons. FWLIW, this was my (strong) preference back at the time of the original discussion. -- 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] Adding a conditional expression in Py3.0
Guido van Rossum <[EMAIL PROTECTED]> writes: >> Given the later addition of generator expressions with mandatory >> parentheses , the mandatory-parentheses version of a conditional expression >> looks less strange to me than it did then ;-). So I could happily use it >> even though I may still lean toward the other option 2 version (then-else) >> due to its not needing ':'s or a third elseif term for chaining. > > I think I'd prefer (if then else ) i.e. no > colons. My problem with this syntax is that it can be hard to read: return if self.arg is None then default else self.arg looks worryingly like return NAME NAME.NAME NAME NAME NAME NAME NAME NAME.NAME to me. > None of the other expression forms (list comprehensions and > generator expressions) involving statement keywords use colons. This is also true. >> *If* you want general community input, I would suggest a runoff ballot with >> those four choices (and a summary of pros and cons of each), or fewer if >> you see any as unacceptible. > > If there's one thing I've learned from the PEP 308 vote, it is that > votes for language don't work. I prefer some discussion on Python-dev > after which I pick one. Well, this is my input (and now I'm going to try and stay out of it). Cheers, mwh -- 59. In English every word can be verbed. Would that it were so in our programming languages. -- Alan Perlis, http://www.cs.yale.edu/homes/perlis-alan/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
On Tue, 2005-09-20 at 22:43, Guido van Rossum wrote: > On 9/20/05, John J Lee <[EMAIL PROTECTED]> wrote: [...] > I don't know that any chips are designed with threading in mind. Fast > threading benefits from fast context switches which benefits from > small register sets. I believe the trend is towards ever large > register sets. Also, multiple processors with shared memory don't > scall all that well; multiple processors with explicit IPC channels > scale much better. All arguments for multi-processing and against > multi-threading. Exactly! I believe the latest MP opteron chipsets use hypertransport busses to directly access the other processor's memory and possibly CPU cache. In theory this means shared memory will not hurt too badly, helping threading. However, memory contention bottlenecks and cache coherency will always mean shared memory hurts more, and will never scale better, than IPC. The reality is threads were invented as a low overhead way of easily implementing concurrent applications... ON A SINGLE PROCESSOR. Taking into account threading's limitations and objectives, Python's GIL is the best way to support threads. When hardware (seriously) moves to multiple processors, other concurrency models will start to shine. In the short term there will be various hacks to try and make the existing plethora of threading applications run better on multiple processors, but ultimately the overheads of shared memory will force serious multi-processing to use IPC channels. If you want serious MP, use processes, not threads. I see anti-GIL threads again and again. Get over it... the GIL rocks for threads :-) -- Donovan Baarda <[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] Adding a conditional expression in Py3.0
On Wed, 2005-09-21 at 11:10, Michael Hudson wrote: > My problem with this syntax is that it can be hard to read: > > return if self.arg is None then default else self.arg > > looks worryingly like > > return NAME NAME.NAME NAME NAME NAME NAME NAME NAME.NAME > > to me. I think that requriing parens helps a lot with the list-of-names problem - it nicely delimits the conditional expression for human readers: return (if self.arg is None then default else self.arg) In particular it breaks up the misleading grouping "return if". Mark Russell ___ 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] Adding a conditional expression in Py3.0
Greg Ewing wrote: > Guido van Rossum wrote: > > >>I think if we go with (if ... then ... else ...) or (if ...: >>... else: ...) we'll have to support elif as well: >> >>(if ... then ... elif ... then ... else ...) >>or >>(if ...: ... elif ...: ... else: ...) > > > One nice thing about "x if b else y" is that it > chains without needing any more keywords: > >x if b else y if c else z > > But if you require parens, it's not so nice: > >(x if b else (y if c else z)) > If Guido chose this form, I would expect the chaining to work like chaining loops in a generator expression, with parentheses being required around the whole thing, rather than around each element in the chain: (x if b else y if c else z) The point being that the result of the conditional expression is exactly one of the options included in the expression, so only one set of parentheses is required. Regards, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.blogspot.com ___ 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
I suppose this is a dead horse now, but I will kick it one more time. Under the rubrics of "explicit is better than implicit" and "there should only be one wat to do it", I would rather see bool_val = bool(foo or bar) instead of having the "or" operator implicitly call bool() for me. There's clear value to the current semantics and it's so easy to get a boolean if you want it, I see no reason for a change. Skip ___ 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/21/05, Donovan Baarda <[EMAIL PROTECTED]> wrote: > The reality is threads were invented as a low overhead way of easily > implementing concurrent applications... ON A SINGLE PROCESSOR. Taking > into account threading's limitations and objectives, Python's GIL is the > best way to support threads. QOTF candidate! (I wonder if this thread could be summarized into a PEP we can use instead of future discussions rehashing the same issues?) -- --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] Adding a conditional expression in Py3.0
Nick Coghlan wrote: > Greg Ewing wrote: >>One nice thing about "x if b else y" is that it >>chains without needing any more keywords: >> >> x if b else y if c else z >> >>But if you require parens, it's not so nice: >> >> (x if b else (y if c else z)) > If Guido chose this form, I would expect the chaining to work like chaining > loops in a generator expression, with parentheses being required around the > whole thing, rather than around each element in the chain: > > (x if b else y if c else z) > > The point being that the result of the conditional expression is exactly one > of the options included in the expression, so only one set of parentheses is > required. Either a or b could be a nested expression so it's important that it be readable in both cases. (a if e then b) ((a1 if e1 then b1) if e then b) (a if e then (a2 if e2 then b2)) ((a1 if e1 then b1) if e then (a2 if e2 then b2)) Without parentheses... (a if e then b) (a1 if e1 then b1 if e then b) (a if e then a2 if e2 then b2) (a1 if e1 then b1 if e then a2 if e2 then b2) I think the parentheses version is clearer. To me it's not as easy to picture what will happen when the condition is in the middle of the expression. Also in the above, is e1 evaluated before e? That would mean the result of e1 (a1 or b1) is thrown away if e if false. So looking at a few alternatives ... (e ? a : b) (e ? (e1 ? a1 : b1) : b) (e ? a : (e2 ? a2 : b2)) (e ? (e1 ? a1 : b1) : (e2 ? a2 : b2)) This better represents a decision tree I think. Each comparison gives one of two possible results which may be another comparison. Using keywords instead... (if e, a else b) (if e, (if e1, a1 else b1) else b) (if e, a else (if e2, a2 else b2)) (if e, (if e1, a1 else b1) else (if e2, a2 else b2)) (if e then a else b) (if e then (if e1 then a1 else b1) else b) (if e then a else (if e2 then a2 else b2)) (if e then (if e1 then a1 else b1) else (if e2 then a2 else b2)) or... possibly... (e selects a else b) (e selects (e1 selects a1 else b1) else b) (e selects a else (e2 selects a2 else b2)) (e selects (e1 selects a1 else b1) else (e2 selects a2 else b2)) I like this one, but maybe a shorter verb would be nice. Other possible words might be "gives", "chooses" or "picks". With the (e?a:b) syntax, I tend to want to switch the '?' and ':' here so that the colon is more consistent with how Python uses it. (e: a ? b) (e: (e1: a1 ? b1) ? b) (e: a ? (e2: a2 ? b2)) (e: (e1: a1 ? b1) ? (e2: a2 ? b2)) That may be more confusing to those who are use to 'C', but clearer to those who use Python as their main programming language. The '?' becomes an 'else' which might be useful in other expressions. Without the colon ... (e selects a ? b) (e selects (e1 selects a1 ? b1) ? b) (e selects a ? (e2 selects a2 ? b2)) (e selects (e1 selects a1 ? b1) ? (e2 selects a2 ? b2)) Or if e evaluates an integer... :-) (e selects a, b, c, ...) I think this would be quite useful and would work perfectly well with boolean expressions as well. The advantage here is that a,b,c etc.. would not be pre evaluated as they are when you use a list or dictionary. (e selects a, b) (e selects (e1 selects a1, b1), b) (e selects a, (e2 selects a2, b2)) (e selects (e1 selects a1, b1), (e2 selects a2, b2)) ( e selects (e1 selects a1, b1), (e2 selects a2, b2), (e3 selects a3, b3) ) Being able to have more than two alternative may reduce the need to nest or chain them in some cases. A variation might be to have negative index's pick from the far end just as list index's do. This would be my choice although I wasn't thinking of it when I started this reply. ;-) 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] Adding a conditional expression in Py3.0
Michael Hudson wrote: >Guido van Rossum <[EMAIL PROTECTED]> writes: > > > >>>Given the later addition of generator expressions with mandatory >>>parentheses , the mandatory-parentheses version of a conditional expression >>>looks less strange to me than it did then ;-). So I could happily use it >>>even though I may still lean toward the other option 2 version (then-else) >>>due to its not needing ':'s or a third elseif term for chaining. >>> >>> >>I think I'd prefer (if then else ) i.e. no >>colons. >> >> > >My problem with this syntax is that it can be hard to read: > >return if self.arg is None then default else self.arg > >looks worryingly like > >return NAME NAME.NAME NAME NAME NAME NAME NAME NAME.NAME > >to me. > > But that's exactly what any language looks like if you get abstract enough: WORD WORD WORD WORD WORD WORD WORD And in fact, one read and understands your return statement just like an English sentence -- word by word from beginning to end. This seems an argument FOR the syntax not against.Moreover, if one uses the proposed parenthesized syntax, even the slightly odd word order of "return if" is mitigated. return (if self.arg is None then default else self.arg) > > >>None of the other expression forms (list comprehensions and >>generator expressions) involving statement keywords use colons. >> >> > >This is also true. > > > >>>*If* you want general community input, I would suggest a runoff ballot with >>>those four choices (and a summary of pros and cons of each), or fewer if >>>you see any as unacceptible. >>> >>> >>If there's one thing I've learned from the PEP 308 vote, it is that >>votes for language don't work. I prefer some discussion on Python-dev >>after which I pick one. >> >> > >Well, this is my input (and now I'm going to try and stay out of it). > >Cheers, >mwh > > > ___ 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] unintentional and unsafe use of realpath()
On Wed, 2005-09-14 at 15:25 -0400, Peter Jones wrote:
[ comments and a patch for sysmodule.c and some configure related files]
... and that patch has obvious problems as well.
Here's a corrected one:
--- Python-2.4.1/pyconfig.h.in.canonicalize 2005-09-14 11:47:04.0
-0400
+++ Python-2.4.1/pyconfig.h.in 2005-09-14 11:47:02.0 -0400
@@ -58,6 +58,9 @@
/* Define if pthread_sigmask() does not work on your system. */
#undef HAVE_BROKEN_PTHREAD_SIGMASK
+/* Define to 1 if you have the `canonicalize_file_name' function. */
+#undef HAVE_CANONICALIZE_FILE_NAME
+
/* Define to 1 if you have the `chown' function. */
#undef HAVE_CHOWN
--- Python-2.4.1/Python/sysmodule.c.canonicalize2005-09-14
11:53:30.0 -0400
+++ Python-2.4.1/Python/sysmodule.c 2005-09-14 11:52:04.0 -0400
@@ -1184,6 +1184,11 @@
char *p = NULL;
int n = 0;
PyObject *a;
+#ifdef HAVE_CANONICALIZE_FILE_NAME
+ argv0 = canonicalize_file_name(argv0);
+ if (argv0 == NULL)
+ Py_FatalError("no mem for sys.argv");
+#else /* ! HAVE_CANONICALIZE_FILE_NAME */
#ifdef HAVE_READLINK
char link[MAXPATHLEN+1];
char argv0copy[2*MAXPATHLEN+1];
@@ -1256,9 +1261,13 @@
#endif /* Unix */
}
#endif /* All others */
+#endif /* ! HAVE_CANONICALIZE_FILE_NAME */
a = PyString_FromStringAndSize(argv0, n);
if (a == NULL)
Py_FatalError("no mem for sys.path insertion");
+#ifdef HAVE_CANONICALIZE_FILE_NAME
+ free(argv0);
+#endif /* HAVE_CANONICALIZE_FILE_NAME */
if (PyList_Insert(path, 0, a) < 0)
Py_FatalError("sys.path.insert(0) failed");
Py_DECREF(a);
--- Python-2.4.1/configure.in.canonicalize 2005-09-14 11:46:00.0
-0400
+++ Python-2.4.1/configure.in 2005-09-14 11:47:22.0 -0400
@@ -2096,8 +2096,8 @@
AC_MSG_RESULT(MACHDEP_OBJS)
# checks for library functions
-AC_CHECK_FUNCS(alarm bind_textdomain_codeset chown clock confstr ctermid \
- execv fork fpathconf ftime ftruncate \
+AC_CHECK_FUNCS(alarm bind_textdomain_codeset canonicalize_file_name chown \
+ clock confstr ctermid execv fork fpathconf ftime ftruncate \
gai_strerror getgroups getlogin getloadavg getpeername getpgid getpid \
getpriority getpwent getsid getwd \
kill killpg lchown lstat mkfifo mknod mktime \
--
Peter
___
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] Adding a conditional expression in Py3.0
Adam wrote: > So looking at a few alternatives ... > [snip] > (e ? (e1 ? a1 : b1) : (e2 ? a2 : b2)) > [snip] > (if e, (if e1, a1 else b1) else (if e2, a2 else b2)) > [snip] > (if e then (if e1 then a1 else b1) else (if e2 then a2 else b2)) > [snip > (e selects (e1 selects a1 else b1) else (e2 selects a2 else b2)) > [snip] > (e: (e1: a1 ? b1) ? (e2: a2 ? b2)) > [snip] > (e selects (e1 selects a1 ? b1) ? (e2 selects a2 ? b2)) > [snip] > (e selects (e1 selects a1, b1), (e2 selects a2, b2)) > Please no more syntax proposals! There were enough in the PEP. It looks like most people support a conditional expression of some sort. We need to leave the syntax to Guido. We've already proved that like the decorators discussions, we can't as a community agree on a syntax. That's what we have a BDFL for. =) 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
On 21 sep 2005, at 12.33, Donovan Baarda wrote: > In the short term there will be various hacks to try and make the > existing plethora of threading applications run better on multiple > processors, but ultimately the overheads of shared memory will force > serious multi-processing to use IPC channels. If you want serious MP, > use processes, not threads. The problem here is that while Python offers some support for thread-based multiprogramming in its standard library: theaad, threading, Queue, etc., there doesn't seem to exist much support for process-based multiprogramming beyond the basics. How is the developer helped? with data sharing, communication, control over running processes, dealing out tasks to be handled, etc. The best way to make people stop complaining about the GIL and start using process-based multiprogramming is to provide solid, standardized support for process-based multiprogramming. //Simon ___ 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] Adding a conditional expression in Py3.0
On 9/21/05, Steven Bethard <[EMAIL PROTECTED]> wrote: > Please no more syntax proposals! There were enough in the PEP. It > looks like most people support a conditional expression of some sort. > We need to leave the syntax to Guido. We've already proved that like > the decorators discussions, we can't as a community agree on a syntax. > That's what we have a BDFL for. =) Another QOTFcandidate! -- --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] GIL, Python 3, and MP vs. UP
> The best way to make people stop complaining about the GIL and start > using > process-based multiprogramming is to provide solid, standardized support > for process-based multiprogramming. 100% agreed. I needed a portable way to know if a program was already running (and then to send it a simple command), the only simple solution I found was to listen on a local TCP socket and store the port number in a file in a known location. Not very elegant IMO. Regards Antoine. ___ 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)
> > But this begs the question: What is relpath good for, anyway? > > A couple of use cases I've encountered: > Another one: - Build tools that work with paths alot can really improve their log readability if relative paths can be used to keep paths short rather than the common fallback of just making everything an absolute path. Trent -- Trent Mick [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] Adding a conditional expression in Py3.0
> > I think I'd prefer (if then else ) i.e. no > > colons. > > My problem with this syntax is that it can be hard to read: > > return if self.arg is None then default else self.arg > > looks worryingly like > > return NAME NAME.NAME NAME NAME NAME NAME NAME NAME.NAME That can already be written in Python: return self.arg or default And maybe the syntax of the future conditional operator could be extended so that: return self.arg else default Would be equivalent to the previous line. For stuff were a conditional expression really is needed, like in: return if self.arg then "yes" else "no" One would hope that whoever writes the conditional expression doesn't make the expressions so long and complicated that it looks like NAME NAME.NAME NAME... It doesn't matter which syntax proposal that wins, it will still be very tempting to write unreadable code with it (think nested/chained conditional expressions). That (and the fact that I've never felt a real need for a conditional expression thanks to the "or" operator) is my very humble argument against it. -- mvh Björn ___ 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
> The best way to make people stop complaining about the GIL and start > using process-based multiprogramming is to provide solid, standardized > support for process-based multiprogramming. +100 Huge amounts of effort would have to be invested to remove the GIL for the benefit of threads. Not only would the effort be huge, the difficulty and complexity of writing extension modules would be increased. Regardless of the arguments about SMP systems and the GIL, Python should provide as much support for process-based multi-programming as it does for threading. How about sinking that same effort into better Python support for process-based multi-programming? All the categories that Simon suggested are great candidates for the targets of this effort. Are there any existing efforts that I don't know about? 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] GIL, Python 3, and MP vs. UP
Antoine Pitrou <[EMAIL PROTECTED]> wrote: > > > > The best way to make people stop complaining about the GIL and start > > using > > process-based multiprogramming is to provide solid, standardized support > > for process-based multiprogramming. > > 100% agreed. I needed a portable way to know if a program was already > running (and then to send it a simple command), the only simple solution > I found was to listen on a local TCP socket and store the port number in > a file in a known location. Not very elegant IMO. On *nix, use a unix domain socket (location in the filesystem which acts as a listening socket). On Windows, you can use cTypes, pywin32, etc., to create a global mutex and/or COM interface. Alternatively, you can write your own cross-platform registry for services, have it running on your machines all the time, and never worry again. Or one can pick a port to use on all systems and not bother with the the file listing the port, ignore domain sockets, COM interfaces, and work-alikes. In terms of IPC, the application may determine which is most usable. If one had a service distributed across multiple machines, sockets are necessary. If one only needed local access, shared memory (perhaps via a memory mapped file) would be significantly faster. In the case of multiple machines with multiple processors, one could opt for shared memory locally but sockets globally, which could complicate the interface, result in non-uniform performance for transfers, which may then necessate complicating the application in order to gain the highest throughput (I've done this previously using MPI, it can be a PITA). - 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] os.path.diff(path1, path2)
On Wed, 21 Sep 2005 02:55:56 +0200, Greg Ewing <[EMAIL PROTECTED]> wrote: > Both of these happen to involve pathnames that exist on > the currrently available file system, but I can easily > imagine cases where that would not be so. E.g. I might > be generating pathames to go into a tar file that will > be unpacked in a different place or on another system. imho, it would be a good thing for a future 'file system handling module' to build more of an abstracted tree-like graph that may or may not be mappable (and may or may not be used in a particular case to actually map) to existing objects on a particular system. for example, i find it a bit in my way a lot of times that all the locators i have os.path handle for me are written according to the os, not in a unified, abstracted way. given that there are a number of applications (xml documents, file system handling, urls, archives...) that have very similar requirements, maybe there is a useful abstraction that covers these and other cases. some nitty-gritty details could be captured by suitable specializations of the general case. _w ___ 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 21-sep-2005, at 0:10, Bob Ippolito wrote: My use case for this isn't so much about threads, but plug-ins. Writing multiple Python-based plug-ins for an application is always a mess, because they share too much (sys.modules, sys.path, etc.). PyObjC would benefit greatly from this feature, because you can write Python-based plug-ins for any Cocoa app that supports plug-ins, even if they're otherwise unaware of Python's existence. There are workarounds, of course, with import hooks and similar hacks. I think that mod_python would also benefit from this, and probably other such systems. For PyObjC having multiple interpreters in a process would cause me severe headaches. Due to the nature of PyObjC it would be way too easy to accidently access objects from one interpreter in another interpreter (in a hypothetical universe where it would be easy to use multiple interpreters). And lets not get started about the GIL, I don't think its accidental that PyGILState_Ensure only works with one interpreter. A system like Java's classloader would be helpfull, where the classloader of a class is used to load the classes used by that class. I have no idea if this can be adapted to python at all. A strict coding style seems to work for now. Ronald smime.p7s Description: S/MIME cryptographic signature ___ 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 need to write a lot more suppression rules for gentoo.) This could be due to your using GCC 4. Apparently, gcc 4 is willing to inline Py_ADDRESS_IN_RANGE even though it appears at the end of the file, at -O3. To suppress that, you can declare the function as __attribute__((noinline)). You will need to conditionalize this on gcc, but not only that: it appears that noinline was one of the more recent additions. I'm not sure when it was added, but apparently, it is present in 3.3 and later. Alternatively, just recompiling the file without -O3 also works. Regards, Martin ___ 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] Adding a conditional expression in Py3.0
BJörn Lindqvist <[EMAIL PROTECTED]> writes: >> My problem with this syntax is that it can be hard to read: >> >> return if self.arg is None then default else self.arg >> >> looks worryingly like >> >> return NAME NAME.NAME NAME NAME NAME NAME NAME NAME.NAME > > That can already be written in Python: No it can't! Would you believe I had this exact conversation two and a half years ago? :) > return self.arg or default Consider what happens if self.arg is 0, here. Cheers, mwh -- If I had wanted your website to make noise I would have licked my finger and rubbed it across the monitor. -- signature of "istartedi" on slashdot.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
On 9/21/05, Michael Hudson <[EMAIL PROTECTED]> wrote: > Brett Cannon <[EMAIL PROTECTED]> writes: > > > On 9/20/05, Michael Hudson <[EMAIL PROTECTED]> wrote: > > [SNIP] > >> I _like_ the explanation of 'and' and 'or' as they are now. They are > >> basically control flow constructs -- and have to be to get > >> short-circuiting to work -- and adding a coercion to bool at the end > >> seems to add complexity, not reduce it (on some levels, anyway). > >> > > > > If you change the definition of 'and' and 'or' to be boolean > > comparison operators (as Raymond is proposing) and not as control flow > > constructs then is it really that complicated? > > If you eliminate the short circuiting behaviour of 'or' and 'and' the > mobs will be after you with torches and pitchforks (and I'll be with > them). > I am not suggesting that at all. I would put myself on a pike first before the mob got there. =) > > I think it would actually simplify things very slightly since you > > just say a boolean is returned instead of the last executed > > expression by the operator. > > You might as well have 'and' be a builtin, then -- or do I misread > you? > I think you might be misreading me, but since Guido seems to have made the decision that 'and' and 'or' are not changing there is no need to try to clarify. > >> > P.S. Simplifying "and" and "or" may create a need to introduce a > >> > conditional operator but that is a discussion for another day. > >> > >> ... which was in the past, I thought. > > > > It was, but changing 'and' and 'or' does tweak the usefulness of a > > conditional operator. > > Another reason why it's a bad idea :) > =) -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] Alternative name for str.partition()
I know I'm coming too late to this discussion, but just for completeness
sake let me mention that the OCaml standard List module uses 'partition'
already in the sense that most mathematically educated people would
understand it:
val partition : ('a -> bool) -> 'a list -> 'a list * 'a list
partition p l returns a pair of lists (l1, l2), where l1 is the list
of all the elements of l that satisfy the predicate p, and l2 is the
list of all the elements of l that do not satisfy p. The order of
the elements in the input list is preserved.
Haskell's Data.List.partion is defined the same way.
So this seems to be generally agreed upon, at least for functional
programming languages. This is why I have to agree with Greg:
On Tue, Aug 30, 2005 at 12:49:26PM +1200, Greg Ewing wrote:
> A more descriptive name than 'partition' would be 'split_at'.
'split_at' is really what's happening. (I came up with it independently
of Greg, if that is any evidence).
--
Chris Stork <> Support eff.org! <> http://www.ics.uci.edu/~cstork/
OpenPGP fingerprint: B08B 602C C806 C492 D069 021E 41F3 8C8D 50F9 CA2F
___
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] Adding a conditional expression in Py3.0
Guido: When you invited resumed discussion, did you intend to proceed from where the revised PEP left off (with a few variations on the table), or to start over from point zero (with potentially anything and everything on the table). In particular, do we need to rehash the reasons for rejection of the backwards if-else proposal that a few seem to wish to resurrect? Many people, perhaps most, including me, read exp1 if exp2 else exp3 # as cond if etrue else efalse # in direct analogy with cond ? etrue : efalse # from C I mentally read ?: in C as if/else! It took a few readings of the proposal to even realize that it the order flipped. There there is the obvious analogy with Python's if cond: etrue else: efalse with 'if' moved over to the first : position (and the : then removed) but with 'else' still between the alternatives (and the second : also removed). Then there are conditional functions, in various languages, iff(cond, etrue, efalse), which as far as I know always have the expressions in that order. Need I continue? Or is the dead still dead? 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] GIL, Python 3, and MP vs. UP
(Interestign to see the PyObjC folks disagree. :-) On 9/21/05, Ronald Oussoren <[EMAIL PROTECTED]> wrote: > > On 21-sep-2005, at 0:10, Bob Ippolito wrote: > > > > My use case for this isn't so much about threads, but plug-ins. > > Writing multiple Python-based plug-ins for an application is always a > > mess, because they share too much (sys.modules, sys.path, etc.). > > PyObjC would benefit greatly from this feature, because you can write > > Python-based plug-ins for any Cocoa app that supports plug-ins, even > > if they're otherwise unaware of Python's existence. There are > > workarounds, of course, with import hooks and similar hacks. I think > > that mod_python would also benefit from this, and probably other such > > systems. > > For PyObjC having multiple interpreters in a process would cause me > severe headaches. Due to the nature of PyObjC it would be way too > easy to accidently access objects from one interpreter in another > interpreter (in a hypothetical universe where it would be easy to use > multiple interpreters). And lets not get started about the GIL, I > don't think its accidental that PyGILState_Ensure only works with one > interpreter. Actually Python itself has a hard time keeping multiple interpreters truly separate. Also of course there are some shared resources maintained by the operating system: current directory, open file descriptors, signal settings, child processes, that sort of thing. If we were to completely drop this feature, we could make built-in classes modifyable. > A system like Java's classloader would be helpfull, where the > classloader of a class is used to load the classes used by that > class. I have no idea if this can be adapted to python at all. A > strict coding style seems to work for now. You can do something like this using the restricted execution support, which works by setting the __builtins__ name in a dict where you exec code, and overriding __import__ in that __builtins__ dict. (I can't explain it too well in one paragraph, just go look up the rexec.py source code.) It's not great for guaranteeing there's absolutely no escape possible from the sandbox, but it works well enough to make accidental resource sharing a non-issue (apart from the OS shared resources and the built-in types). A misfeature (for this purpose) is that certain kinds of introspection are disabled (this was of course to enable restricted execution). I'd be willing to entertain improvements that improve the insulation this provides. -- --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] Adding a conditional expression in Py3.0
I think a recap of past arguments is useful. Me-too votes are not. i will read everything and pick a syntax and that's it. We can do it in Python 2.5. On 9/21/05, Terry Reedy <[EMAIL PROTECTED]> wrote: > Guido: > > When you invited resumed discussion, did you intend to proceed from where > the revised PEP left off (with a few variations on the table), or to start > over from point zero (with potentially anything and everything on the > table). In particular, do we need to rehash the reasons for rejection of > the backwards if-else proposal that a few seem to wish to resurrect? > > Many people, perhaps most, including me, read > > exp1 if exp2 else exp3 # as > cond if etrue else efalse # in direct analogy with > cond ? etrue : efalse # from C > > I mentally read ?: in C as if/else! It took a few readings of the proposal > to even realize that it the order flipped. > > There there is the obvious analogy with Python's > if cond: etrue > else: efalse > with 'if' moved over to the first : position (and the : then removed) but > with 'else' still between the alternatives (and the second : also removed). > > Then there are conditional functions, in various languages, iff(cond, > etrue, efalse), which as far as I know always have the expressions in that > order. > > Need I continue? Or is the dead still dead? > > 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/guido%40python.org > -- --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] GIL, Python 3, and MP vs. UP
Bob Ippolito <[EMAIL PROTECTED]> writes: > Personally my biggest issue with the way the CPython VM works is that > you can't reliably do multiple interpreters in a single process. If > that worked well, you could start an independent interpreter per > thread and with a per-interpreter GIL you'd have pretty much > everything you needed... but this would horribly break the C API and > may be a performance hit. > > My use case for this isn't so much about threads, but plug-ins. > Writing multiple Python-based plug-ins for an application is always a > mess, because they share too much (sys.modules, sys.path, etc.). > PyObjC would benefit greatly from this feature, because you can write > Python-based plug-ins for any Cocoa app that supports plug-ins, even > if they're otherwise unaware of Python's existence. There are > workarounds, of course, with import hooks and similar hacks. I think > that mod_python would also benefit from this, and probably other such > systems. Just a note in case you didn't know this already, probably off-topic for python-dev, but not meant as advertisement for py2exe): the same (plug-in) problem occurs with an inprocess COM server and a Python client program, or more than one inproc COM server in any client program. The 0.6 py2exe release with it's bundle-file option allows to build COM dlls (and client EXE programs, if needed) that APPEAR to have a statically linked copy of Python##.dll, and so have several CPython VMs running in the same process. In case anybody want's to take a look or experiment with it. Thomas ___ 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] Adding a conditional expression in Py3.0
Ron Adam wrote: > ( e selects (e1 selects a1, b1), > (e2 selects a2, b2), > (e3 selects a3, b3) ) I think you've just reinvented the case statement, which disagrees with "if" over the order of true and false clauses. For a conditional expression, I think the choices are really down to the following, which was already way too much freedom last (http://www.python.org/peps/pep-0308.html) time: (1) Should it be done at all? + It would be useful, and avoid certain types of bugs. - It would encourage bracketing instead of indentation PEP 308 decided "not yet, anyhow" (2) How many of the keywords (if ... then ... else ... elif) should be dropped? (if test then True else False) + standard english + standard programming idiom - adds a "then" keyword (if test True else False) + better parallels the if: statement - starts to run together (if test1 Val1 elif test2 Val2 elif test3 Val3) + parallels the if: statement - encourages overly long code * but still better than nested parens PEP 308 wasn't entirely clear; the words said to keep "elif", but the examples did not. There was some disagreement on which of the other three keywords to represent explicitly. (Rather than only by position.) (3) What order should the clauses appear? (if test then True else False) (if test1 then Val1 elif test2 Val2 elif test3 Val3 else Val4) + Natural Order - do we need "then"? (True if normal else False) (Val1 if test1 else Val2 if test2 else Val3 if test3 else Val4) + Best order for normal/default conditionals + Best order in general if we weren't used to left-right processing - But we *do* expect left->right almost everywhere except assignments PEP 308 made it clear that "else" should be last. Putting the condition before the "then" was not as clearcut. (4) What sort of punctuation should augment or replace the keywords? PEP 308 suggested avoiding punctuation, but it wasn't clearcut. -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] GIL, Python 3, and MP vs. UP
On 21-sep-2005, at 21:04, Guido van Rossum wrote: A system like Java's classloader would be helpfull, where the classloader of a class is used to load the classes used by that class. I have no idea if this can be adapted to python at all. A strict coding style seems to work for now. You can do something like this using the restricted execution support, which works by setting the __builtins__ name in a dict where you exec code, and overriding __import__ in that __builtins__ dict. (I can't explain it too well in one paragraph, just go look up the rexec.py source code.) It's not great for guaranteeing there's absolutely no escape possible from the sandbox, but it works well enough to make accidental resource sharing a non-issue (apart from the OS shared resources and the built-in types). A misfeature (for this purpose) is that certain kinds of introspection are disabled (this was of course to enable restricted execution). Replacing __builtins__ hadn't crossed my mind yet. My first cut at building plugins played games with __path__, Bob then replaced that by a version that actually works using py2app. The sandbox doesn't need to closed for plugins, it's only needed to avoid accidental naming clashes (two independent plugins that contain a util module). I don't know if restrictions on introspection would be an issue, I haven't felt the need to write real plugins yet. Well other than the 'look I've a python interpreter inside app goes here>' demo plugins. Ronald smime.p7s Description: S/MIME cryptographic signature ___ 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] Adding a conditional expression in Py3.0
Steven Bethard wrote: > Please no more syntax proposals! There were enough in the PEP. It > looks like most people support a conditional expression of some sort. > We need to leave the syntax to Guido. We've already proved that like > the decorators discussions, we can't as a community agree on a syntax. > That's what we have a BDFL for. =) No problem, I'll go back to watching this interesting discussion and see what happens. :-) I really should have deleted all but the last one anyway and probably should have moved it to python-list at that point since it's quite different from whats being proposed I think. 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] GIL, Python 3, and MP vs. UP
At 12:04 PM 9/21/2005 -0700, Guido van Rossum wrote: >Actually Python itself has a hard time keeping multiple interpreters >truly separate. Also of course there are some shared resources >maintained by the operating system: current directory, open file >descriptors, signal settings, child processes, that sort of thing. > >If we were to completely drop this feature, we could make built-in >classes modifyable. I'd personally much rather we got back the ability to change the type of an instance of a builtin to that of a Python subclass of that builtin type, or to change it back. I have more use cases for that than for actually modifying builtins. (E.g. "observable" lists/dicts, hooking module __getattr__, etc.) > > A system like Java's classloader would be helpfull, where the > > classloader of a class is used to load the classes used by that > > class. I have no idea if this can be adapted to python at all. A > > strict coding style seems to work for now. > >You can do something like this using the restricted execution support, >which works by setting the __builtins__ name in a dict where you exec >code, and overriding __import__ in that __builtins__ dict. (I can't >explain it too well in one paragraph, just go look up the rexec.py >source code.) > >It's not great for guaranteeing there's absolutely no escape possible >from the sandbox, but it works well enough to make accidental resource >sharing a non-issue (apart from the OS shared resources and the >built-in types). A misfeature (for this purpose) is that certain kinds >of introspection are disabled (this was of course to enable restricted >execution). Another misfeature is that some C-level Python code expects to obtain sys.modules, builtins, etc. via the interpreter struct. Thus, you tend to have to reimplement those things in Python to get them to respect a virtualization of sys.modules. I have to admit I've only dabbled in attempting this, just long enough to hit a stumbling block or two and then discover that they were because sys.modules is in the interpreter struct. Of course, my next thought then was to just expose the multi-interpreter API as an extension module, so that you could create interpreters from Python code. The project I'd originally planned to do this for never materialized though, so I never actually attempted it. My thought, though, was that by swapping the current interpreter of the thread state when crossing code boundaries, you could keep both the Python-level and C-level code happy. However, it might also suffice to have a way to switch in and out the interpreter configuration (sys.modules, sys.__dict__, and __builtins__ at minimum; I don't have any clear use case for changing the three codec_* vars at the moment). >I'd be willing to entertain improvements that improve the insulation >this provides. Since there's already a way to change __builtins__ in the threadstate, maybe the C API could be changed to obtain the six interpreter variables via builtins rather than the other way around. This would allow us to drop the multi-interpreter API from C (along with support for restricted mode) but still allow complete virtualization from inside Python code. The steps would be: 1. Remove restricted mode support 2. Change the tstate structure to have a 'builtins' 3. Change code that does tstate->interp lookups to instead lookup special names in the tstate's builtins At that point, you can exec code with new builtins to bootstrap a virtual Python, subject to limitations like being able to load a given extension module only once. Systems like mod_python that use the multi-interpreter API now would just need to bootstrap a new __builtins__. Sadly, this doesn't *really* cure the GIL-ensure problem, in that you still don't have a specially-distinguished __builtins__ to use when you call into Python from a C-started thread. On the other hand, I suspect that the use cases for that, and the use cases for virtualization don't overlap much, so having a distinguished place to hold the "default" (i.e. initial) builtins probably doesn't hurt virtualization much, since you can always *modify* that set of builtins if you need to. ___ 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] Alternative name for str.partition()
"Christian Stork" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > On Tue, Aug 30, 2005 at 12:49:26PM +1200, Greg Ewing wrote: >> A more descriptive name than 'partition' would be 'split_at'. > > 'split_at' is really what's happening. (I came up with it independently > of Greg, if that is any evidence). At least semi-seriously, how about condensing 'split_at' to 'splat', a variant of split (and splash), as in 'hit the string on the separator, and with a splat, split it into 3 pieces'. (See dictionary.com for various meanings.) 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] possible memory leak on windows (valgrind report)
On 9/21/05, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > Neal Norwitz wrote: > > (I need to write a lot more suppression rules for gentoo.) > > This could be due to your using GCC 4. Apparently, gcc 4 > is willing to inline Py_ADDRESS_IN_RANGE even though it > appears at the end of the file, at -O3. I don't think I'm using gcc 4. > To suppress that, you can declare the function as > __attribute__((noinline)). You will need to conditionalize > this on gcc, but not only that: it appears that noinline > was one of the more recent additions. I'm not sure when > it was added, but apparently, it is present in 3.3 and > later. This is a good point. I recall when I made Py_ADDRESS_IN_RANGE the docs said that anything could be inlined. I think it would be good to use this attribute (conditionally of course). I'll try to remember to add this. I wonder if using attributes for other features would gain us much. I would really like to be able to use attributes for PyArgs_ParseTuple(), but I don't think gcc can use user defined formats. It's only printf AFAIR. Does anyone know if this isn't true and we can define our own format -> type mappings? 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] bool(iter([])) changed between 2.3 and 2.4
[Guido van Rossum] > Could you at least admit that this was an oversight and not try to > pretend it was intentional breakage? Absolutely. I completely missed this one. 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] Adding a conditional expression in Py3.0
Jim Jewett wrote: > > (3) What order should the clauses appear? > (if test then True else False) > (if test1 then Val1 elif test2 Val2 elif test3 Val3 else Val4) > + Natural Order > - do we need "then"? > (True if normal else False) > (Val1 if test1 else Val2 if test2 else Val3 if test3 else Val4) > + Best order for normal/default conditionals > + Best order in general if we weren't used to left-right processing > - But we *do* expect left->right almost everywhere except assignments + out-of-order evaluation is already used in LC's and GE's + declarative style, rather than imperative To try and make that last point clearer: real = (z.real if isinstance(z, ComplexType) else z) This translates directly into in words as: "Set real to be the real component of z if z is a complex number, otherwise set it to be the same as z" vs. real = (if isinstance(z, ComplexType) then z.real else z) I can't put that into words without changing the order of the elements either by re-using the phrasing from above (with the condition between the two outcomes), or else describing the statement form instead of the expression form by bringing the condition all the way to the front: "If z is a complex number, then set real to be the real component of z, otherwise set real to be the same as z" I find it to be like with GE's and LC's - the phrasing works better with the expression at the front, because you say basically what you're doing, then you put the additional constraints on it (i.e., which iterable is used as the data source, and what filtering is applied to the elements of that iterable) I think I've said enough on this point though, so I'll try to bite my tongue until Guido makes a decision. . . Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.blogspot.com ___ 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
I agree with Skip. Bill > I suppose this is a dead horse now, but I will kick it one more time. > > Under the rubrics of "explicit is better than implicit" and "there should > only be one wat to do it", I would rather see > > bool_val = bool(foo or bar) > > instead of having the "or" operator implicitly call bool() for me. There's > clear value to the current semantics and it's so easy to get a boolean if > you want it, I see no reason for a change. > > Skip ___ 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
> The best way to make people stop complaining about the GIL and start > using > process-based multiprogramming is to provide solid, standardized support > for process-based multiprogramming. And the model provided by the thread abstraction is a good API for that support... Bill ___ 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] bool(iter([])) changed between 2.3 and 2.4
Raymond Hettinger wrote: > The Boolean value of an > iterator is certainly not promised by the iterator protocol as specified > in the docs or the PEP. But if the docs don't mention anything about true or false values for some particular type, one tends to assume that all values are true, as is the default for user-defined classes. -- 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] Adding a conditional expression in Py3.0
Ron Adam wrote: > (a if e then b) > ((a1 if e1 then b1) if e then b) > (a if e then (a2 if e2 then b2)) > ((a1 if e1 then b1) if e then (a2 if e2 then b2)) I think you mean 'else' rather than 'then' in all those, don't you? -- 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] Adding a conditional expression in Py3.0
Greg Ewing wrote: > Ron Adam wrote: > > >>(a if e then b) >>((a1 if e1 then b1) if e then b) >>(a if e then (a2 if e2 then b2)) >>((a1 if e1 then b1) if e then (a2 if e2 then b2)) > > > I think you mean 'else' rather than 'then' in all > those, don't you? Yes of course, thanks for correcting. ___ 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] Adding a conditional expression in Py3.0
Gary Herron wrote: > And in fact, one read and understands your return statement just like an > English sentence -- word by word from beginning to end. This seems an > argument FOR the syntax not against.Moreover, if one uses the > proposed parenthesized syntax, even the slightly odd word order of > "return if" is mitigated. The reason I like "a if b else c" is because it has the most natural word order. In English, My dog is happy if he has a bone, else sad. sounds much more natural than My dog is, if he has a bone, happy, else sad. In return statements, return self.arg if self.arg is not None else default looks quite all right to me. I think the fact that it does resemble English word order so much prevents the word-soup problem from occurring. Interestingly, it looks *more* odd to me if parens are included: return (self.arg if self.arg is not None else default) I think this is because, without the parens, I tend to read the "if" as applying to the whole phrase "return self.arg", not just to the "self.arg". The English analogy is rewriting "My dog is happy if he has a bone" as "If he has a bone, my dog is happy", which also sounds natural, whereas "My dog is, if he has a bone, happy" sounds unnatural. So I still prefer "a if b else c" to any of the alternatives, and I still think parens should not be required. -- 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] bool(iter([])) changed between 2.3 and 2.4
On 9/21/05, Raymond Hettinger <[EMAIL PROTECTED]> wrote: > [Guido van Rossum] > > Could you at least admit that this was an oversight and not try to > > pretend it was intentional breakage? > > Absolutely. I completely missed this one. Thanks; spoken like a man. I strongly feel that this needs to be corrected in 2.5. Iterators should have neither __len__ nor __nonzero__. I see mostly agreement that this is a misfeature. We don't really want to start writing code like this: while it: x = it.next() ...process x... when we can already write it like this: for x in it: ...process x... do we? Keeping a special API to allow a more efficient implementation of __reversed__ is fine. -- --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] Adding a conditional expression in Py3.0
Terry Reedy wrote: > Many people, perhaps most, including me, read > > exp1 if exp2 else exp3 # as > cond if etrue else efalse # in direct analogy with > cond ? etrue : efalse # from C I'd have thought only Forth programmers would be prone to that! It would surprise me greatly if it's really true that *most* people would read it that way. Especially given that, in real code, you're not going to be looking at abstract names like exp1, exp2, exp3, but (hopefully) something a lot more meaningful. Can you honestly say that you would read return red_value if color == 'red' else blue_value as if red_value: return color == 'red' else: return blue_value ? -- 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
[Python-Dev] Mapping Darwin 8.2.0 to Mac OS X 10.4.2 in platform.py
The platform module has a way to map system names such as returned by uname() to marketing names. It maps SunOS to Solaris, for example. But it doesn't map Darwin to Mac OS X. I think I know how to map Darwin version numbers to OS X version numbers: from http://www.opensource.apple.com/darwinsource/ it is clear that OS X 10.a.b corresponds to Darwin (a+4).b, except for OS X versions <= 10.1. I'd be happy to write the code and add it to system_alias() in platform.py. Is this a good idea? -- --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] Mapping Darwin 8.2.0 to Mac OS X 10.4.2 in platform.py
On 9/21/05, Guido van Rossum <[EMAIL PROTECTED]> wrote: > The platform module has a way to map system names such as returned by > uname() to marketing names. It maps SunOS to Solaris, for example. But > it doesn't map Darwin to Mac OS X. I think I know how to map Darwin > version numbers to OS X version numbers: from > http://www.opensource.apple.com/darwinsource/ it is clear that OS X > 10.a.b corresponds to Darwin (a+4).b, except for OS X versions <= > 10.1. I'd be happy to write the code and add it to system_alias() in > platform.py. Is this a good idea? I forgot. The current code recognizes 'Rhapsody' and maps it to "MacOS X Server". But I don't see any evidence that Apple still uses the code name Rhapsody. Does uname ever return 'Rhapsody'? -- --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] Mapping Darwin 8.2.0 to Mac OS X 10.4.2 in platform.py
On Sep 21, 2005, at 11:26 PM, Guido van Rossum wrote: > The platform module has a way to map system names such as returned by > uname() to marketing names. It maps SunOS to Solaris, for example. But > it doesn't map Darwin to Mac OS X. I think I know how to map Darwin > version numbers to OS X version numbers: from > http://www.opensource.apple.com/darwinsource/ it is clear that OS X > 10.a.b corresponds to Darwin (a+4).b, except for OS X versions <= > 10.1. I'd be happy to write the code and add it to system_alias() in > platform.py. Is this a good idea? No, it's not. There are other mismatches between Mac OS X version and Darwin kernel version (e.g. 10.3.0 and 10.3.1 used the same kernel version). The only correct way to do it with public API is to use gestalt, which platform.mac_ver() does. There are other ways (reading a plist, parsing the output of /usr/bin/sw_vers, using the same SPI that /usr/bin/sw_vers uses...), but gestalt is the only public API. The one caveat with platform.mac_ver() is that it was broken for some version(s) of Python. I don't remember when that was fixed. It definitely works for Python 2.3.5 (ships with Mac OS X 10.4) and Python 2.4.1, but I'm relatively certain it was broken with the Python 2.3.0 that shipped with Mac OS X 10.3, and perhaps also the Python 2.2.0 that shipped with Mac OS X 10.2. Anyway, this information isn't in the uname. You can guess with the uname, but it requires lots of special cases and maintenance. -bob ___ 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] bool(iter([])) changed between 2.3 and 2.4
[Guido] > I strongly feel that this needs to be corrected in 2.5. Iterators > should have neither __len__ nor __nonzero__. Right. I'll get it fixed-up. [Terry Reedy] > I presume there were two reasons: internal efficiency of > preallocations > (list(some_it) for example) [Guido] > This could have been implemented without making the > implementation details public. I see a way to do that by renaming the __len__ method to some private name for internal use. This would preserve the performance gains while still restoring the public API. 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] GIL, Python 3, and MP vs. UP
Bill Janssen <[EMAIL PROTECTED]> wrote: > > > The best way to make people stop complaining about the GIL and start > > using > > process-based multiprogramming is to provide solid, standardized support > > for process-based multiprogramming. > > And the model provided by the thread abstraction is a good API for that > support... While creating a thread is generally quite easy, the threading abstraction assumes globally shared memory. Certainly there are multiprocessing systems which handle transferring of data between disparate memories automatically (Linda/PyLinda, POSH, etc.), but no doubt some users will want a more fine-grained control of data transfer (and this is saying nothing of the shared-memory model's currently horrible performance in Python). As such, there is always the option of using the tried and true MPI and PyMPI, which looks to have been recently updated. Or even XMLRPC and PickleRPC over sockets and/or mmap'd files. Then again, with how easy it is to distribute workloads using (Py)Linda, I'd be hard pressed to suggest any other module for multiprocessing into the standard library (unless it was a work-alike)...though perhaps we should wait until it has been sped up a bit, supports more data types, etc. - 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] os.path.diff(path1, path2)
On 9/20/05, Greg Ewing <[EMAIL PROTECTED]> wrote: > Matthias Andreas Benkard wrote: > > * In a recent project, I had occasion to store pathnames of >picture files in a relational database. I wanted to store >the pathnames relative to a user-chosen "Pictures" >directory, so that it could be moved without having to >update all the pathnames in the database. Curator does the same, for the same reasons. http://furius.ca/curator/ Also, you can burn the static HTML files to CDROM, and the links still all work. That was the main motivator for this. cheers, ___ 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 wonder if using attributes for other features would gain us much. I > would really like to be able to use attributes for > PyArgs_ParseTuple(), but I don't think gcc can use user defined > formats. It's only printf AFAIR. Does anyone know if this isn't true > and we can define our own format -> type mappings? Yes and no. Yes, it cannot do user-defined formats, but no, it is not just *printf. They support gcc_diag and gcc_cxxdiag for their own internal printf-like functions (error() and warning()); they also support strftime and strfmon. Regards, Martin ___ 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] Mapping Darwin 8.2.0 to Mac OS X 10.4.2 in platform.py
On 22-sep-2005, at 5:26, Guido van Rossum wrote: The platform module has a way to map system names such as returned by uname() to marketing names. It maps SunOS to Solaris, for example. But it doesn't map Darwin to Mac OS X. I think I know how to map Darwin version numbers to OS X version numbers: from http://www.opensource.apple.com/darwinsource/ it is clear that OS X 10.a.b corresponds to Darwin (a+4).b, except for OS X versions <= 10.1. I'd be happy to write the code and add it to system_alias() in platform.py. Is this a good idea? There's no good reason to assume that the mapping from kernel version to marketing version will stay the same in the future. The savest way to get the marketing version of the currently running OSX is to run / usr/sbin/sw_vers and parse its output. There might also be a public API for getting the same information. Py2app, and specifically the bdist_mpkg component of that, contains code to parse sw_vers output. Ronald -- --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/ ronaldoussoren%40mac.com smime.p7s Description: S/MIME cryptographic signature ___ 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
