Re: [Python-Dev] More tracker demos online

[David Ascher]

> ""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 246, redux

[David Ascher]

Alex Martelli wrote:
On 2005 Jan 10, at 23:15, Thomas Heller wrote:
Alex Martelli <[EMAIL PROTECTED]> writes:
PEP: 246
Title: Object Adaptation

Minor nit (or not?): You could provide a pointer to the Liskov
substitution principle, for those reader that aren't too familiar with
that term.

Excellent idea, thanks.
Terminology point: I know that LiskovViolation is technically correct, 
but I'd really prefer it if exception names (which are sometimes all 
users get to see) were more informative for people w/o deep technical 
background.  Would that be possible?

--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

[Python-Dev] Re: PEP 246: LiskovViolation as a name

[David Ascher]

Michael Chermside wrote:
David Ascher writes:
Terminology point: I know that LiskovViolation is technically correct,
but I'd really prefer it if exception names (which are sometimes all
users get to see) were more informative for people w/o deep technical
background.  Would that be possible?

I don't see how. Googling on Liskov immediately brings up clear
and understandable descriptions of the principle that's being violated.
I can't imagine summarizing the issue more concisely than that! What
would you suggest? Including better explanations in the documentation
is a must, but "LiskovViolation" in the exception name seems unbeatably
clear and concise.
Clearly, I disagree.
My point is that it'd be nice if we could come up with an exception name 
which could be grokkable without requiring 1) Google, 2) relatively 
high-level understanding of type theory.

Googling on Liskov brings up things like:
http://c2.com/cgi/wiki?LiskovSubstitutionPrinciple
"""What is wanted here is something like the following substitution 
property: If for each object o1 of type S there is an object o2 of type 
T such that for all programs P defined in terms of T, the behavior of P 
is unchanged when o1 is substituted for o2 then S is a subtype of T." - 
BarbaraLiskov, Data Abstraction and Hierarchy, SIGPLAN Notices, 23,5 
(May, 1988)."""

If you think that that is clear and understandable to the majority of 
the Python community, you clearly have a different perspective on that 
community.  I have (almost) no doubt that all Python-dev'ers understand 
it, but maybe we should ask someone like Anna Ravenscroft or Mark Lutz 
if they thinks it'd be appropriate from a novice user's POV.  I'm quite 
sure that the experts could understand a more pedestrian name, and quite 
sure that the reverse isn't true.

I also think that the term "violation" isn't necessarily the best word 
to add to the Python namespace, when error or exception would do just fine.

In addition, to say that it's unbeatably clear without a discussion of 
alternatives (or if I've missed it, please let me know) seems weird.

The point is broader, though -- when I get my turn in the time machine, 
I'll lobby for replacing NameError with UndefinedVariable or something 
similar (or more useful still).  The former is confusing to novices, and 
while it can be learned, that's yet another bit of learning which is, 
IMO, unnecessary, even though it may be technically more correct.

--david ascher
___
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: PEP 246: LiskovViolation as a name

[David Ascher]

Guido van Rossum wrote:
My point is that it'd be nice if we could come up with an exception name
which could be grokkable without requiring 1) Google, 2) relatively
high-level understanding of type theory.

How about SubstitutabilityError?
That would be far, far better, yes.
We did that for UnboundLocalError, which subclasses NameError. Perhaps
we can rename NameError to UnboundVariableError (and add NameError as
an alias for b/w compat).
Sure, although (and here I'm pushing it, I know, and I should have 
argued it way back then), the notion of 'unbound' is possibly too 
low-level still.  'Unknown' would probably carry much more meaning to 
those people who most need it.

But yes, you're catching my drift.
--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] Re: PEP 246: LiskovViolation as a name

[David Ascher]

Guido van Rossum wrote:
The point is broader, though -- when I get my turn in the time machine,
I'll lobby for replacing NameError with UndefinedVariable or something
Strange, my blog reading just hit upon
http://blogs.zdnet.com/open-source/index.php?p=93
...
"Perhaps as open source developers are making their resolutions for 
2005, they could add human-readable error codes to their list?
"

:-)
--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 246, redux

[David Ascher]

Alex Martelli wrote:
Yes, there is (lato sensu) "non-determinism" involved, just like in, say:
for k in d:
print k
Wow, it took more than the average amount of googling to figure out that 
lato sensu means "broadly speaking", and occurs as "sensu lato" with a 
1:2 ratio.

