On 5/7/06, Talin <[EMAIL PROTECTED]> wrote:
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 tha
Thomas Wouters python.org> writes:
> It may be 'common' for programmers to try and write this kind of
code (accept either a string or an instance, a sequence or a single
object, etc) but it's certainly not a common idiom -- idioms don't suck
As an example, lets take a look at re.sub:
sub(p
On 5/7/06, Talin <[EMAIL PROTECTED]> wrote:
> As an example, lets take a look at re.sub:
>
>sub(pattern, repl, string[, count])
>
> The documentation says that "repl can be a string or a function" and
> "If repl is a function, it is called for every non-overlapping occurrence
> of pattern. The
Talin wrote:
> A common Python idiom is to take different actions based on the capabilities
> of an object rather than its type.
I have no objection to that when the capability can be
tested for easily and efficiently and without danger of
causing undesirable side effects. But callability is
not
Talin wrote:
> (Admittedly this particular case could be done without 'callable', since you
> could test for string type, and assume callable otherwise.
Yes, and that's exactly why it can be made to work
in this particular case. Most likely no testing for
callability is being done, only isinstanc
Greg Ewing wrote:
> Talin wrote:
>
>> (Admittedly this particular case could be done without 'callable', since you
>> could test for string type, and assume callable otherwise.
>
> Yes, and that's exactly why it can be made to work
> in this particular case. Most likely no testing for
> callabili
Le dimanche 07 mai 2006 à 17:47 +1200, Greg Ewing a écrit :
> 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
On 5/6/06, Talin <[EMAIL PROTECTED]> wrote:
> 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 t
On May 6, 2006, at 6:37 PM, Greg Ewing wrote:
...
> The disadvantages associated with very strong type systems
> arise because of their strength, not whether they are
> static or dynamic. A language with the same type system
> as Java, but enforced at run time instead of compile
> time, would
Alex Martelli <[EMAIL PROTECTED]> writes:
> Java's typechecking IS enforced at runtime just about each and every
> time you cast something (I'm told the need for casting has diminished
> with Java 1.5's generics, but I have no experience of 1.5; earlier,
> casts abounded each time you used c
> From: Greg Ewing <[EMAIL PROTECTED]>
> There is another alternative -- move both Tk and IDLE out of the core
> into separate downloads.
+1.
Greg
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Un
On 5/6/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> 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
On 5/7/06, Greg Wilson <[EMAIL PROTECTED]> wrote:
> > From: Greg Ewing <[EMAIL PROTECTED]>
> > There is another alternative -- move both Tk and IDLE out of the core
> > into separate downloads.
>
> +1.
If the implication here is that there is *no* GUI in the Python
standard library, I'd be cautiou
Guido van Rossum python.org> writes:
> > 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 want to know if somet
Talin <[EMAIL PROTECTED]> writes:
> How about instead of 'callable', an "isFunction' test to go along
> with 'isSequence' and 'isMapping'. (You aren't getting rid of those -
> I hope...?)
Such predicates, unless backed by some explicit or strict criterion
like isinstance, are as suspicious for me
> A language with the same type system
> as Java, but enforced at run time instead of compile
> time, would be just as annoying to use.
Python already has a different, and in many respects better, type
system than Java has. I'm simply suggesting that the common practice
of ignoring -- or worse, s
On Sun, May 07, 2006 at 02:24:08PM -0700, Bill Janssen wrote:
> I think that there is little of advantage in the Java type system to
> be adopted into Python.
One thing from Java I really miss in Python - declaration what
exception(s) a function/method can raise. Almost nobody almost never
docu
On 5/7/06, Oleg Broytmann <[EMAIL PROTECTED]> wrote:
On Sun, May 07, 2006 at 02:24:08PM -0700, Bill Janssen wrote:> I think that there is little of advantage in the Java type system to> be adopted into Python. One thing from Java I really miss in Python - declaration what
exception(s) a function/
On 5/7/06, Talin <[EMAIL PROTECTED]> wrote:
All right, I'll desist.[insert distinct sound of persistance]
How about instead of 'callable', an "isFunction' test to go alongwith 'isSequence' and 'isMapping'. (You aren't getting rid of those -I hope...?)He is, and for the same reasons as callable():
Thomas Wouters python.org> writes:
> On 5/7/06, Talin acm.org> wrote:
>
> > How about instead of 'callable', an "isFunction' test to go alongwith
> > 'isSequence' and 'isMapping'. (You aren't getting rid of those
> > - I hope...?)
>
> He is, and for the same reasons as callable(): there is no w
Paul Moore wrote:
> If the implication here is that there is *no* GUI in the Python
> standard library, I'd be cautious of this (-0, probably). Things like
> the pydoc server use a little GUI window.
There *isn't* currently any GUI in the core distribution
except on Windows. Non-Windows users alr
Talin wrote:
> How about instead of 'callable', an "isFunction' test to go along
> with 'isSequence' and 'isMapping'. (You aren't getting rid of those -
> I hope...?)
Yes, we are! And for much the same reasons!
And *how* exactly would you implement your isFunction test
so as to detect the "naive
Bill Janssen wrote:
> I think that there is little of advantage in the Java type system to
> be adopted into Python. One possible addition is the often-discussed
> optional type declarations and associated ability to define an
> interface for a module or class.
The problem with something like th
On 07/05/06 Brett Cannon said:
> Checked exceptions are the worst feature of Java in my opinion. =)
Seconded. This basically results in people writing methods that all throw
Exception, instead of something useful. Otherwise, if you make a small change
in your code, you'll find that it's not loca
On Mon, May 08, 2006, Greg Ewing wrote:
> Paul Moore wrote:
>>
>> If the implication here is that there is *no* GUI in the Python
>> standard library, I'd be cautious of this (-0, probably). Things like
>> the pydoc server use a little GUI window.
>
> There *isn't* currently any GUI in the core di
Aahz,
> First of all, Mac users downloading a release get Tk automatically.
Good idea!
I run on a Mac, and don't download -- I use the pre-installed Python
on the Mac. And there's no Tk.
Much as we might like to think otherwise, there's no standard GUI in
the Python core, and IDLE (or anything
On 5/1/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 4/29/06, Steven Bethard <[EMAIL PROTECTED]> wrote:
> > Yes, I think it definitely makes more sense to make the modifications
> > on 2.x. I was hesitant to require integrating it into the main-line
> > Python 2.x code because I was worried
On 5/7/06, Collin Winter <[EMAIL PROTECTED]> wrote:
> This -- more intuitive error messages -- is really what I'm after, and
> while you may think of type of "def foo(a, b, c):..." as "a function
> with three required arguments", I'd wager that most Python
> programmers, if asked what type foo has,
Is it possible to include a python daemon that will shorten startup time
and share most stdlib among all the python instances? If extension
libraries like pygtk can also be sured in memory, then maybe the total
memory usage can be greatly reduced for python gui applications. That
will encourage pe
This is not a Py3k topic. I suspect this can be done easily today if
you need it. Please post to comp.lang.python instead.
--Guido
On 5/7/06, JustFillBug <[EMAIL PROTECTED]> wrote:
>
> Is it possible to include a python daemon that will shorten startup time
> and share most stdlib among all the p
30 matches
Mail list logo
