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
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
___
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
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
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
___
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
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
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
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/
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
Python-3000@python.org
http://mail.
> 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 *
> 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
;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: python-3000@python.org
> Subject: Re: [Python-3000] in-out parameters
>
> On 5/
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
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
> > 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/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
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.
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
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
"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
>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
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
23 matches
Mail list logo