I learned something today! ;-)
--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

[Python-Dev] Re: [PyCON-Organizers] PyCon: The Spam Continues ;-)

[David Ascher]

Steve Holden wrote:
Dear python-dev:
The current (as of even date) summary of my recent contributions to 
Python -dev appears to be spam about PyCon.

Not being one to break habits, even not those of a lifetime sometimes, I 
spam you yet again to show you what a beautiful summary ActiveState have 
provided (I don't know whether this URL is cacheable or not):

 
Yup, we try to make all our URLs portable and persistent.
If I remember Trent Lott (?) 
Nah, that's a US politician.  T'was Trent Mick.
described at an IPC the SQL Server database 
that drives this system, and it was a great example of open source 
technology driving a proprietary (but I expect (?) relatively portable) 
repository.
Modulo some SQLServer features we're using.
Since I have your attention (and if I haven't then it really doesn't 
matter what I write hereafter, goodbye ...) I will also point out that 
the current top hit on Google for

"Microsoft to Provide PyCon Opening Keynote"
What a bizarre search.
(note that some of your To's and Cc's were pretty strange...
--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

[Python-Dev] Re: [PyCON-Organizers] PyCon: The Spam Continues ;-)

[David Ascher]

Steve Holden wrote:
Modulo some SQLServer features we're using.
Well free-text indexing would be my first guess. Anything else of 
interest? MySQL's free text indexing really sucks compared with SQL 
Server's, which to my mind is a good justification for the Microsoft 
product.
Freetext search is one of them, but there may be others (I think there 
are some stored procedure in some MS language).  I'm hardly a SQL 
expert, or an expert on our ASPN infrastructure.

--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] Clarification sought about including a multidimensional array object into Python core

[David Ascher]

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

[David Ascher]

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

Re: [Python-Dev] Re: [Python-checkins] python/dist/src/Lib xmlrpclib.py, 1.38, 1.39

[David Ascher]

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

[Python-Dev] Jim Roskind

[David Ascher]

I contacted Jim Roskind re: the profiler code.  

i said:

 I'm a strong supporter of Opensource software, but I'm probably not
going to be able to help you very much.  I could be much more helpful
with understanding the code or its use ;-).

To summarize what I'll say: I don't own the rights to this stuff.  ...
but I don't believe there are any patents that I was ever involved
with that might encumber this work.

I would note that my profiler code is really very rarely used in
commercial products, and it is much more typically used by developers
(I guess a developer toolkit, if sold, would use it).  I'm pretty
delighted that the code has found so much use by developers over the
years.  As I noted in the intro to the documentation, I had only been
coding in Python for 3 weeks when I wrote it.  On the positive side,
it exposed many weaknesses in many developer's code (including our own
at InfoSeek), as well as in core Python code (subtle bugs in the
interpreter) that surely helped everyone.  Even though I was a newbie,
It was VERY carefully crafted,, and I'd expect that it would take a
fair amount of effort to reproduce it (and that is is probably why it
has not been changed much... or at least no one told me when they
changed/fixed it ;-) ).

With regard to why I probably can't help much.

First off, InfoSeek (holder of the copyright) was bought by Disney,
and I don't know what if anything has eventually become of the
tradename.  There is a chance that Disney owns the rights... and I
have no idea who to ask there :-/.

Second, I took a look at the Copyright, and it sure seems pretty
permissive.  I'm amazed if folks want something more permissive.  
This is what I found on the web for it:

Copyright © 1994, by InfoSeek Corporation, all rights reserved.

Written by James Roskind.10.1

Permission to use, copy, modify, and distribute this Python
software and its associated documentation for any purpose (subject to
the restriction in the following sentence) without fee is hereby
granted, provided that the above copyright notice appears in all
copies, and that both that copyright notice and this permission notice
appear in supporting documentation, and that the name of InfoSeek not
be used in advertising or publicity pertaining to distribution of the
software without specific, written prior permission. This permission
is explicitly restricted to the copying and modification of the
software to remain in Python, compiled Python, or other languages
(such as C) wherein the modified or derived code is exclusively
imported into a Python module.

INFOSEEK CORPORATION DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS
SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND
FITNESS. IN NO EVENT SHALL INFOSEEK CORPORATION BE LIABLE FOR ANY
SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER
RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF
CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN
CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.

