Re: [Python-Dev] Pervasive socket failures on Windows
[Tim] > ... FD_SETSIZE is the maximum number of distinct fd's an fdset can > hold, and the numerical magnitude of any specific fd has nothing to do > with that in general (they may be related in fact on Unix systems that > implement an fdset as "a big bit vector" -- but Windows doesn't work > that way, and neither do all Unix systems, and nothing in socket > specs requires an implementation to work that way). Hmm. Looks like POSIX _does_ require that. Can't work on Windows, though. I have a distinct memory of a 64-bit Unix that didn't work that way either, but while that memory is younger than I am, it's too old for me to recall more than just that ;-). ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP for adding an sq_index slot so that any object, a or b, can be used in X[a:b] notation
> Add a nb_index slot to PyNumberMethods, and a corresponding > __index__ special method. Objects could define a function to > place in the sq_index slot that returns an appropriate I presume 'sq_index' should also be 'nb_index' ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Pervasive socket failures on Windows
Tim Peters wrote: > I _suspect_ that rev 42253 introduced these problems. For example, that > added: > > + /* Guard against socket too large for select*/ > + if (s->sock_fd >= FD_SETSIZE) > + return SOCKET_INVALID; > > to _ssl.c, and added > > +/* Can we call select() with this socket without a buffer overrun? */ > +#define IS_SELECTABLE(s) ((s)->sock_fd < FD_SETSIZE) > > to socketmodule.c, but those appear to make no sense. FD_SETSIZE is > the maximum number of distinct fd's an fdset can hold, and the > numerical magnitude of any specific fd has nothing to do with that in > general (they may be related in fact on Unix systems that implement an > fdset as "a big bit vector" -- but Windows doesn't work that way, and > neither do all Unix systems, and nothing in socket specs requires an > implementation to work that way). Neal checked these changes in to address bug #876637 "Random stack corruption from socketmodule.c" But the Windows implementation of "select" is entirely different than other platforms, in so far as windows uses an internal counter to assign fds to an fd_set, so the fd number itself has no relevance to where they are placed in an fd_set. This stack corruption bug then does not exist on Windows, and so the code should not be used with Windows either. -- Scott Dial [EMAIL PROTECTED] [EMAIL PROTECTED] ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Let's just *keep* lambda
Guido van Rossum wrote: > To those people who believe that lambda is required in some situations > because it behaves differently with respect to the surrounding scope > than def: it doesn't, and it never did. This is (still!) a > surprisingly common myth. I have no idea where it comes from; does > this difference exist in some other language that has lambda as well > as some other function definition mechanism? Not that I know of. Maybe it's because these people first encountered the concept of a closure in when using lambda in Lisp or Scheme, and unconsciously assumed there was a dependency. > Parting shot: it appears that we're getting more and more > expressionized versions of statements: ... > Perhaps we could add a try/except/finally > expression, and allow assignments in expressions, and then we could > rid of statements altogether, turning Python into an expression > language. Change the use of parentheses a bit, and... voila, Lisp! :-) > Or we could go the other way and provide means of writing all expressions as statements. call: foo x lambda y,z: w =: +: y z print: "Result is" w -- Greg Ewing, Computer Science Dept, +--+ University of Canterbury, | Carpe post meridiam! | Christchurch, New Zealand | (I'm not a morning person.) | [EMAIL PROTECTED] +--+ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP for adding an sq_index slot so that any object, a or b, can be used in X[a:b] notation
Thomas Wouters wrote: > I have a slight reservation about the name. ... On the other > hand, there are other places (in C) that want an actual int, and they could > use __index__ too. Maybe __exactint__? -- Greg Ewing, Computer Science Dept, +--+ University of Canterbury, | Carpe post meridiam! | Christchurch, New Zealand | (I'm not a morning person.) | [EMAIL PROTECTED] +--+ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Let's just *keep* lambda
Valentino Volonghi aka Dialtone wrote: > when some_operation_that_results_in_a_deferred() -> result: > if result == 'Initial Value': > when work_on_result_and_return_a_deferred(result) -> inner_res: > print inner_res > else: > print "No work on result" > reactor.stop() Hmmm. This looks remarkably similar to something I got half way through dreaming up a while back, that I was going to call "Simple Continuations" (by analogy with "Simple Generators"). Maybe I should finish working out the details and write it up. On the other hand, it may turn out that it's subsumed by the new enhanced generators plus a trampoline. -- Greg Ewing, Computer Science Dept, +--+ University of Canterbury, | Carpe post meridiam! | Christchurch, New Zealand | (I'm not a morning person.) | [EMAIL PROTECTED] +--+ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] py3k and not equal; re names
On Thu, 2006-02-09 at 19:10 -0500, Jim Jewett wrote: > Logically, "<=" means the same as "< or =" > > <> does not mean the same as "< or >"; it might just mean that > they aren't comparable. Whether that is a strong enough reason > to remove it is another question. Visually, "==" looks very symmetrical and stands out nicely, while "!=" is asymmetric and jarring. "<>" has a visual symmetry that is a nice counterpart to "==". For me, that's enough of a reason to keep it. -Barry signature.asc Description: This is a digitally signed message part ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Let's just *keep* lambda
[EMAIL PROTECTED] wrote: > Lambdas are expressions. Statements can't be embedded in expressions. That > statements and expressions are different is a core feature of the language. > That is almost certainly not going to change. Although "print" may become a function in 3.0, so that this particular example would no longer be a problem. -- Greg Ewing, Computer Science Dept, +--+ University of Canterbury, | Carpe post meridiam! | Christchurch, New Zealand | (I'm not a morning person.) | [EMAIL PROTECTED] +--+ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Pervasive socket failures on Windows
Noticed that various socket tests are failing today, WinXP, Python trunk:
test_socket_ssl
Exception in thread Thread-27:
Traceback (most recent call last):
File "C:\Code\python\lib\threading.py", line 444, in __bootstrap
self.run()
File "C:\Code\python\lib\threading.py", line 424, in run
self.__target(*self.__args, **self.__kwargs)
File "C:\Code\python\lib\test\test_socket_ssl.py", line 50, in listener
s.accept()
File "C:\Code\python\lib\socket.py", line 169, in accept
sock, addr = self._sock.accept()
error: unable to select on socket
test test_socket_ssl crashed -- socket.error: (10061, 'Connection refused')
test test_urllibnet failed -- errors occurred; run in verbose mode for details
Running that in verbose mode shows 2 "ok" and 8 "ERROR". A typical ERROR:
ERROR: test_basic (test.test_urllibnet.urlopenNetworkTests)
--
Traceback (most recent call last):
File "C:\Code\python\lib\test\test_urllibnet.py", line 43, in test_basic
open_url = urllib.urlopen("http://www.python.org/";)
File "C:\Code\python\lib\urllib.py", line 82, in urlopen
return opener.open(url)
File "C:\Code\python\lib\urllib.py", line 190, in open
return getattr(self, name)(url)
File "C:\Code\python\lib\urllib.py", line 325, in open_http
h.endheaders()
File "C:\Code\python\lib\httplib.py", line 798, in endheaders
self._send_output()
File "C:\Code\python\lib\httplib.py", line 679, in _send_output
self.send(msg)
File "C:\Code\python\lib\httplib.py", line 658, in send
self.sock.sendall(str)
File "", line 1, in sendall
IOError: [Errno socket error] unable to select on socket
test_logging appears to consume 100% of a CPU now, and never finishes.
This may be an independent error.
test_asynchat
Exception in thread Thread-1:
Traceback (most recent call last):
File "C:\Code\python\lib\threading.py", line 444, in __bootstrap
self.run()
File "C:\Code\python\lib\test\test_asynchat.py", line 18, in run
conn, client = sock.accept()
File "C:\Code\python\lib\socket.py", line 169, in accept
sock, addr = self._sock.accept()
error: unable to select on socket
test_socket is a long-winded disaster.
test_socketserver
test test_socketserver crashed -- socket.error: (10061, 'Connection refused')
There are others, but tests that use sockets hang a lot now & it's
tedious to worm around that.
I _suspect_ that rev 42253 introduced these problems. For example, that added:
+ /* Guard against socket too large for select*/
+ if (s->sock_fd >= FD_SETSIZE)
+ return SOCKET_INVALID;
to _ssl.c, and added
+/* Can we call select() with this socket without a buffer overrun? */
+#define IS_SELECTABLE(s) ((s)->sock_fd < FD_SETSIZE)
to socketmodule.c, but those appear to make no sense. FD_SETSIZE is
the maximum number of distinct fd's an fdset can hold, and the
numerical magnitude of any specific fd has nothing to do with that in
general (they may be related in fact on Unix systems that implement an
fdset as "a big bit vector" -- but Windows doesn't work that way, and
neither do all Unix systems, and nothing in socket specs requires an
implementation to work that way).
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP for adding an sq_index slot so that any object, a or b, can be used in X[a:b] notation
> "Brett" == Brett Cannon <[EMAIL PROTECTED]> writes: Brett> On 2/9/06, Barry Warsaw <[EMAIL PROTECTED]> wrote: >> Maybe we can amend your rules to those people who both have >> commit privileges and have successfully submitted a PEP before. >> PEP virgins should go through the normal process. +1 Brett> Sounds reasonable to me. Then again I don't think I would Brett> ever attempt to get a PEP accepted without at least a Brett> single pass over by python-dev or c.l.py . But making it Brett> simpler definitely would be nice when you can already check Brett> in yourself. Besides Brett's point that in some sense most new authors *want* to go through the normal process, having the normal process means that there are a couple of people you can contact who are default mentor/editors, and TOOWDTI. -- School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp University of TsukubaTennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can "do" free software business; ask what your business can "do for" free software. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Let's just *keep* lambda
On Thu, 9 Feb 2006 16:27:35 -0800, Guido van Rossum <[EMAIL PROTECTED]> wrote: >[Bengt, on lambda :: suite] > >Since you probably won't stop until I give you an answer: I'm really >not interested in a syntactic solution that allows multi-line lambdas. >I don't think the complexity (in terms of users needing to learn them) >is worth it. So please stop (as several people have already asked >you). There's some text somewhere in the guidelines for python >developers on when to know when to give up. Read it. :-) > Thank you. I give up ;-) I will try to find it and read it. But no fair tempting the weak with """ It's a hard problem ... For example, consider this hypothetical example: ... """ ;-) Regards, Bengt Richter ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP for adding an sq_index slot so that any object, a or b, can be used in X[a:b] notation
On 2/9/06, Travis E. Oliphant <[EMAIL PROTECTED]> wrote: > Thomas Wouters wrote: > > I have a slight reservation about the name. On the one hand it's clear the > > canonical use will be for indexing sequences, and __index__ doesn't look > > enough like __int__ to get people confused on the difference. On the other > > hand, there are other places (in C) that want an actual int, and they could > > use __index__ too. Even more so if a PyArg_Parse* grew a format for 'the > > index-value for this object' ;) I think we should just change all the existing formats that require int or long to support nb_as_index. > There are other places in Python that check specifically for int objects > and long integer objects and fail with anything else. Perhaps all of > these should aslo call the __index__ slot. Right, absolutely. > But, then it *should* be renamed to i.e. "__true_int__". One such place > is in abstract.c sequence_repeat function. I don't like __true_int__ very much. Personally, I'm fine with calling it __index__ after the most common operation. (Well, I would be since I think I came up with the name in the first place. :-) Since naming is always so subjective *and* important, I'll wait a few days, but if nobody suggests something better then we should just go with __index__. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP for adding an sq_index slot so that any object, a or b, can be used in X[a:b] notation
Thomas Wouters wrote: > On Thu, Feb 09, 2006 at 02:32:47PM -0800, Brett Cannon wrote: > >>Looks good to me. Only change I might make is mention why __int__ >>doesn't work sooner (such as in the rationale). Otherwise +1 from me. > > > I have a slight reservation about the name. On the one hand it's clear the > canonical use will be for indexing sequences, and __index__ doesn't look > enough like __int__ to get people confused on the difference. On the other > hand, there are other places (in C) that want an actual int, and they could > use __index__ too. Even more so if a PyArg_Parse* grew a format for 'the > index-value for this object' ;) > There are other places in Python that check specifically for int objects and long integer objects and fail with anything else. Perhaps all of these should aslo call the __index__ slot. But, then it *should* be renamed to i.e. "__true_int__". One such place is in abstract.c sequence_repeat function. The patch I submitted, perhaps aggressivele, changed that function to call the nb_index slot as well instead of raising an error. Perhaps the slot should be called nb_true_int? -Travis > On the *other* one hand, I can't think of a good name... but on the other > other hand, it would be awkward to have to support an old name just because > the real use wasn't envisioned yet. > > One-time-machine-for-the-shortsighted-quadrumanus-please-ly y'r,s ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP for adding an sq_index slot so that any object, a or b, can be used in X[a:b] notation
On 2/9/06, Alex Martelli <[EMAIL PROTECTED]> wrote: > Shouldn't that new API function (whatever its name) also be somehow > exposed for easy access from Python code? I realize new builtins are > unpopular, so a builtin 'asindex' might not be appropriate, but > perhaps operator.asindex might be. My main point is that I don't think > we want every Python-coded sequence to have to call x.__index__() > instead. Very good point; this is why we have a PEP discussion phase. If it's x.__index__(), I think it ought to be operator.index(x). I'm not sure we need a builtin (also not sure we don't). I wonder if hasattr(x, "__index__") can be used as the litmus test for int-ness? (Then int and long should have one that returns self.) Travis, can you send me additional PEP updates as context or unified diffs vs. the PEP in SVN? (or against python.org/peps/pep-0357.txt if you don't want to download the entire PEP directory). -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP for adding an sq_index slot so that any object, a or b, can be used in X[a:b] notation
On 2/9/06, Travis E. Oliphant <[EMAIL PROTECTED]> wrote: ... > The patch adds a new API function int PyObject_AsIndex(obj). > > This was not specifically in the PEP but probably should be. The name > could also be PyNumber_AsIndex(obj) but I was following the nb_nonzero > slot example to help write the code. Shouldn't that new API function (whatever its name) also be somehow exposed for easy access from Python code? I realize new builtins are unpopular, so a builtin 'asindex' might not be appropriate, but perhaps operator.asindex might be. My main point is that I don't think we want every Python-coded sequence to have to call x.__index__() instead. Alex ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP for adding an sq_index slot so that any object, a or b, can be used in X[a:b] notation
Guido van Rossum wrote: > On 2/9/06, Travis Oliphant <[EMAIL PROTECTED]> wrote: > > > This is very close to acceptance. I think I'd like to see the patch > developed and submitted to SF (and assigned to me) prior to > acceptance. > > >>Copyright >> >> This document is placed in the public domain > > > If you agree with the above comments, please send me an updated > version of the PEP and I'll check it in over the old one, and approve > it. Then just use SF to submit the patch etc. > I uploaded a patch to SF against current SVN. The altered code compiles and the functionality works with classes defined in Python. I have yet to test against a C-type that defines the method. The patch adds a new API function int PyObject_AsIndex(obj). This was not specifically in the PEP but probably should be. The name could also be PyNumber_AsIndex(obj) but I was following the nb_nonzero slot example to help write the code. -Travis ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Let's just *keep* lambda
On Fri, 10 Feb 2006 01:23:25 +0100, Thomas Wouters <[EMAIL PROTECTED]> wrote: >On Fri, Feb 10, 2006 at 12:16:30AM +, Bengt Richter wrote: >> On Thu, 9 Feb 2006 10:33:10 -0800, Guido van Rossum <[EMAIL PROTECTED]> >> wrote: >> >Enough already. > [...some stuff snipped...] >> Yes, but if you're an optimist, those years mean we're closer to the magic >> moment ;-) [...some stuff snipped...] > >Please stop. Discuss it elsewhere. I suggest not CC'ing Guido in that >discussion, either, at least not if you want the proposals to still have a >chance. Also don't CC me, please, although it's not as hazardous as pissing >off Guido ;) Well, he presented a technical problem (indentation for lambda suites), and my main point was to address it with a suggestion he may not have seen (or why wouldn't he have mentioned it at least as a dumb failing attempt at solving the problem he was discussing?) IMHO it does solve the problem (modulo stupidities that I am prepared to have my nose rubbed in if I missed something) and was on topic. If a solution to a problem that Guido presents as an obstacle pisses him off, I'd be surprised, and disappointed. > >Make-the-hurting-stop-ly y'rs, I'm sorry you're hurting. That was not my intent ;-/ BTW, I never CC anyone unless they have asked me to. Unless gmane is doing it automatically, it shouldn't be happening. Regards, Bengt Richter ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Let's just *keep* lambda
Guido van Rossum wrote: > [Bengt, on lambda :: suite] > > Since you probably won't stop until I give you an answer: I'm really > not interested in a syntactic solution that allows multi-line lambdas. > I don't think the complexity (in terms of users needing to learn them) > is worth it. So please stop (as several people have already asked > you). There's some text somewhere in the guidelines for python > developers on when to know when to give up. Read it. :-) > It's not just a matter of knowing when to give up. It's also a matter of actually *giving up* once you know it's time. regards Steve -- Steve Holden +44 150 684 7255 +1 800 494 3119 Holden Web LLC www.holdenweb.com PyCon TX 2006 www.python.org/pycon/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Let's just *keep* lambda
[Bengt, on lambda :: suite] Since you probably won't stop until I give you an answer: I'm really not interested in a syntactic solution that allows multi-line lambdas. I don't think the complexity (in terms of users needing to learn them) is worth it. So please stop (as several people have already asked you). There's some text somewhere in the guidelines for python developers on when to know when to give up. Read it. :-) -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Let's just *keep* lambda
On Fri, Feb 10, 2006 at 12:16:30AM +, Bengt Richter wrote: > On Thu, 9 Feb 2006 10:33:10 -0800, Guido van Rossum <[EMAIL PROTECTED]> wrote: > >Enough already. > Yes, but if you're an optimist, those years mean we're closer to the magic > moment ;-) Please stop. Discuss it elsewhere. I suggest not CC'ing Guido in that discussion, either, at least not if you want the proposals to still have a chance. Also don't CC me, please, although it's not as hazardous as pissing off Guido ;) Make-the-hurting-stop-ly y'rs, -- Thomas Wouters <[EMAIL PROTECTED]> Hi! I'm a .signature virus! copy me into your .signature file to help me spread! ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Let's just *keep* lambda
On Thu, 9 Feb 2006 10:33:10 -0800, Guido van Rossum <[EMAIL PROTECTED]> wrote: >Enough already. > >As has clearly been proven, lambda is already perfect. > [...] > >To those people still complaining that lambda is crippled because it >doesn't do statements: First, remember that adding statement >capability wouldn't really add any power to the language; lambda is >purely syntactic sugar for an anonymous function definition (see above >myth debunking section). Second, years of attempts to overcome this >haven't come up with a usable syntax (and yes, curly braces have been Yes, but if you're an optimist, those years mean we're closer to the magic moment ;-) >proposed and rejected like everything else). It's a hard problem >because switching back to indentation-based parsing inside an >expression is problematic. For example, consider this hypothetical >example: > >a = foo(lambda x, y: > print x > print y) > >Should this be considered legal? Or should it be written as > >a = foo(lambda x, y: > print x > print y >) > Neither. If I may ;-) First, please keep the existing expression lambda exactly as is. Second, allow a new lambda variant to have a suite. But this necessitates: 1. same suite syntax as a function def suite, with explicit returns of values except if falling out with a default None. Just like a function def. 2. diffentiating the variant lambda, and providing for suite termination. 2a. differentiate by using doubled ':' a = foo(lambda x, y :: print x+y) 2b. the lambda:: variant _requires_ enclosing parens, and the top suite ends at the closing ')' A calling context may be sufficient parens, but sometimes, like tuple expressions, yet another pair of enclosing expression-parens may be needed. 2c. Single-line suites terminate on closing paren. Hence a = foo(lambda x, y :: print x; print y) # is ok 2d. For multiline suites, the first line after the one with the '::' defines the column of a single indent (COLSI), at the first non-whitepace character. Further indents work normally and terminate by dedent, or the closing ')' may be placed anywhere convenient to terminate the whole lambda suite. Any statement dedenting to left of the established single indent column (COLSI) before the closing ')' is a syntax error. I recognize that this requires keeping track of independent nested indentation contexts, but that part of tokenizing was always fun, I imagine. I'd volunteer to suffer appropriately if you like this (the lambda variant, I mean, not my suffering ;-) I think that's it, though I'm always prepared for a d'oh moment ;-) >??? (Indenting the prints so they start at a later column than the 'l' >of 'lambda', and adding an explicit dedent before the close >parenthesis.) Note that if the former were allowed, we'd have >additional ambiguity if foo() took two parameters, e.g.: > >a = foo(lambda x, y: > print x > print y, 42) > >-- is 42 the second argument to foo() or is it printed? To make 42 a second argument, it would be spelled a = foo((lambda x, y:: print x print y), 42) to have the "print y, 42" statement, you could move the closing paren like a = foo((lambda x, y:: print x print y, 42)) but that would have redundant parens with the same meaning as a = foo(lambda x, y:: print x print y, 42) Though perhaps requiring the redundant parens for _all_ (lambda::) expressions would make the grammar easier. > >I'd much rather avoid this snake's nest by giving the function a name >and using existing statement syntax, like this: This is Python! How can a snake's nest be bad? ;-) Seriously, with the above indentation rules it seems straightforward to me. I do think it would be hard to do something reasonable without an explicitly differentiated lambda variant though. > >def callback(x, y): >print x >print y >a = foo(callback) vs a = foo(lambda x, y :: print x; print y) > >This is unambiguous, easier to parse (for humans as well as for >computers), and doesn't actually span more text lines. Since this Well, it does use more lines when :: allows simple statement suites ;-) >typically happens in a local scope, the name 'callback' disappears as >soon as as the scope is exited. > >BTW I use the same approach regularly for breaking up long >expressions; for example instead of writing > >a = foo(some_call(another_call(some_long_argument, > another_argument), > and_more(1, 2, 3), >and_still_more()) > >I'll write > >x = another_call(some_long_argument, another_argument) >a = foo(some_call(x, and_more(1, 2, 3)), and_still_more()) > >and suddenly my code is more compact and yet easier to read! (In real >life, I'd use a more meaningful name than 'x', but since the example >is nonsense it's hard to come up with a meaningfu
[Python-Dev] py3k and not equal; re names
Smith asked: > I'm wondering if it's just "foolish consistency" (to quote a PEP 8) > that is calling for the dropping of <> in preference of only !=. Logically, "<=" means the same as "< or =" <> does not mean the same as "< or >"; it might just mean that they aren't comparable. Whether that is a strong enough reason to remove it is another question. -jJ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP for adding an sq_index slot so that any object, a or b, can be used in X[a:b] notation
On Thu, Feb 09, 2006 at 03:39:46PM -0800, Aahz wrote: > Can you provide a couple of examples where you think you'd want __index__ > functionality but the name would be inappropriate? Not really, or I wouldn't have had only a _slight_ reservation :) There are many functioncalls and methodcalls that only take integers, though, and they all currently use int() on their argument. file.read, socket.recv, signal.signal, str.zfill/center/ljust -- basically anything that uses the 'i' PyArg_Parse* format specifier, which is quite a lot. For a great many of them it will not make sense to pass objects that don't have an appropriate __int__, but who knows howmany really *mean* to ask for __index__ instead. I mostly voice the reservation to lure out people with actual reservations ;) -- Thomas Wouters <[EMAIL PROTECTED]> Hi! I'm a .signature virus! copy me into your .signature file to help me spread! ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP for adding an sq_index slot so that any object, a or b, can be used in X[a:b] notation
On Fri, Feb 10, 2006, Thomas Wouters wrote: > > I have a slight reservation about the name. On the one hand it's clear the > canonical use will be for indexing sequences, and __index__ doesn't look > enough like __int__ to get people confused on the difference. On the other > hand, there are other places (in C) that want an actual int, and they could > use __index__ too. Even more so if a PyArg_Parse* grew a format for 'the > index-value for this object' ;) > > On the *other* one hand, I can't think of a good name... but on the other > other hand, it would be awkward to have to support an old name just because > the real use wasn't envisioned yet. Can you provide a couple of examples where you think you'd want __index__ functionality but the name would be inappropriate? -- Aahz ([EMAIL PROTECTED]) <*> http://www.pythoncraft.com/ "19. A language that doesn't affect the way you think about programming, is not worth knowing." --Alan Perlis ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP for adding an sq_index slot so that any object, a or b, can be used in X[a:b] notation
On Thu, Feb 09, 2006 at 02:32:47PM -0800, Brett Cannon wrote: > Looks good to me. Only change I might make is mention why __int__ > doesn't work sooner (such as in the rationale). Otherwise +1 from me. I have a slight reservation about the name. On the one hand it's clear the canonical use will be for indexing sequences, and __index__ doesn't look enough like __int__ to get people confused on the difference. On the other hand, there are other places (in C) that want an actual int, and they could use __index__ too. Even more so if a PyArg_Parse* grew a format for 'the index-value for this object' ;) On the *other* one hand, I can't think of a good name... but on the other other hand, it would be awkward to have to support an old name just because the real use wasn't envisioned yet. One-time-machine-for-the-shortsighted-quadrumanus-please-ly y'r,s -- Thomas Wouters <[EMAIL PROTECTED]> Hi! I'm a .signature virus! copy me into your .signature file to help me spread! ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Linking with mscvrt
Neil Hodgson wrote: >I suppose the answer (hmm, am I allowed to anser my own rhtorical > questions?) is that it was originally developed on other operating > systems and the Windows port has never been as much of a focus for > most contributors. That's certainly the case. It is all Mark Hammond's doing still; not much has happened since the original Windows port. The other reason, of course, is that adding *specific* support for Windows will break support of other platforms. Microsoft had no problems breaking support of VB on Linux :-) Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Let's just *keep* lambda
On 2/9/06, Valentino Volonghi aka Dialtone <[EMAIL PROTECTED]> wrote: > Let's consider this piece of code (actual code that works today and uses > twisted for convenience): > > def do_stuff(result): > if result == 'Initial Value': > d2 = work_on_result_and_return_a_deferred(result) > d2.addCallback(println) > return d2 > return 'No work on result' > > def println(something): > print something > > d1 = some_operation_that_results_in_a_deferred() > d1.addCallback(do_stuff) > d1.addCallback(lambda _: reactor.stop()) > > reactor.run() PEP 342 provides a much better alternative: def do_stuff(): result = (yield some_operation()) something = (yield work_on_result(result)) print something reactor.stop() # Maybe unnecessary? reactor.run(do_stuff()) Apparantly it's already been applied to Python 2.5: http://www.python.org/dev/doc/devel/whatsnew/node4.html Now that may not be the exact syntax that Twisted provides, but the point is that the layout (and the top-to-bottom execution order) is possible. -- Adam Olsen, aka Rhamphoryncus ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Linking with mscvrt
Martin v. Löwis: > > Visual Basic never forced > > use of a particular compiler or runtime library for extensions so why > > should Python? > > Do you really not know? Because of API that happens to be defined > the way it is. It was rhetorical: Why should Python be inferior to VB? I suppose the answer (hmm, am I allowed to anser my own rhtorical questions?) is that it was originally developed on other operating systems and the Windows port has never been as much of a focus for most contributors. Neil ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP for adding an sq_index slot so that any object, a or b, can be used in X[a:b] notation
On 2/9/06, Adam Olsen <[EMAIL PROTECTED]> wrote: > On 2/9/06, Travis Oliphant <[EMAIL PROTECTED]> wrote: > > > > Guido seemed accepting to this idea about 9 months ago when I spoke to > > him. I finally got around to writing up the PEP. I'd really like to > > get this into Python 2.5 if possible. > > -1 > > I've detailed my reasons here: > http://mail.python.org/pipermail/python-dev/2006-January/059851.html I don't actually see anything relevant to this discussion in that post. > In short, there are purely math usages that want to convert to int > while raising exceptions from inexact results. The name __index__ > seems inappropriate for this, and I feel it would be cleaner to fix > float.__int__ to raise exceptions from inexact results (after a > suitable warning period and with a trunc() function added to math.) Maybe cleaner, but a thousand time harder given the status quo. Travis has a need for this *today* and __index__ can be added without any incompatibilities. I'm not even sure that it's worth changing __int__ for Python 3.0. Even if float.__int__ raised an exception if the float isn't exactly an integer, I still think it's wrong to use it here. Suppose I naively write some floating point code that usually (or with sufficiently lucky inputs) produces exact results, but which can produce inaccurate (or at least approximate) results in general. If I use such a result as an index, your proposal would allow that -- but the program would suddenly crash with an ImpreciseConversionError exception if the inputs produced an approximated result. I'd rather be made aware of this problem on the first run. Then I can decide whether to use int() or int(round()) or whatever other appropriate conversion. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP for adding an sq_index slot so that any object, a or b, can be used in X[a:b] notation
Guido van Rossum wrote: > On 2/9/06, Travis Oliphant <[EMAIL PROTECTED]> wrote: > > > BTW do you also still want to turn ZeroDivisionError into a warning > (that is changed into an error by default)? That idea shared a slide > and I believe it was discussed in the same meeting you & I and some > others had in San Mateo last summer. I think that idea has some support, but I haven't been thinking about it for awhile. > > > Shouldn't this slot be in the PyNumberMethods extension? It feels more > like a property of numbers than of a property of sequences. Also, the > slot name should then probably be nb_index. Yes, definitely!!! > > There's also an ambiguity when using simple indexing. When writing > x[i] where x is a sequence and i an object that isn't int or long but > implements __index__, I think i.__index__() should be used rather than > bailing out. I suspect that you didn't think of this because you've > already special-cased this in your code -- when a non-integer is > passed, the mapping API is used (mp_subscript). This is done to > suppose extended slicing. The built-in sequences (list, str, unicode, > tuple for sure, probably more) that implement mp_subscript should > probe for nb_index before giving up. The generic code in > PyObject_GetItem should also check for nb_index before giving up. > I agree. These should also be changed. I'll change the PEP, too. > > I think all sequence objects that implement mp_subscript should > probably be modified according to the lines I sketched above. > True. > > This is very close to acceptance. I think I'd like to see the patch > developed and submitted to SF (and assigned to me) prior to > acceptance. > O.K. I'll work on it. -Travis ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP for adding an sq_index slot so that any object, a or b, can be used in X[a:b] notation
Looks good to me. Only change I might make is mention why __int__ doesn't work sooner (such as in the rationale). Otherwise +1 from me. -Brett On 2/9/06, Travis E. Oliphant <[EMAIL PROTECTED]> wrote: > > Attached is an updated PEP for 357. I think the index concept is better > situated in the PyNumberMethods structure. That way an object doesn't > have to define the Sequence protocol just to be treated like an index. > > -Travis > > > PEP: 357357357 > Title: Allowing any object to be used for slicing > Version: Revision 1.2 > Last Modified: 02/09/2006 > Author: Travis Oliphant > Status: Draft > Type: Standards Track > Created: 09-Feb-2006 > Python-Version: 2.5 > > Abstract > >This PEP proposes adding an nb_as_index slot in PyNumberMethods and >an __index__ special method so that arbitrary objects can be used >in slice syntax. > > Rationale > >Currently integers and long integers play a special role in slice >notation in that they are the only objects allowed in slice >syntax. In other words, if X is an object implementing the sequence >protocol, then X[obj1:obj2] is only valid if obj1 and obj2 are both >integers or long integers. There is no way for obj1 and obj2 to >tell Python that they could be reasonably used as indexes into a >sequence. This is an unnecessary limitation. > >In NumPy, for example, there are 8 different integer scalars >corresponding to unsigned and signed integers of 8, 16, 32, and 64 >bits. These type-objects could reasonably be used as indexes into >a sequence if there were some way for their typeobjects to tell >Python what integer value to use. > > Proposal > >Add a nb_index slot to PyNumberMethods, and a corresponding >__index__ special method. Objects could define a function to >place in the sq_index slot that returns an appropriate >C-integer for use as ilow or ihigh in PySequence_GetSlice, >PySequence_SetSlice, and PySequence_DelSlice. > > Implementation Plan > >1) Add the slots > >2) Change the ISINT macro in ceval.c to ISINDEX and alter it to > accomodate objects with the index slot defined. > >3) Change the _PyEval_SliceIndex function to accomodate objects > with the index slot defined. > > Possible Concerns > >Speed: > >Implementation should not slow down Python because integers and long >integers used as indexes will complete in the same number of >instructions. The only change will be that what used to generate >an error will now be acceptable. > >Why not use nb_int which is already there? > >The nb_int, nb_oct, and nb_hex methods are used for coercion. >Floats have these methods defined and floats should not be used in >slice notation. > > Reference Implementation > >Available on PEP acceptance. > > Copyright > >This document is placed in the public domain > > > > > > ___ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/brett%40python.org > > > ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Linking with mscvrt
Neil Hodgson wrote: >>At first glance, this is a minor issue - passing FILE* pointers across >>DLL boundaries isn't something I'd normally expect people to do - but >>look further and you find you're opening a real can of worms. For >>example, Python has public APIs which take FILE* parameters. > > >So convert them to taking PyWrappedFile * parameters. Easy to say, hard to do. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Linking with mscvrt
Neil Hodgson wrote: >>If pythonxy.dll >>was statically linked, you would get all the CRT duplication >>already in extension modules. Given that there are APIs in Python >>where you have to do malloc/free across the python.dll >>boundary, you get memory leaks. > > >Memory allocations across DLL boundaries will have to use wrapper > functions. Sure, but that is a change to the API. Contributions are welcome, along with a plan how breakage of existing code can be minimized. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Linking with mscvrt
Neil Hodgson wrote: >COM was partly just a continuation of the practices used for > controls, VBXs and other forms of extension. Visual Basic never forced > use of a particular compiler or runtime library for extensions so why > should Python? Do you really not know? Because of API that happens to be defined the way it is. >>Alas, it is not a cross-platform API. Standard C is cross-platform, >>so Python uses it in its own APIs. > > >The old (pre-XPCOM) Netscape plugin interface was cross-platform > and worked with any compiler on Windows. Yes, and consequently, it avoids using standard C library types throughout. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP for adding an sq_index slot so that any object, a or b, can be used in X[a:b] notation
Attached is an updated PEP for 357. I think the index concept is better situated in the PyNumberMethods structure. That way an object doesn't have to define the Sequence protocol just to be treated like an index. -Travis PEP: 357357357 Title: Allowing any object to be used for slicing Version: Revision 1.2 Last Modified: 02/09/2006 Author: Travis Oliphant Status: Draft Type: Standards Track Created: 09-Feb-2006 Python-Version: 2.5 Abstract This PEP proposes adding an nb_as_index slot in PyNumberMethods and an __index__ special method so that arbitrary objects can be used in slice syntax. Rationale Currently integers and long integers play a special role in slice notation in that they are the only objects allowed in slice syntax. In other words, if X is an object implementing the sequence protocol, then X[obj1:obj2] is only valid if obj1 and obj2 are both integers or long integers. There is no way for obj1 and obj2 to tell Python that they could be reasonably used as indexes into a sequence. This is an unnecessary limitation. In NumPy, for example, there are 8 different integer scalars corresponding to unsigned and signed integers of 8, 16, 32, and 64 bits. These type-objects could reasonably be used as indexes into a sequence if there were some way for their typeobjects to tell Python what integer value to use. Proposal Add a nb_index slot to PyNumberMethods, and a corresponding __index__ special method. Objects could define a function to place in the sq_index slot that returns an appropriate C-integer for use as ilow or ihigh in PySequence_GetSlice, PySequence_SetSlice, and PySequence_DelSlice. Implementation Plan 1) Add the slots 2) Change the ISINT macro in ceval.c to ISINDEX and alter it to accomodate objects with the index slot defined. 3) Change the _PyEval_SliceIndex function to accomodate objects with the index slot defined. Possible Concerns Speed: Implementation should not slow down Python because integers and long integers used as indexes will complete in the same number of instructions. The only change will be that what used to generate an error will now be acceptable. Why not use nb_int which is already there? The nb_int, nb_oct, and nb_hex methods are used for coercion. Floats have these methods defined and floats should not be used in slice notation. Reference Implementation Available on PEP acceptance. Copyright This document is placed in the public domain ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP for adding an sq_index slot so that any object, a or b, can be used in X[a:b] notation
On 2/9/06, Barry Warsaw <[EMAIL PROTECTED]> wrote: > On Thu, 2006-02-09 at 11:30 -0800, Guido van Rossum wrote: > > > In the past, the protocol for aqcuiring a PEP number has been to ask > > the PEP coordinators (Barry Warsaw and David Goodger) to assign one. I > > believe that we could simplify this protocol to avoid necessary > > involvement of the PEP coordinators; all that is needed is someone > > with checkin privileges. I propose the following protocol: > > [omitted] > > In general, this is probably fine. Occasionally we reserve a PEP number > for something special, or for a pre-request, but I think both are pretty > rare. And because of svn and the commit messages we can at least catch > those fairly quickly and fix them. Maybe we can add known reserved > numbers to PEP 0 so they aren't taken accidentally. > > What I'm actually more concerned about is that we (really David) often > review PEPs and reject first submissions on several grounds. I must say > that David's done such a good job at keeping the quality of PEPs high > that I'm leery of interfering with that. OTOH, perhaps those with > commit privileges should be expected to produce high quality PEPs on the > first draft. > > Maybe we can amend your rules to those people who both have commit > privileges and have successfully submitted a PEP before. PEP virgins > should go through the normal process. > Sounds reasonable to me. Then again I don't think I would ever attempt to get a PEP accepted without at least a single pass over by python-dev or c.l.py . But making it simpler definitely would be nice when you can already check in yourself. -Brett ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Linking with mscvrt
Paul Moore: > This has all been thrashed out before, but the issue is passing > CRT-allocated objects across DLL boundaries. Yes, that was the first point I addressed through wrapping CRT objects. > At first glance, this is a minor issue - passing FILE* pointers across > DLL boundaries isn't something I'd normally expect people to do - but > look further and you find you're opening a real can of worms. For > example, Python has public APIs which take FILE* parameters. So convert them to taking PyWrappedFile * parameters. > Further, > memory allocation is CRT-managed - allocate memory with one CRT's > malloc, and dealloacte it elsewhere, and you have issues. So *any* > pointer could be CRT-managed, to some extent. Etc, etc... I thought PyMem_Malloc was the correct call to use for memory allocation now and avoided direct links to the CRT for memory management. Neil ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Linking with mscvrt
Martin v. Löwis: > Not sure whether this was a serious suggestion. Yes it is. > If pythonxy.dll > was statically linked, you would get all the CRT duplication > already in extension modules. Given that there are APIs in Python > where you have to do malloc/free across the python.dll > boundary, you get memory leaks. Memory allocations across DLL boundaries will have to use wrapper functions. Neil ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Linking with mscvrt
Martin v. Löwis: > COM really solves all problems people might have on Windows. COM was partly just a continuation of the practices used for controls, VBXs and other forms of extension. Visual Basic never forced use of a particular compiler or runtime library for extensions so why should Python? It was also easy to debug an extension DLL inside release-mode VB (I can't recall if debug versions of VB were ever readily available) which is something that is more difficult than it should be for Python. > Alas, it is not a cross-platform API. Standard C is cross-platform, > so Python uses it in its own APIs. The old (pre-XPCOM) Netscape plugin interface was cross-platform and worked with any compiler on Windows. Neil ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP for adding an sq_index slot so that any object, a or b, can be used in X[a:b] notation
Bengt Richter wrote: >> > > How about if SLICE byte code interpretation would try to call > obj.__int__() if passed a non-(int,long) obj ? Would that cover your use case? > I believe that this is pretty much what I'm proposing (except I'm not proposing to use the __int__ method because it is already used as coercion and doing this would allow floats to be used in slices which is a bad thing). The apply_slice and assign_slice functions in ceval.c are called for the SLICE and STORE_SLICE and DELETE_SLICE opcodes. > BTW the slice type happily accepts anything for start:stop:step I believe, > and something[slice(whatever)] will call something.__getitem__ with the slice > instance, though this is neither a fast nor nicely spelled way to customize. > Yes, the slice object itself takes whatever you want. However, Python special-cases what happens for X[a:b] *if* X as the sequence-protocol defined. This is the code-path I'm trying to enhance. -Travis ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP for adding an sq_index slot so that any object, a or b, can be used in X[a:b] notation
Bengt Richter wrote: >> > > How about if SLICE byte code interpretation would try to call > obj.__int__() if passed a non-(int,long) obj ? Would that cover your use case? > I believe that this is pretty much exactly what I'm proposing. The apply_slice and assign_slice functions in ceval.c are called for the SLICE and STORE_SLICE and DELETE_SLICE opcodes. > BTW the slice type happily accepts anything for start:stop:step I believe, > and something[slice(whatever)] will call something.__getitem__ with the slice > instance, though this is neither a fast nor nicely spelled way to customize. > Yes, the slice object itself takes whatever you want. However, Python special-cases what happens for X[a:b] *if* X as the sequence-protocol defined. This is the code-path I'm trying to enhance. -Travis ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Let's send lambda to the shearing shed (Re: Let's just *keep* lambda)
Bengt Richter wrote: >>1) Replace lambda args: value with >> >> args -> value >> >>or something equivalently concise, or >> > Yet another bike shed color chip: > > !(args:expr) # <==> lambda args:expr > and > !(args::suite) # <==> (lambda args::suite) Please drop it. Guido pronounced on it, it is _not_ going to change, and the introduction of new punctuation is clearly not improving anything. > (where the latter lambda form requires outer enclosing parens) But either > "::" form > allows full def suite, with indentation for multilines having left edge of > single indent > defined by first line following the "::"-containing line, and explicit > returns for values > required and top suite ending on closing outer paren) > > Probable uses for the "::" form would be for short inline suite definitions > !(x::print x) # <==> (lambda x::print x) & etc. similarly Use sys.stdout.write. > !(::global_counter+=1;return global_counter) > !(::raise StopIteration)() # more honest than iter([]).next() Use a function. > but the flexibility would be there for an in-context definition, e.g., > > sorted(seq, key= !(x:: > try: return abs(x) > except TypeError: return 0)) Bah! I can't parse this. In "!(x::" there's clearly too much noise. Georg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP for adding an sq_index slot so that any object, a or b, can be used in X[a:b] notation
On Thu, 2006-02-09 at 11:30 -0800, Guido van Rossum wrote: > In the past, the protocol for aqcuiring a PEP number has been to ask > the PEP coordinators (Barry Warsaw and David Goodger) to assign one. I > believe that we could simplify this protocol to avoid necessary > involvement of the PEP coordinators; all that is needed is someone > with checkin privileges. I propose the following protocol: [omitted] In general, this is probably fine. Occasionally we reserve a PEP number for something special, or for a pre-request, but I think both are pretty rare. And because of svn and the commit messages we can at least catch those fairly quickly and fix them. Maybe we can add known reserved numbers to PEP 0 so they aren't taken accidentally. What I'm actually more concerned about is that we (really David) often review PEPs and reject first submissions on several grounds. I must say that David's done such a good job at keeping the quality of PEPs high that I'm leery of interfering with that. OTOH, perhaps those with commit privileges should be expected to produce high quality PEPs on the first draft. Maybe we can amend your rules to those people who both have commit privileges and have successfully submitted a PEP before. PEP virgins should go through the normal process. -Barry signature.asc Description: This is a digitally signed message part ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP for adding an sq_index slot so that any object, a or b, can be used in X[a:b] notation
On Thu, 09 Feb 2006 01:00:22 -0700, Travis Oliphant <[EMAIL PROTECTED]> wrote: > >Abstract > > This PEP proposes adding an sq_index slot in PySequenceMethods and > an __index__ special method so that arbitrary objects can be used > in slice syntax. > >Rationale > > Currently integers and long integers play a special role in slice > notation in that they are the only objects allowed in slice > syntax. In other words, if X is an object implementing the sequence > protocol, then X[obj1:obj2] is only valid if obj1 and obj2 are both > integers or long integers. There is no way for obj1 and obj2 to > tell Python that they could be reasonably used as indexes into a > sequence. This is an unnecessary limitation. > > In NumPy, for example, there are 8 different integer scalars > corresponding to unsigned and signed integers of 8, 16, 32, and 64 > bits. These type-objects could reasonably be used as indexes into > a sequence if there were some way for their typeobjects to tell > Python what integer value to use. > >Proposal > > Add a sq_index slot to PySequenceMethods, and a corresponding > __index__ special method. Objects could define a function to > place in the sq_index slot that returns an C-integer for use in > PySequence_GetSlice, PySequence_SetSlice, and PySequence_DelSlice. > How about if SLICE byte code interpretation would try to call obj.__int__() if passed a non-(int,long) obj ? Would that cover your use case? BTW the slice type happily accepts anything for start:stop:step I believe, and something[slice(whatever)] will call something.__getitem__ with the slice instance, though this is neither a fast nor nicely spelled way to customize. Regards, Bengt Richter ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP for adding an sq_index slot so that any object, a or b, can be used in X[a:b] notation
On 2/9/06, Travis E. Oliphant <[EMAIL PROTECTED]> wrote: > I'm a little confused. Is your opposition solely due to the fact that > you think float's __int__ method ought to raise exceptions and the > apply_slice code should therefore use the __int__ slot? > > In theory I can understand this reasoning. In practice, however, the > __int__ slot has been used for "coercion" and changing the semantics of > int(3.2) at this stage seems like a recipe for lots of code breakage. I > don't think something like that is possible until Python 3k. > > If that is not your opposition, please be more clear. Regardless of how > it is done, it seems rather unPythonic to only allow 2 special types to > be used in apply_slice and assign_slice. Yes, that is the basis of my opposition, and I do understand it would take a long time to change __int__. What is the recommended practice for python? I can think of three distinct categories of behavior: - float to str. Some types converted to str might by lossy, but in general it's a very drastic conversion and unrelated to the others - float to Decimal. Raises an exception because it's usually lossy. - Decimal to int. Truncates, quite happily losing precision.. I guess my confusion revolves around float to Decimal. Is lossless conversion a good thing in python, or is prohibiting float to Decimal conversion just a fudge to prevent people from initializing a Decimal from a float when they really want a str? -- Adam Olsen, aka Rhamphoryncus ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Let's send lambda to the shearing shed (Re: Let's just *keep* lambda)
On Thu, 09 Feb 2006 16:41:10 +1300, Greg Ewing <[EMAIL PROTECTED]> wrote: >My thought on lambda at the moment is that it's too VERBOSE. > >If a syntax for anonymous functions is to pull its weight, >it needs to be *very* concise. The only time I ever consider >writing a function definition in-line is when the body is >extremely short, otherwise it's clearer to use a def instead. > >Given that, I do *not* have the space to waste with 6 or 7 >characters of geeky noise-word. OTOH, it does stand out as a flag to indicate what is being done. > >So my vote for Py3k is to either > >1) Replace lambda args: value with > > args -> value > >or something equivalently concise, or > Yet another bike shed color chip: !(args:expr) # <==> lambda args:expr and !(args::suite) # <==> (lambda args::suite) (where the latter lambda form requires outer enclosing parens) But either "::" form allows full def suite, with indentation for multilines having left edge of single indent defined by first line following the "::"-containing line, and explicit returns for values required and top suite ending on closing outer paren) Probable uses for the "::" form would be for short inline suite definitions !(x::print x) # <==> (lambda x::print x) & etc. similarly !(::global_counter+=1;return global_counter) !(::raise StopIteration)() # more honest than iter([]).next() but the flexibility would be there for an in-context definition, e.g., sorted(seq, key= !(x:: try: return abs(x) except TypeError: return 0)) and closures could be spelled !(c0,c1:!(x:c0+c1*x))(3,5) # single use with constants is silly spelling of !(x:3+5*x) Hm, are the latter two really better for eliminating "lambda"? Cf: sorted(seq, key=(lambda x:: try:return abs(x) except TypeError: return 0)) and (lambda c1,c2:lambda x:c0+c1*x)(3,5) # also silly with constants I'm not sure. I think I kind of like lambda args:expr and (lambda args::suite) but sometimes super-concise is nice ;-) >2) Remove lambda entirely. > -1 Regards, Bengt Richter ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP for adding an sq_index slot so that any object, a or b, can be used in X[a:b] notation
On 2/9/06, Guido van Rossum <[EMAIL PROTECTED]> wrote: > On 2/9/06, Brett Cannon <[EMAIL PROTECTED]> wrote: > > >2) Change the ISINT macro in ceval.c to accomodate objects with the > > >index slot defined. > > > > Maybe the macro should also be renamed? Not exactly testing if > > something is an int anymore if it checks for __index__. > > Have you looked at the code? ceval.c uses this macro only in the slice > processing code. I don't particularly care what it's called... > Yeah, I looked. I just don't want a misnamed macro to start being abused for some odd reason. Might as well rename it while we are thinking about it then let it have a bad name. -Brett ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] threadsafe patch for asynchat
On 2/7/06, Mark Edgington <[EMAIL PROTECTED]> wrote: > Ok, perhaps the notation could be improved, but the idea of the > semaphore in the patch is "Does it run inside of a multithreaded > environment, and could its push() functions be called from a different > thread?" The long-term fate of asyncore/asynchat aside, instead of wanting to patch asynchat, you should be able to subclass it easily to introduce the functionality you want. Given the disagreement over whether this is a good thing, I suggest that that's a much better way for you to solve your problem than to introduce yet another obscure confusing optional parameter. And you won't have to wait for Python 2.5. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Linking with mscvrt
On 2/9/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > COM really solves all problems people might have on Windows. Taken deliberately out of context, that sounds rather like a claim even Microsoft itself wouldn't make. :-) -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP for adding an sq_index slot so that any object, a or b, can be used in X[a:b] notation
On 2/9/06, Brett Cannon <[EMAIL PROTECTED]> wrote: > >2) Change the ISINT macro in ceval.c to accomodate objects with the > >index slot defined. > > Maybe the macro should also be renamed? Not exactly testing if > something is an int anymore if it checks for __index__. Have you looked at the code? ceval.c uses this macro only in the slice processing code. I don't particularly care what it's called... -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP for adding an sq_index slot so that any object, a or b, can be used in X[a:b] notation
On 2/9/06, Travis Oliphant <[EMAIL PROTECTED]> wrote: > > Guido seemed accepting to this idea about 9 months ago when I spoke to > him. I finally got around to writing up the PEP. I'd really like to > get this into Python 2.5 if possible. Excellent! I was just going over the 2.5 schedule with Neal Norwitz last night, and looking back in my slides for OSCON 2005 I noticed this idea, and was wondering if you still wanted it. I'm glad the answer is yes! BTW do you also still want to turn ZeroDivisionError into a warning (that is changed into an error by default)? That idea shared a slide and I believe it was discussed in the same meeting you & I and some others had in San Mateo last summer. I'll comment on the PEP in-line. I've assigned it number 357 and checked it in. In the past, the protocol for aqcuiring a PEP number has been to ask the PEP coordinators (Barry Warsaw and David Goodger) to assign one. I believe that we could simplify this protocol to avoid necessary involvement of the PEP coordinators; all that is needed is someone with checkin privileges. I propose the following protocol: 1. In the peps directory, do a svn sync. 2. Look at the files that are there and the contents of pep-.txt. This should provide you with the last PEP number in sequence, ignoring the out-of-sequence PEPs (666, 754, and 3000). The reason to look in PEP 0 is that it is conceivable that a PEP number has been reserved in the index but not yet committed, so you should use the largest number. 3. Add 1 to the last PEP number. This gives your new PEP number, . 4. Using svn add and svn commit, check in the file pep-.txt (use %04d to format the number); the contents can be a minimal summary or even just headers. If this succeeds, you have successfully assigned yourself PEP number . Exit. 5. If you get an error from svn about the commit, someone else was carrying out the same protocol at the same time, and they won the race. Start over from step 1. I suspect the PEP coordinators have informally been using this protocol amongst themseles -- and amongst the occasional developer who bypassed the "official" protocol, like I've done in the past and like Neal Norwitz did last night with the Python 2.5 release schedule, PEP 356. I'm simply extending the protocol to all developers with checkin permissions. For PEP authors without checkin permissions, nothing changes, except that optionally if they don't get a timely response from the PEP coordinators, they can ask someone else with checkin permissions. > PEP: ### > Title: Allowing any object to be used for slicing > Version: $Revision 1.1$ > Last Modified: $Date: 2006/02/09 $ > Author: Travis Oliphant > Status: Draft > Type: Standards Track > Created: 09-Feb-2006 > Python-Version: 2.5 > > Abstract > >This PEP proposes adding an sq_index slot in PySequenceMethods and >an __index__ special method so that arbitrary objects can be used >in slice syntax. > > Rationale > >Currently integers and long integers play a special role in slice >notation in that they are the only objects allowed in slice >syntax. In other words, if X is an object implementing the sequence >protocol, then X[obj1:obj2] is only valid if obj1 and obj2 are both >integers or long integers. There is no way for obj1 and obj2 to >tell Python that they could be reasonably used as indexes into a >sequence. This is an unnecessary limitation. > >In NumPy, for example, there are 8 different integer scalars >corresponding to unsigned and signed integers of 8, 16, 32, and 64 >bits. These type-objects could reasonably be used as indexes into >a sequence if there were some way for their typeobjects to tell >Python what integer value to use. > > Proposal > >Add a sq_index slot to PySequenceMethods, and a corresponding >__index__ special method. Objects could define a function to >place in the sq_index slot that returns an C-integer for use in >PySequence_GetSlice, PySequence_SetSlice, and PySequence_DelSlice. Shouldn't this slot be in the PyNumberMethods extension? It feels more like a property of numbers than of a property of sequences. Also, the slot name should then probably be nb_index. There's also an ambiguity when using simple indexing. When writing x[i] where x is a sequence and i an object that isn't int or long but implements __index__, I think i.__index__() should be used rather than bailing out. I suspect that you didn't think of this because you've already special-cased this in your code -- when a non-integer is passed, the mapping API is used (mp_subscript). This is done to suppose extended slicing. The built-in sequences (list, str, unicode, tuple for sure, probably more) that implement mp_subscript should probe for nb_index before giving up. The generic code in PyObject_GetItem should also check for nb_index before giving up. > Implementation Plan > >1) Add the slots > >2) Change the ISINT mac
Re: [Python-Dev] _length_cue()
On Thu, 9 Feb 2006 09:54:59 -0600, [EMAIL PROTECTED] wrote: > >>> Ditto. In addition, we already have queues. Do we really need to >>> use a homonym that means something entirely different? (Hint: >>> consider the added difficulty for non-native English speakers). > >Guido> Right. As a non-native speaker I can confirm that for English >Guido> learners, "cue" is a bit mysterious at first while "hint" is >Guido> obvious. > >Guido, you're hardly your typical non-native speaker. I think your English >may be better than mine. ;-) At any rate, I was thinking of some of the >posts I see on c.l.py where it requires a fair amount of detective work just >to figure out what the poster has written, what with all the incorrect >grammar and wild misspellings. For that sort of person I can believe that >"cue", "queue" and "kew" might mean exactly the same thing... > FWIW, I first thought "cue" might be a typo mutation of "clue" ;-) +1 on something with "hint". Regards, Bengt Richter ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Let's just *keep* lambda
On Thu, 09 Feb 2006 17:39:31 +0100, "\"Martin v. Löwis\"" <[EMAIL PROTECTED]> wrote: >It's not a specific example though: what precise library provides >the visit method? I'll provide my own usecase right now which is event driven programming of any kind (from GUI toolkits, to network frameworks/libraries). From my experience these are the kind of usecases that suffer most from having to define functions everytime and, worse, to define functions before their actual usage (which is responsible for part of the bad reputation that, for example, deferreds have). Let's consider this piece of code (actual code that works today and uses twisted for convenience): def do_stuff(result): if result == 'Initial Value': d2 = work_on_result_and_return_a_deferred(result) d2.addCallback(println) return d2 return 'No work on result' def println(something): print something d1 = some_operation_that_results_in_a_deferred() d1.addCallback(do_stuff) d1.addCallback(lambda _: reactor.stop()) reactor.run() As evident the execution order is almost upside-down and this is because I have to define a function before using it (instead of defining and using a function inline). However python cannot have a statement inside an expression as has already been said, thus I think some new syntax to support this could be helpful, for example: when some_operation_that_results_in_a_deferred() -> result: if result == 'Initial Value': when work_on_result_and_return_a_deferred(result) -> inner_res: print inner_res else: print "No work on result" reactor.stop() reactor.run() In this case the execution order is correct and indentation helps in identifying which pieces of the execution will be run at a later time (depending on the when block). This way of coding could be useful for many kind of event driven frameworks like GUI toolkits that could do the following: when button.clicked() -> event, other_args: when some_dialog() -> result: if result is not None: window.set_title(result) IMHO similar considerations are valid for other libraries/frameworks like asyncore. What would this require? Python should basically support a protocol for a deferred like object that could be used by a framework to support that syntax. Something like: callback(initial_value) add_callback(callback, *a, **kw) add_errback(callback, *a, **kw) (extra methods if needed) HTH -- Valentino Volonghi aka Dialtone Now Running MacOSX 10.4 Blog: http://vvolonghi.blogspot.com New Pet: http://www.stiq.it ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Let's just *keep* lambda
Enough already. As has clearly been proven, lambda is already perfect. *** To those folks attempting to propose alternate syntax (e.g. x -> y): this is the wrong thread for that (see subject). Seriously, I've seen lots of proposals that just change the syntax, and none of them are so much better than what we have. My comments on some recent proposals: - for Smells to much like a loop. And what if there are no formals? Also the generalization from a generator without the "in " part is wrong; "f(x) for x in S" binds x, while the proposed "f(x) for x" has x as a free variable. Very odd. - -> The -> symbol is much easier to miss. Also it means something completely different in other languages. And it has some problems with multiple formals: (x, y -> x+y) isn't very clear on the binding -- since '->' is an uncommon operator, there's no strong intuition about whether ',' or '->' binds stronger. (x, y) -> x+y would make more sense, but has an ambiguity as long as we want to allow argument tuples (which I've wanted to take out, but that is also getting a lot of opposition). - lambda(): This was my own minimal proposal. I withdraw it -- I agree with the criticism that it looks too much like a function call. - Use a different keyword instead of lambda What is that going to solve? - If there were other proposals, I missed them, or they were too far out to left field to be taken seriously. *** To those people complaining that Python's lambda misleads people into thinking that it is the same as Lisp's lambda: you better get used to it. Python has a long tradition of borrowing notations from other languages and changing the "deep" meaning -- for example, Python's assignment operator does something completely different from the same operator in C or C++. *** To those people who believe that lambda is required in some situations because it behaves differently with respect to the surrounding scope than def: it doesn't, and it never did. This is (still!) a surprisingly common myth. I have no idea where it comes from; does this difference exist in some other language that has lambda as well as some other function definition mechanism? *** To those people still complaining that lambda is crippled because it doesn't do statements: First, remember that adding statement capability wouldn't really add any power to the language; lambda is purely syntactic sugar for an anonymous function definition (see above myth debunking section). Second, years of attempts to overcome this haven't come up with a usable syntax (and yes, curly braces have been proposed and rejected like everything else). It's a hard problem because switching back to indentation-based parsing inside an expression is problematic. For example, consider this hypothetical example: a = foo(lambda x, y: print x print y) Should this be considered legal? Or should it be written as a = foo(lambda x, y: print x print y ) ??? (Indenting the prints so they start at a later column than the 'l' of 'lambda', and adding an explicit dedent before the close parenthesis.) Note that if the former were allowed, we'd have additional ambiguity if foo() took two parameters, e.g.: a = foo(lambda x, y: print x print y, 42) -- is 42 the second argument to foo() or is it printed? I'd much rather avoid this snake's nest by giving the function a name and using existing statement syntax, like this: def callback(x, y): print x print y a = foo(callback) This is unambiguous, easier to parse (for humans as well as for computers), and doesn't actually span more text lines. Since this typically happens in a local scope, the name 'callback' disappears as soon as as the scope is exited. BTW I use the same approach regularly for breaking up long expressions; for example instead of writing a = foo(some_call(another_call(some_long_argument, another_argument), and_more(1, 2, 3), and_still_more()) I'll write x = another_call(some_long_argument, another_argument) a = foo(some_call(x, and_more(1, 2, 3)), and_still_more()) and suddenly my code is more compact and yet easier to read! (In real life, I'd use a more meaningful name than 'x', but since the example is nonsense it's hard to come up with a meaningful name here. :-) Regarding the leakage of temporary variable names in this case: I don't care; this typically happens in a local scope where a compiler could easily enough figure out that a variable is no longer in use. And for clarity we use local variables in this way all the time anyway. *** Parting shot: it appears that we're getting more and more expressionized versions of statements: first list comprehensions, then generator expressions, most recently conditional expressions, in Python 3000 print() will become a function... Seen this way, lambda was just ahead of its time! Perhaps we could add a try/except/finally expression, and allow assignments in e
Re: [Python-Dev] Let's just *keep* lambda
On Thu, 09 Feb 2006 17:39:31 +0100, =?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=
<[EMAIL PROTECTED]> wrote:
>Jiwon Seo wrote:
>> Apparently, simplest example is,
>>
>> collection.visit(lambda x: print x)
>
>Ok. I remotely recall Guido suggesting that print should become
>a function.
>
Even so, that one is so trivial to define (other than the >> part):
>>> import sys
>>> def printfun(*args): sys.stdout.write(' '.join(map(str,args))+'\n')
...
>>> lamb = lambda x: printfun(x)
>>>
>>> lamb(123)
123
>>> printfun('How', 'about', 'that?')
How about that?
Also the quasi-C variant:
>>> def printf(fmt, *args): sys.stdout.write(fmt%args)
...
>>> (lambda x: printf('How about this: %s', x))('-- also a function\n(no \\n
>>> here ;-) ')
How about this: -- also a function
(no \n here ;-) >>>
>It's not a specific example though: what precise library provides
>the visit method?
>
>> which currently is not possible. Another example is,
>>
>> map(lambda x: if odd(x): return 1
>> else: return 0,
>> listOfNumbers)
>
>Hmm. What's wrong with
>
>map(odd, listOfNumbers)
>
>or, if you really need ints:
>
>map(lambda x:int(odd(x)), listOfNumbers)
>
>> Also, anything with exception handling code can't be without explicit
>> function definition.
>>
>> collection.visit(lambda x: try: foo(x); except SomeError: error("error
>> message"))
>
>That's not a specific example.
>
>>> (lambda : """
... I will say that the multi-line part
... of the argument against lambda suites
... is bogus, though ;-)
... """)(
... ).splitlines(
... )[-1].split()[1].capitalize(
... ).rstrip(',')+'! (though this is ridiculous ;-)'
'Bogus! (though this is ridiculous ;-)'
And, as you know, you can abuse the heck out of lambda (obviously this is
ridiculous**2 avoidance of external def)
>>> lamb = lambda x: eval(compile("""if 1:
... def f(x):
... try: return 'zero one two three'.split()[x]
... except Exception,e:return 'No name for %r --
%s:%s'%(x,e.__class__.__name__, e)
... """,'','exec')) or locals()['f'](x)
>>> lamb(2)
'two'
>>> lamb(0)
'zero'
>>> lamb(4)
'No name for 4 -- IndexError:list index out of range'
>>> lamb('x')
"No name for 'x' -- TypeError:list indices must be integers"
But would e.g. [1]
collection.visit(lambda x:: # double ':' to signify suite start
try: return 'zero one two three'.split()[x]
except Exception,e:return 'No name for %r --
%s:%s'%(x,e.__class__.__name__, e)
)
be so bad an "improvement"? Search your heart for the purest answer ;-)
(requires enclosing parens, and suite ends on closing ')' and if multiline,
the first line after the :: defines the indent-one left edge, and explicit
return of value required after ::).
[1] (using the function body above just as example, not saying it makes sense
for collection.visit)
Regards,
Bengt Richter
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] _length_cue()
> Hint seems like the standard terminology in the field. I don't think > it makes sense to invent our own terminology without some compelling > reason. Okay, I give, hint wins. Raymond ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP for adding an sq_index slot so that any object, a or b, can be used in X[a:b] notation
On 2/9/06, Travis Oliphant <[EMAIL PROTECTED]> wrote: > > Guido seemed accepting to this idea about 9 months ago when I spoke to > him. I finally got around to writing up the PEP. I'd really like to > get this into Python 2.5 if possible. > > -Travis > > > > > PEP: ### > Title: Allowing any object to be used for slicing Overally I am fine with the idea. Being used as an index is different than coercion into an int so adding this extra method seems reasonable. > Implementation Plan > >1) Add the slots > >2) Change the ISINT macro in ceval.c to accomodate objects with the >index slot defined. > Maybe the macro should also be renamed? Not exactly testing if something is an int anymore if it checks for __index__. >3) Change the _PyEval_SliceIndex function to accomodate objects >with the index slot defined. > -Brett ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Linking with mscvrt
Neil Hodgson wrote: >>But that won't help when you need to deal with third-party >>code that knows nothing about Python or its wrapped file >>objects, and calls the CRT (or one of the myriad extant >>CRTs, chosen at random:-) directly. > > >Can you explain exactly why there is a problem here? Its fairly > normal under Windows to build applications that provide a generic > plugin interface (think Netscape plugins or COM) that allow the > plugins to be built with any compiler and runtime. COM really solves all problems people might have on Windows. Alas, it is not a cross-platform API. Standard C is cross-platform, so Python uses it in its own APIs. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Let's just *keep* lambda
Jiwon Seo wrote:
> Apparently, simplest example is,
>
> collection.visit(lambda x: print x)
Ok. I remotely recall Guido suggesting that print should become
a function.
It's not a specific example though: what precise library provides
the visit method?
> which currently is not possible. Another example is,
>
> map(lambda x: if odd(x): return 1
> else: return 0,
> listOfNumbers)
Hmm. What's wrong with
map(odd, listOfNumbers)
or, if you really need ints:
map(lambda x:int(odd(x)), listOfNumbers)
> Also, anything with exception handling code can't be without explicit
> function definition.
>
> collection.visit(lambda x: try: foo(x); except SomeError: error("error
> message"))
That's not a specific example.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Linking with mscvrt
Neil Hodgson wrote: >The postgres example is strange to me as I'd never consider passing > a FILE* over a DLL boundary. Maybe this is a Unix/Windows cultural > thing due to such practices being more dangerous on Windows. In the specific example, Postgres has a PQprint function that can print a query result to a file; the file was sys.stdout. >>Also, there is still the redistribution issue: to redistribute >>msvcr71.dll, you need to own a MSVC license. People that want to >>use py2exe (or some such) are in trouble: they need to distribute >>both python25.dll, and msvcr71.dll. They are allowed to distribute >>the former, but (formally) not allowed to distribute the latter. > > >Link statically. Not sure whether this was a serious suggestion. If pythonxy.dll was statically linked, you would get all the CRT duplication already in extension modules. Given that there are APIs in Python where you have to do malloc/free across the python.dll boundary, you get memory leaks. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] _length_cue()
[Raymond Hettinger] > [Armin Rigo] > > BTW the reason I'm looking at this is that I'm considering adding > > another undocumented internal-use-only method, maybe __getitem_cue__(), > > that would try to guess what the nth item to be returned will be. This > > would allow the repr of some iterators to display more helpful > > information when playing around with them at the prompt, e.g.: > > > enumerate([3.1, 3.14, 3.141, 3.1415, 3.14159, 3.141596]) > > > > At one point, I explored and then abandoned this idea. For objects like > itertools.count(n), it worked fine -- the state was readily knowable and the > eval(repr(obj)) round-trip was possible. However, for tools like > enumerate(), it didn't make sense to have a preview that only applied in a > tiny handful of (mostly academic) cases and was not evaluable in any case. > That is my experience too. Even for knowable sequences people consume it in series and not just one element. My permutation module supports pulling out just the Nth canonical permutation. Lots of people have used the module and no one uses that feature. >>> import probstat >>> p = probstat.Permutation(range(4)) >>> p[0] [0, 1, 2, 3] >>> len(p) 24 >>> p[23] [3, 2, 1, 0] >>> -jackdied ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] _length_cue()
>> Ditto. In addition, we already have queues. Do we really need to >> use a homonym that means something entirely different? (Hint: >> consider the added difficulty for non-native English speakers). Guido> Right. As a non-native speaker I can confirm that for English Guido> learners, "cue" is a bit mysterious at first while "hint" is Guido> obvious. Guido, you're hardly your typical non-native speaker. I think your English may be better than mine. ;-) At any rate, I was thinking of some of the posts I see on c.l.py where it requires a fair amount of detective work just to figure out what the poster has written, what with all the incorrect grammar and wild misspellings. For that sort of person I can believe that "cue", "queue" and "kew" might mean exactly the same thing... Skip ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] _length_cue()
<[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] >>>> Might I suggest that at least you consider using "hint" instead of > "cue"? >... > >Greg> I agree that "hint" is a more precise name. > > Ditto. In addition, we already have queues. Do we really need to use a > homonym that means something entirely different? (Hint: consider the > added > difficulty for non-native English speakers). Even as a native English speaker, but without knowing the intended meaning, I did not understand or guess that length_cue meant length_hint. The primary meaning of cue is 'signal to begin some action', with 'hint, suggestion' being a secondary meaning. Even then, I would take it as referring to possible action rather than possible information. Cue is also short for queue, leading to cue stick (looks like a pigtail, long and tapering) and cue ball. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] _length_cue()
On 2/9/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > Greg> I agree that "hint" is a more precise name. > > Ditto. In addition, we already have queues. Do we really need to use a > homonym that means something entirely different? (Hint: consider the added > difficulty for non-native English speakers). Right. As a non-native speaker I can confirm that for English learners, "cue" is a bit mysterious at first while "hint" is obvious. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] _length_cue()
Hint seems like the standard terminology in the field. I don't think it makes sense to invent our own terminology without some compelling reason. Jeremy On 2/9/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > >> [Andrew Koenig] > >> > >>> Might I suggest that at least you consider using "hint" instead of > "cue"? > ... > > Greg> I agree that "hint" is a more precise name. > > Ditto. In addition, we already have queues. Do we really need to use a > homonym that means something entirely different? (Hint: consider the added > difficulty for non-native English speakers). > > Skip > ___ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/jeremy%40alum.mit.edu > ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP for adding an sq_index slot so that any object, a or b, can be used in X[a:b] notation
Adam Olsen wrote: > On 2/9/06, Travis Oliphant <[EMAIL PROTECTED]> wrote: > >>Guido seemed accepting to this idea about 9 months ago when I spoke to >>him. I finally got around to writing up the PEP. I'd really like to >>get this into Python 2.5 if possible. > > > -1 > > I've detailed my reasons here: > http://mail.python.org/pipermail/python-dev/2006-January/059851.html > > In short, there are purely math usages that want to convert to int > while raising exceptions from inexact results. The name __index__ > seems inappropriate for this, and I feel it would be cleaner to fix > float.__int__ to raise exceptions from inexact results (after a > suitable warning period and with a trunc() function added to math.) > I'm a little confused. Is your opposition solely due to the fact that you think float's __int__ method ought to raise exceptions and the apply_slice code should therefore use the __int__ slot? In theory I can understand this reasoning. In practice, however, the __int__ slot has been used for "coercion" and changing the semantics of int(3.2) at this stage seems like a recipe for lots of code breakage. I don't think something like that is possible until Python 3k. If that is not your opposition, please be more clear. Regardless of how it is done, it seems rather unPythonic to only allow 2 special types to be used in apply_slice and assign_slice. -Travis ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] threadsafe patch for asynchat
On Thu, 2006-02-09 at 13:12 +0100, Fredrik Lundh wrote: > Donovan Baarda wrote: > > >> Here I think you meant that medusa didn't handle computation in separate > >> threads instead. > > > > No, I pretty much meant what I said :-) > > > > Medusa didn't have any concept of a deferred, hence the idea of using > > one to collect the results of a long computation in another thread never > > occurred to them... remember the highly refactored OO beauty that is > > twisted was not even a twinkle in anyone's eye yet. > > > > In theory it would be just as easy to add twisted style deferToThread to > > Medusa, and IMHO it is a much better approach. Unfortunately at the time > > they went the other way and implemented multiple async-loops in separate > > threads. > > that doesn't mean that everyone using Medusa has done things in the wrong > way, of course ;-) Of course... and even Zope2 was not necessarily the "wrong way"... it was a perfectly valid design decision, given that it was all new ground at the time. And it works really well... there were many consequences of that design that probably contributed to the robustness of other Zope components like ZODB... -- Donovan Baarda <[EMAIL PROTECTED]> http://minkirri.apana.org.au/~abo/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Let's just *keep* lambda
>> Hmm. Can you give real-world examples (of existing code) where you >> needed this? Jiwon> Apparently, simplest example is, Jiwon> collection.visit(lambda x: print x) Sure, but has several other people have indicated, statements are not expressions in Python as they are in C (or in Lisp, which doesn't have statements). You can't do this either: if print x: print 5 because "print x" is a statement, while the if statement only accepts expressions. Lambdas are expressions. Statements can't be embedded in expressions. That statements and expressions are different is a core feature of the language. That is almost certainly not going to change. Skip ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] _length_cue()
>> [Andrew Koenig] >> >>> Might I suggest that at least you consider using "hint" instead of "cue"? ... Greg> I agree that "hint" is a more precise name. Ditto. In addition, we already have queues. Do we really need to use a homonym that means something entirely different? (Hint: consider the added difficulty for non-native English speakers). Skip ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] py3k and not equal; re names
On Thu, Feb 09, 2006 at 07:39:06AM -0500, Barry Warsaw wrote: > I've long advocated for keeping <> as I find it much more visually > distinctive when reading code. +1. And, two years ago, in his PyCon keynote, Guido forgot to say <> was going away, so I think Barry and I are completely in our rights to demand it'd stay. <0.5 wink>-ly y'rs, -- Thomas Wouters <[EMAIL PROTECTED]> Hi! I'm a .signature virus! copy me into your .signature file to help me spread! ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Linking with mscvrt
On 2/9/06, Neil Hodgson <[EMAIL PROTECTED]> wrote: > Greg Ewing: > > > But that won't help when you need to deal with third-party > > code that knows nothing about Python or its wrapped file > > objects, and calls the CRT (or one of the myriad extant > > CRTs, chosen at random:-) directly. > >Can you explain exactly why there is a problem here? Its fairly > normal under Windows to build applications that provide a generic > plugin interface (think Netscape plugins or COM) that allow the > plugins to be built with any compiler and runtime. This has all been thrashed out before, but the issue is passing CRT-allocated objects across DLL boundaries. If you open a file (getting a FILE*) in one DLL, using one CRT, and pass it to a second DLL, linked with a different CRT, the FILE* is not valid in that second CRT, and operations on it will fail. At first glance, this is a minor issue - passing FILE* pointers across DLL boundaries isn't something I'd normally expect people to do - but look further and you find you're opening a real can of worms. For example, Python has public APIs which take FILE* parameters. Further, memory allocation is CRT-managed - allocate memory with one CRT's malloc, and dealloacte it elsewhere, and you have issues. So *any* pointer could be CRT-managed, to some extent. Etc, etc... As a counterexample, however, I've heard reports that you can do a binary edit of the DLLs in the Subversion Python bindings, to change references to python23.dll to python24.dll, and everything still works. Make of that what you will... Also, there are intractable cases, like mod_python. Apache is still built with MSVC6, where Python is built with MSVC7.1. And so, mod_python, as a bridge, has *no* CRT that is "officially" OK. And yet, it works. I don't know how, maybe the mod_python developers could comment. Anyway, that's the brief summary. Paul. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] py3k and not equal; re names
On Feb 9, 2006, at 3:41 AM, Smith wrote: > I'm wondering if it's just "foolish consistency" (to quote a PEP 8) > that is calling for the dropping of <> in preference of only !=. > I've used the former since the beginning in everything from basic, > fortran, claris works, excel, gnumeric, and python. I tried to find > a rationale for the dropping--perhaps there is some other object > that will be represented (like an empty set). I'm sure there must > be some reason, but just want to put a vote in for keeping this > variety. I've long advocated for keeping <> as I find it much more visually distinctive when reading code. -Barry ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] threadsafe patch for asynchat
Donovan Baarda wrote: >> Here I think you meant that medusa didn't handle computation in separate >> threads instead. > > No, I pretty much meant what I said :-) > > Medusa didn't have any concept of a deferred, hence the idea of using > one to collect the results of a long computation in another thread never > occurred to them... remember the highly refactored OO beauty that is > twisted was not even a twinkle in anyone's eye yet. > > In theory it would be just as easy to add twisted style deferToThread to > Medusa, and IMHO it is a much better approach. Unfortunately at the time > they went the other way and implemented multiple async-loops in separate > threads. that doesn't mean that everyone using Medusa has done things in the wrong way, of course ;-) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] threadsafe patch for asynchat
On Wed, 2006-02-08 at 15:14 +0100, Valentino Volonghi aka Dialtone wrote: > On Wed, Feb 08, 2006 at 01:23:26PM +, Donovan Baarda wrote: > > I believe that Twisted does pretty much this with it's "deferred" stuff. > > It shoves slow stuff off for processing in a separate thread that > > re-syncs with the event loop when it's finished. > > Deferreds are only an elaborate way to deal with a bunch of callbacks. > It's Twisted itself that provides a way to run something in a separate thread > and then fire a deferred (from the main thread) when the child thread > finishes (reactor.callInThread() to call stuff in a different thread, [...] I know they are more than just a way to run slow stuff in threads, but once you have them, simple as they are, they present an obvious solution to all sorts of things, including long computations in a thread. Note that once zope2 took the approach it did, blocking the async-loop didn't hurt so bad, so lots of zope add-ons just did it gratuitously. In many cases the slow event handlers were slow because they are waiting on IO that could in theory be serviced as yet another event handler in the async-loop. However, the Zope/Medusa async framework had become so scary hardly anyone knew how to do this without breaking Zope itself. > > In the case of Zope/ZEO I'm not entirely sure but I think what happened > > was medusa (asyncore/asynchat based stuff Zope2 was based on) didn't > > have this deferred handler support. When they found some of the stuff > > Here I think you meant that medusa didn't handle computation in separate > threads instead. No, I pretty much meant what I said :-) Medusa didn't have any concept of a deferred, hence the idea of using one to collect the results of a long computation in another thread never occurred to them... remember the highly refactored OO beauty that is twisted was not even a twinkle in anyone's eye yet. In theory it would be just as easy to add twisted style deferToThread to Medusa, and IMHO it is a much better approach. Unfortunately at the time they went the other way and implemented multiple async-loops in separate threads. -- Donovan Baarda <[EMAIL PROTECTED]> http://minkirri.apana.org.au/~abo/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Let's just *keep* lambda
On 2/8/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Jiwon Seo wrote:
> > Then, is there any chance anonymous function - or closure - is
> > supported in python 3.0 ? Or at least have a discussion about it?
>
> That discussion appears to be closed (or, not really: everybody
> can discuss, but it likely won't change anything).
>
> > (IMHO, closure is very handy for function like map, sort etc. And
> > having to write a function for multiple statement is kind of good in
> > that function name explains what it does. However, I sometimes feel
> > that having no name at all is clearer. Also, having to define a
> > function when it'll be used only once seemed inappropriate sometimes.)
>
> Hmm. Can you give real-world examples (of existing code) where you
> needed this?
Apparently, simplest example is,
collection.visit(lambda x: print x)
which currently is not possible. Another example is,
map(lambda x: if odd(x): return 1
else: return 0,
listOfNumbers)
(however, with new if/else expression, that's not so much a problem any more.)
Also, anything with exception handling code can't be without explicit
function definition.
collection.visit(lambda x: try: foo(x); except SomeError: error("error
message"))
Anyway, I was just curious that if anyone is interested in having more
closure-like closure in python 3.0 - in any form, not necessary an
extension on lambda.
-Jiwon
>
> Regards,
> Martin
>
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP for adding an sq_index slot so that any object, a or b, can be used in X[a:b] notation
On 2/9/06, Travis Oliphant <[EMAIL PROTECTED]> wrote: > > Guido seemed accepting to this idea about 9 months ago when I spoke to > him. I finally got around to writing up the PEP. I'd really like to > get this into Python 2.5 if possible. -1 I've detailed my reasons here: http://mail.python.org/pipermail/python-dev/2006-January/059851.html In short, there are purely math usages that want to convert to int while raising exceptions from inexact results. The name __index__ seems inappropriate for this, and I feel it would be cleaner to fix float.__int__ to raise exceptions from inexact results (after a suitable warning period and with a trunc() function added to math.) -- Adam Olsen, aka Rhamphoryncus ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP for adding an sq_index slot so that any object, a or b, can be used in X[a:b] notation
Eric Nieuwland wrote:
> Travis Oliphant wrote:
>
>> PEP: ###
>> Title: Allowing any object to be used for slicing
>> [...]
>> Rationale
>>
>>Currently integers and long integers play a special role in slice
>>notation in that they are the only objects allowed in slice
>>syntax. In other words, if X is an object implementing the sequence
>>protocol, then X[obj1:obj2] is only valid if obj1 and obj2 are both
>>integers or long integers. There is no way for obj1 and obj2 to
>>tell Python that they could be reasonably used as indexes into a
>>sequence. This is an unnecessary limitation.
>> [...]
>
>
> I like the general idea from an academic point of view.
> Just one question: could you explain what I should expect from x[
> slicer('spam') : slicer('eggs') ] when slicer implements this protocol?
> Specifically, I'd like to known how you want to define the interval
> between two objects. Or is that for the sliced/indexed object to decide?
I'm not proposing to define that. The sequence protocol already
provides to the object only a c-integer (currently it's int but there's
a PEP to change it to ssize_t). Right now, only Python integer and
Python Long integers are allowed to be converted to this c-integer
passed to the object that is implementing the slicing protocol. It's up
to the object to deal with those integers as it sees fit.
One possible complaint that is easily addressed is that the slot should
really go into the PyNumber_Methods as nb_index because a number-like
object is what would typically be easily convertible to a c-integer.
Having to implement the sequence protocol (on the C-level) just to
enable sq_index seems in-appropriate.
So, I would change the PEP to implement nb_index instead...
-Travis
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP for adding an sq_index slot so that any object, a or b, can be used in X[a:b] notation
Eric Nieuwland wrote:
> Travis Oliphant wrote:
>> PEP: ###
>> Title: Allowing any object to be used for slicing
>> [...]
>> Rationale
>>
>>Currently integers and long integers play a special role in slice
>>notation in that they are the only objects allowed in slice
>>syntax. In other words, if X is an object implementing the sequence
>>protocol, then X[obj1:obj2] is only valid if obj1 and obj2 are both
>>integers or long integers. There is no way for obj1 and obj2 to
>>tell Python that they could be reasonably used as indexes into a
>>sequence. This is an unnecessary limitation.
>> [...]
>
> I like the general idea from an academic point of view.
> Just one question: could you explain what I should expect from x[
> slicer('spam') : slicer('eggs') ] when slicer implements this
> protocol?
> Specifically, I'd like to known how you want to define the interval
> between two objects. Or is that for the sliced/indexed object to
> decide?
As I understand it:
The sliced object will only see integers. The PEP wants to give arbitrary
objects the possibility of pretending to be an integer that can be used
for indexing.
Georg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP for adding an sq_index slot so that any object, a or b, can be used in X[a:b] notation
Travis Oliphant wrote:
> PEP: ###
> Title: Allowing any object to be used for slicing
> [...]
> Rationale
>
>Currently integers and long integers play a special role in slice
>notation in that they are the only objects allowed in slice
>syntax. In other words, if X is an object implementing the sequence
>protocol, then X[obj1:obj2] is only valid if obj1 and obj2 are both
>integers or long integers. There is no way for obj1 and obj2 to
>tell Python that they could be reasonably used as indexes into a
>sequence. This is an unnecessary limitation.
> [...]
I like the general idea from an academic point of view.
Just one question: could you explain what I should expect from x[
slicer('spam') : slicer('eggs') ] when slicer implements this
protocol?
Specifically, I'd like to known how you want to define the interval
between two objects. Or is that for the sliced/indexed object to
decide?
--eric
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] py3k and not equal; re names
I'm wondering if it's just "foolish consistency" (to quote a PEP 8) that is calling for the dropping of <> in preference of only !=. I've used the former since the beginning in everything from basic, fortran, claris works, excel, gnumeric, and python. I tried to find a rationale for the dropping--perhaps there is some other object that will be represented (like an empty set). I'm sure there must be some reason, but just want to put a vote in for keeping this variety. And another suggestion for py3k would be to increase the correspondence between string methods and re methods. e.g. since re.match and string.startswith are checking for the same thing, was there a reason to introduce the new names? The same question is asked for string.find and re.search. Instead of having to learn another set of method names to use re, it would be nice to have the only change be the pattern used for the method. Here is a side-by-side listing of methods in both modules that are candidates for consistency--hopefully not "foolish" ;-) stringre ---- find search startswithmatch split split replace sub NAsubn NAfindall NAfinditer /c ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] PEP for adding an sq_index slot so that any object, a or b, can be used in X[a:b] notation
Guido seemed accepting to this idea about 9 months ago when I spoke to him. I finally got around to writing up the PEP. I'd really like to get this into Python 2.5 if possible. -Travis PEP: ### Title: Allowing any object to be used for slicing Version: $Revision 1.1$ Last Modified: $Date: 2006/02/09 $ Author: Travis Oliphant Status: Draft Type: Standards Track Created: 09-Feb-2006 Python-Version: 2.5 Abstract This PEP proposes adding an sq_index slot in PySequenceMethods and an __index__ special method so that arbitrary objects can be used in slice syntax. Rationale Currently integers and long integers play a special role in slice notation in that they are the only objects allowed in slice syntax. In other words, if X is an object implementing the sequence protocol, then X[obj1:obj2] is only valid if obj1 and obj2 are both integers or long integers. There is no way for obj1 and obj2 to tell Python that they could be reasonably used as indexes into a sequence. This is an unnecessary limitation. In NumPy, for example, there are 8 different integer scalars corresponding to unsigned and signed integers of 8, 16, 32, and 64 bits. These type-objects could reasonably be used as indexes into a sequence if there were some way for their typeobjects to tell Python what integer value to use. Proposal Add a sq_index slot to PySequenceMethods, and a corresponding __index__ special method. Objects could define a function to place in the sq_index slot that returns an C-integer for use in PySequence_GetSlice, PySequence_SetSlice, and PySequence_DelSlice. Implementation Plan 1) Add the slots 2) Change the ISINT macro in ceval.c to accomodate objects with the index slot defined. 3) Change the _PyEval_SliceIndex function to accomodate objects with the index slot defined. Possible Concerns Speed: Implementation should not slow down Python because integers and long integers used as indexes will complete in the same number of instructions. The only change will be that what used to generate an error will now be acceptable. Why not use nb_int which is already there? The nb_int, nb_oct, and nb_hex methods are used for coercion. Floats have these methods defined and floats should not be used in slice notation. Reference Implementation Available on PEP acceptance. Copyright This document is placed in the public domain ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
