Krishna Sankar <[EMAIL PROTECTED]> wrote:
> b)Of course, we can simulate "in" by a deep copy to a temp variable
> and then restoring the variable back before return. The "out" and
> "inout" do not need any special tratment.
Or the writer of a function can document what the function does, and
>From what I understand, the "mission statement" of Python 3000 is not to load
up the lanugage with a bunch of sexy new programming features, but rather to
"go back in time" and make small changes to the original Python design that have
turned out to be problematic in practice.
One of those proble
"Guido van Rossum" <[EMAIL PROTECTED]> wrote:
>
> On 5/4/06, Josiah Carlson <[EMAIL PROTECTED]> wrote:
> >
> > "Guido van Rossum" <[EMAIL PROTECTED]> wrote:
> > > Can you please post the benchmarking code?
> >
> > No problem.
>
> OK, so I have the advantage of a time machine... Or at least the p
Talin wrote:
> I'm sure that the question of whether IDLE should be fixed or dropped will
> start a huge flamewar; But the alternative is to do nothing, which seems
> even worse from my viewpoint.
There is another alternative -- move both Tk and IDLE out
of the core into separate downloads.
--
G
Bill Janssen wrote:
> GvR writes:
>>On 5/5/06, Bill Janssen <[EMAIL PROTECTED]> wrote:
>Is there anywhere else in Python where the type of an object isn't
>checkable with isinstance()?
Yes, it's called duck typing.
>>>And, in my opinion, it's probably worth stomping out in Py3K.
>>You w
Le samedi 06 mai 2006 à 08:05 -0400, Blake Winton a écrit :
> Bill Janssen wrote:
> > GvR writes:
> >>On 5/5/06, Bill Janssen <[EMAIL PROTECTED]> wrote:
> >Is there anywhere else in Python where the type of an object isn't
> >checkable with isinstance()?
> Yes, it's called duck typing.
On 5/5/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 5/5/06, Collin Winter <[EMAIL PROTECTED]> wrote:
> > On 5/1/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> > > The Type Error is actually referring to the type of 'foo' - the code is
> > > clearly expecting it to be something with a differe
> > d) One clear advantage is that this will minimize side effects and
> > surprises/programming, eventually adding reliabliltiy to
> the systems
> > developed using py.
>
> That seems to imply that programming with Python has more
> surprises and/or less reliability than other languages; a
>
On 5/6/06, Collin Winter <[EMAIL PROTECTED]> wrote:
> On 5/5/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > I'm not sure it's worth distinguishing call signature errors from
> > other type errors; there's already a gray area where sometimes a
> > TypeError is reported as an AttributeError or v
On 5/6/06, Krishna Sankar <[EMAIL PROTECTED]> wrote:
> Nope, that is not what I meant. Eventually adding *more* reliability
> to py programs.
Please stop this debate. It's not going to happen. And taking
arguments from Ada and applying them to Python is not a useful way to
predict whether
;o) Agreed. Enough said ...
Cheers
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
> Behalf Of Guido van Rossum
> Sent: Saturday, May 06, 2006 8:32 AM
> To: Krishna Sankar
> Cc: [email protected]
> Subject: Re: [Python-3000] in-out parameters
>
> On 5/
> Seriously, if I wanted a language that restricted me to classes and
> subtyping and mixins, I'ld use Java.
Sadly, Java doesn't give you the tools you need to do that. If you
think that Java is what I'm talking about, you're misunderstanding my
suggestion, and I can see why you would have a neg
> If you want a Python-lookalike with strong static typing (and optional
> duck typing with the "duck" keyword!), then try Boo:
> http://boo.codehaus.org/Home
Thanks, Antoine, but I don't want strong static typing at all. I
wouldn't mind optional partial static typing, but what I want is
strong *
On Saturday 06 May 2006 07:33, Greg Ewing wrote:
> There is another alternative -- move both Tk and IDLE out
> of the core into separate downloads.
+1
-Fred
--
Fred L. Drake, Jr.
___
Python-3000 mailing list
[email protected]
http://mail.
On 5/6/06, Fred L. Drake, Jr. <[EMAIL PROTECTED]> wrote:
> On Saturday 06 May 2006 07:33, Greg Ewing wrote:
> > There is another alternative -- move both Tk and IDLE out
> > of the core into separate downloads.
>
> +1
Works for me.
--
--Guido van Rossum (home page: http://www.python.org/~guido/
http://iostack.wikispaces.com/
that's the code i've came up with. i'll be adding the rest of
the stream stack sooner or later, but the new socket
module is ready, imho. it's still a prototype, but i've done
some tests, and i like the feeling of it.
feel free to comment / test / fix bugs / suggest
Bill Janssen parc.com> writes:
> Folks, I've got a paper deadline looming, and helpful as this
> discussion has been in my procrastination , I need to get back to it.
> I'll take this thread up again next week, if no one else does.
>
> Please feel free to send me mail in the meantime, and try a
Collin Winter wrote:
> Do you change
> function X to match the call site or write a function with the proper
> signature that wraps function X? Of course not. You change the call
> site to match the signature.
Or to put it another way, calling this a TypeError assumes
that you were mistaken about
Krishna Sankar wrote:
> Nope, that is not what I meant. Eventually adding *more* reliability to py
> programs.
But at what cost? There is a large downside to all
the B&D in languages like Java. One of Python's
biggest strengths is that it doesn't have any of
that.
--
Greg
___
Bill Janssen wrote:
> Thanks, Antoine, but I don't want strong static typing at all. I
> wouldn't mind optional partial static typing, but what I want is
> strong *dynamic* typing
How strong do you want it, exactly?
The disadvantages associated with very strong type systems
arise because of the
I want to say that I agree with everything in PEP 3100 except for two things:
1) Getting rid of 'callable'.
The reccomended replacement is "just call the object and catch the resulting
exception", but I can think of a lot of situations where that wouldn't be
appropriate. For example, what if you
Talin wrote:
> 1) Getting rid of 'callable'.
>
> The reccomended replacement is "just call the object and catch the resulting
> exception",
No, the recommended replacement should be "redesign your API
so that you don't need to test whether something is callable".
--
Greg
___
Greg Ewing canterbury.ac.nz> writes:
> Talin wrote:
>
> > 1) Getting rid of 'callable'.
> >
> > The reccomended replacement is "just call the object and catch the resulting
> > exception",
>
> No, the recommended replacement should be "redesign your API
> so that you don't need to test whether
23 matches
Mail list logo