As I recall, I probably personally created the terms of the above
license.  I used a similar license on my C/C++ grammar, and Infoseek
just added a bunch of wording to be sure that they were not at risk,
and that their name would not be used in vain (or in advertising
material).  I think they were also interested in limiting its use to
Python but I don't think that is a concern that would bother you.

I read the link you directed me to, and its primary focus seemed ot be
on patents for related or included technology.

I don't believe that infoseek applied for or got any patents in this
area (and certainly if they did so without my name, it would probably
invalidate the patent), and I'm sure I didn't get any patents in this
area at Netscape/AOL.  In fact I don't think I got any patents back in
1994 or 1995.  My only prior patent dated back to about 1983 (a
hardware patent) that has since expired.

I have some patents since (roughly) 1995, and even though I don't
think any of them relate to profiling (though some did relate to
languages, or more specifically, security in languages), I wouldn't
want to mess with assigning rights to any of those patents, as they
belong to AOL/Netscape.  Here again, to my knowledge, none of my
patents relate in any way to this area (profiling).  Sadly, if they
did, I would not have the right to assign them.

I'm sure you're just doing your job, and following through by dotting
all the I's and crossing all T's.  My suggestion is to (as you said)
work around the issue.  You could always re-write the code from
scratch, as the approaches are not rocket science and are pretty
thoroughly explained.  I wouldn't suggest it unless you are desperate.
 If I were you, I'd wait for a license problem to emerge (which I
don't believe will ever happen).

Hope th

Re: [Python-Dev] license issues with profiler.py and md5.h/md5c.c

[David Ascher]

On Tue, 8 Feb 2005 15:52:29 -0500, Jeremy Hylton <[EMAIL PROTECTED]> wrote:
> Maybe some ambitious PSF activitst could contact Roskind and Steve
> Kirsch and see if they know who at Disney to talk to...  Or maybe the
> Disney guys who were at PyCon last year could help.

I contacted Jim.  His response follows:

---
I'm a strong supporter of Opensource software, but I'm probably not
going to be able to help you very much.  I could be much more helpful
with understanding the code or its use ;-).

To summarize what I'll say: I don't own the rights to this stuff.  ...
but I don't believe there are any patents that I was ever involved
with that might encumber this work.

I would note that my profiler code is really very rarely used in
commercial products, and it is much more typically used by developers
(I guess a developer toolkit, if sold, would use it).  I'm pretty
delighted that the code has found so much use by developers over the
years.  As I noted in the intro to the documentation, I had only been
coding in Python for 3 weeks when I wrote it.  On the positive side,
it exposed many weaknesses in many developer's code (including our own
at InfoSeek), as well as in core Python code (subtle bugs in the
interpreter) that surely helped everyone.  Even though I was a newbie,
It was VERY carefully crafted,, and I'd expect that it would take a
fair amount of effort to reproduce it (and that is is probably why it
has not been changed much... or at least no one told me when they
changed/fixed it ;-) ).

With regard to why I probably can't help much.

First off, InfoSeek (holder of the copyright) was bought by Disney,
and I don't know what if anything has eventually become of the
tradename.  There is a chance that Disney owns the rights... and I
have no idea who to ask there :-/.

Second, I took a look at the Copyright, and it sure seems pretty
permissive.  I'm amazed if folks want something more permissive.  
This is what I found on the web for it:

Copyright © 1994, by InfoSeek Corporation, all rights reserved.

Written by James Roskind.10.1

Permission to use, copy, modify, and distribute this Python
software and its associated documentation for any purpose (subject to
the restriction in the following sentence) without fee is hereby
granted, provided that the above copyright notice appears in all
copies, and that both that copyright notice and this permission notice
appear in supporting documentation, and that the name of InfoSeek not
be used in advertising or publicity pertaining to distribution of the
software without specific, written prior permission. This permission
is explicitly restricted to the copying and modification of the
software to remain in Python, compiled Python, or other languages
(such as C) wherein the modified or derived code is exclusively
imported into a Python module.

INFOSEEK CORPORATION DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS
SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND
FITNESS. IN NO EVENT SHALL INFOSEEK CORPORATION BE LIABLE FOR ANY
SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER
RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF
CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN
CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.

As I recall, I probably personally created the terms of the above
license.  I used a similar license on my C/C++ grammar, and Infoseek
just added a bunch of wording to be sure that they were not at risk,
and that their name would not be used in vain (or in advertising
material).  I think they were also interested in limiting its use to
Python but I don't think that is a concern that would bother you.

