Re: [Python-Dev] More tracker demos online
Martin v. Löwis [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Currently, we have two running tracker demos online: Roundup: http://efod.se/python-tracker/ Jira: http://jira.python.atlassian.com/secure/Dashboard.jspa Is anyone looking at the Google Code Hosting tracker, just for fun? =) (code.google.com/hosting, although performance seems to be an issue for now)--david ___ 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 340 - possible new name for block-statement
On 4/28/05, Guido van Rossum [EMAIL PROTECTED] wrote:
How about, instead of trying to emphasize how different a
block-statement is from a for-loop, we emphasize their similarity?
A regular old loop over a sequence or iterable is written as:
for VAR in EXPR:
BLOCK
A variation on this with somewhat different semantics swaps the keywords:
in EXPR for VAR:
BLOCK
If you don't need the variable, you can leave the for VAR part out:
in EXPR:
BLOCK
Too cute? :-)
If you want to truly confuse the Ruby folks, you could go for something like:
{ EXPR } VAR:
BLOCK
wink/
___
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 340 - possible new name for block-statement
On 4/29/05, Guido van Rossum [EMAIL PROTECTED] wrote: [Phillip J. Eby] Although I'd personally prefer a no-keyword approach: synchronized(self): with_file(foo) as f: # etc. I'd like that too, but it was shot down at least once. Maybe we can resurrect it? opening(foo) as f: # etc. is just a beauty! I agree, but does this then work: x = opening(foo) ...stuff... x as f: # etc ? And if not, why not? And if yes, what happens if stuff raises an exception? ___ 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 340 - possible new name for block-statement
I agree, but does this then work: x = opening(foo) ...stuff... x as f: # etc ? And if not, why not? And if yes, what happens if stuff raises an exception? Forget it -- the above is probably addressed by the PEP and doesn't really depend on whether there's a kw or not. ___ 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] Re: anonymous blocks
On 4/27/05, Guido van Rossum [EMAIL PROTECTED] wrote: As long as I am BDFL Python is unlikely to get continuations -- my head explodes each time someone tries to explain them to me. You just need a safety valve installed. It's outpatient surgery, don't worry. --david ___ 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] sum()
You guys have way too much time on your hands and neurons devoted to this stuff. I'm glad that means that I can spend the afternoon playing w/ my kids and searching python-dev when I need to add numbers =). ___ 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] UserString
On Tue, 22 Feb 2005 08:16:52 -0800, Guido van Rossum [EMAIL PROTECTED] wrote: Really? I do this kind of thing all the time: import os import errno try: os.makedirs(dn) except OSError, e: if e.errno errno.EEXIST: raise You have a lot more faith in the errno module than I do. Are you sure the same error codes work on all platforms where Python works? It's also not exactly readable (except for old Unix hacks). Agreed. In general, I often wish in production code (especially in not-100% Python systems) that Python did a better job of at the very least documenting what kinds of exceptions were raised by what function calls. Otherwise you end up with what are effectively blanket try/except statements way too often for my taste. --da ___ 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] Fixing _PyEval_SliceIndex so that integer-like objects can be used
On Fri, 18 Feb 2005 13:28:34 -0800, Guido van Rossum [EMAIL PROTECTED] wrote: Would it be possible to change _PyEval_SliceIndex in ceval.c so that rather than throwing an error if the indexing object is not an integer, the code first checks to see if the object has a tp_as_number-nb_int method and calls it instead. I don't think this is the right solution; since float has that method, it would allow floats to be used as slice indices, but that's not supposed to work (to protect yourself against irreproducible results due to rounding errors). I wonder if floats are the special case here, not integer like objects. I've never been particularly happy about the confusion between the two roles of int() and it's C equivalents, i.e. casting and conversion. ___ 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] Re: [Python-checkins] python/dist/src/Lib xmlrpclib.py, 1.38, 1.39
On Thu, 10 Feb 2005 15:32:14 -0500, Fred L. Drake, Jr. [EMAIL PROTECTED] wrote: On Thursday 10 February 2005 14:44, Tim Peters wrote: Well, then since that isn't ISO 8601 format, it would be nice to have a comment explaining why it's claiming to be anyway 0.5 wink. I've posted a note on the XML-RPC list about this. There doesn't seem to be anything that describes the range of what's accepted and produced by the various XML-RPC libraries, but I've not looked hard for it. Is there any surprise here? =) ___ 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] Clarification sought about including a multidimensional array object into Python core
On Wed, 9 Feb 2005 14:45:18 -0800, Guido van Rossum [EMAIL PROTECTED] wrote: The intended user community must accept the code as best-of-breed. It seems that the Num* community has some work to do in this respect. I've not followed the num* discussion in quite a while, but my impression back then was that there wasn't one such community. Instead, the technical differences in the approaches required in specific fields, regarding things like the relative importance of memory profiles, speed, error handling, willingness to require modern C++ compilers, etc. made practical compromises quite tricky. I would love to be proven wrong. --david ___ 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: [Numpy-discussion] Re: [Python-Dev] Re: Numeric life as I see it
On Wed, 09 Feb 2005 22:02:11 -0700, Travis Oliphant [EMAIL PROTECTED] wrote: GvR: And why would a Matrix need to inherit from a C-array? Wouldn't it make more sense from an OO POV for the Matrix to *have* a C-array without *being* one? Travis: The only reason I'm thinking of here is to have it inherit from the C-array many of the default methods without having to implement them all itself. I think Paul is saying that this never works with C-types like arrays, and I guess from your comments you agree with him. The only real reason for wanting to construct a separate Matrix object is the need to overload the * operation to do matrix multiplication instead of element-by-element multiplication. This is dredging stuff up from years (and layers and layers of new memories =), but I think that what Paul was referring to was in fact independent of implementation language. The basic problem, IIRC, had to do with the classic (it turns out) problem of confusing the need for reuse of implementation bits with interface inheritance. We always felt that things that people felt were array-like (Matrices, missing value arrays, etc.) _should_ inherit from array, and that (much like you're saying), it would save work. In practice, however, there were a few problems (again, from lousy memory), all boiling down to the fact that the array object implemenation implies interfaces that weren't actually applicable to the others. The biggest problems had to do with the fact that when you do subclassing, you end up in a nasty combinatorial problem when you wanted to figure out what operand1 operator operand2 means, if operand1 is a derivative and operand2 is a different derivative. In other words, if you multiply a matrix with a missingvalues array, what should you do? Having a common inheritance means you need to _stop_ default behaviors from happening, to avoid meaningless results. It gets worse with function calls that take array-like objects as arguments. A lot of this may be resolvable with the recent notions of adaptation and more formalized interfaces. In the meantime, I would, like Paul, recommend that you separate the interface-bound type aspects (which is what Python classes are in fact!) from the implementation sharing. This may be obvious to everyone, and if so, sorry. --david ___ 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