I read the link you directed me to, and its primary focus seemed ot be
on patents for related or included technology.

I don't believe that infoseek applied for or got any patents in this
area (and certainly if they did so without my name, it would probably
invalidate the patent), and I'm sure I didn't get any patents in this
area at Netscape/AOL.  In fact I don't think I got any patents back in
1994 or 1995.  My only prior patent dated back to about 1983 (a
hardware patent) that has since expired.

I have some patents since (roughly) 1995, and even though I don't
think any of them relate to profiling (though some did relate to
languages, or more specifically, security in languages), I wouldn't
want to mess with assigning rights to any of those patents, as they
belong to AOL/Netscape.  Here again, to my knowledge, none of my
patents relate in any way to this area (profiling).  Sadly, if they
did, I would not have the right to assign them.

I'm sure you're just doing your job, and following through by dotting
all the I's and crossing all T's.  My suggestion is to (as you said)
work around the issue.  You could always re-write the code from
scratch, as the approaches are not rocket science and are pretty
thoroughly explained.  I wouldn't suggest it unle

Re: [Python-Dev] Fixing _PyEval_SliceIndex so that integer-like objects can be used

[David Ascher]

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] Fixing _PyEval_SliceIndex so that integer-like objects can be used

[David Ascher]

On Fri, 18 Feb 2005 15:40:54 -0700, Travis Oliphant <[EMAIL PROTECTED]> wrote:
> Guido van Rossum 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,
> >
> >
> O.K.,
> 
> then how about if arrayobjects can make it in the core, then a check for
> a rank-0 integer-type
> arrayobject is allowed before raising an exception?

Following up on Bob's point, maybe making rank-0 integer type
arrayobjects inherit from int has some mileage?  Somewhat weird,
but...
___
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

[David Ascher]

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] FWD: SD MAgazine.com - Jolt Awards Winners

[David Ascher]

On Thu, 10 Mar 2005 19:23:41 -0500, Aahz <[EMAIL PROTECTED]> wrote:
> Guido may not be able to go.  Anyone else already going?

I may, but only on the 18th, not the 16th.  So that doesn't really work =).

> 
> - Forwarded message from [EMAIL PROTECTED] -
> 
> > Subject: Request - SD MAgazine.com - Jolt Awards Winners
> > To: [EMAIL PROTECTED]
> > From: [EMAIL PROTECTED]
> > Date: Thu, 10 Mar 2005 16:02:35 -0800
> >
> > HI Python.org,
> >
> > You may or may not be aware that Python is a finalist in the 15th
> > Annual Jolt Awards in the Languages and Development Category.The
> > awards ceremony will take place at SD West, in the Santa Clara
> > Convention Center, Auditorium, on March 16th from 6:30-7:30 p.m., when
> > the winners will be announced.  Is there anyway that a representative
> > of Python.org be present to accept the award if they should win?  I
> > will have badges for these individuals at the registration desk to
> > attend the awards ceremony.
> >
> > I understand the Guido van Rossum will be attending SD West. Is there
> > anyway that he can be present?
> >
> > All finalists and conference alumni are invited to a poolside party
> > with food, drinks and entertainment after the ceremony at the
> > Westin, which is adjacent to the Conference Center. Hope to see you
> > there. Dress should be business casual.
> >
> > Looking forward to hearing from you.
> >
> > Rosalyn
> > (415) 947-6182
> >
> >
> > =
> > Rosalyn Lum
> > Technical Editor
> > Software Development Magazine
> > CMP Media
> > 600 Harrison St., 6th Floor
> > San Francisco, CA 94107
> > www.sdmagazine.com
> 
> - End forwarded message -
> 
> --
> Aahz ([EMAIL PROTECTED])   <*> http://www.pythoncraft.com/
> 
> "The joy of coding Python should be in seeing short, concise, readable
> classes that express a lot of action in a small amount of clear code --
> not in reams of trivial code that bores the reader to death."  --GvR
> ___
> 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/david.ascher%40gmail.com
>
___
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()

[David Ascher]

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] Re: anonymous blocks

[David Ascher]

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] PEP 340 - possible new name for block-statement

[David Ascher]

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


___
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

[David Ascher]

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

[David Ascher]

> 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