Greg Ewing wrote:
> 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!
I'll have more to say on this later - but for now, l
On 5/8/06, Greg Ewing <[EMAIL PROTECTED]> 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 t
On 5/8/06, Talin <[EMAIL PROTECTED]> wrote:
> Lets say we outlaw the use of isSequence - how do you propose to
> implement this type of pattern? Or are you saying that this pattern is
> bad style?
Generic (overloadable) functions. See the archives - it's possible the
discussion was before you subs
Paul Moore <[EMAIL PROTECTED]> wrote:
>> Lets say we outlaw the use of isSequence - how do you propose to
>> implement this type of pattern? Or are you saying that this pattern
>> is bad style?
>
> Generic (overloadable) functions. See the archives - it's possible the
> discussion was before you s
On 8-mei-2006, at 2:55, 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 distributio
On 8-mei-2006, at 4:07, Bill Janssen wrote:
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.
What version of OSX are you using? /usr/bin/python on 10.4
On 8-mei-2006, at 8:58, Talin wrote:
And *how* exactly would you implement your isFunction test
so as to detect the "naive, everyday concept of a function"
that you seem to want, in a way that does any better job
than the current callable()?
This 'isFunction' test that I am thinking of would
On 5/8/06, Talin <[EMAIL PROTECTED]> wrote:
Thomas Wouters python.org> writes:> He is, and for the same reasons as callable(): there is no way to> tell whether an object is a mapping or a sequence (considering
> Python object of both 'types' implement __getitem__, and that's> it. If you don't beli
Ronald Oussoren wrote:
> On 8-mei-2006, at 4:07, Bill Janssen wrote:
> >
> > Much as we might like to think otherwise, there's no standard GUI in
> > the Python core, and IDLE (or anything else that depends on it) won't
> > work in some cases where it should work.
>
> Yes there is. Some distributo
Aahz wrote:
> First of all, Mac users downloading a release get Tk automatically.
I stand corrected -- I wasn't aware that the Mac
version came with Tk these days.
> Secondly, your argument sounds like a variant of the argument against
> adding pysqlite to the core,
It's not really the same thi
Talin wrote:
>
> There are two reasons why I think that bundling a GUI library with
> Python is a good idea:
>
> -- It makes it possible to include GUI-based tools and applications
> in the base distribution.
I agree with this, although how ambitious are such tools? If you're just
popping a d
Thomas Wouters wrote:
> Duck typing isn't "ask the object whether it can do this". Duck typing is
> "do this". I don't believe 'taking different actions based on capabilities'
> is all that common, and it certainly breaks easily.
have you used callable(), or are you just making things up ?
> It
Talin wrote:
> This 'isFunction' test that I am thinking of would only return true for
> user defined functions, built-in functions, and similar objects; It
> would not return true for classes or other objects that are technically
> functions in a mathematically pure sense, but which normal peo
Bill Janssen writes:
> I don't want to ever again use a library that claims to export a
> "dict" object, only to find (later) that the implementor hasn't
> implemented some of the methods of the real "dict" type because he
> thought they wouldn't be called.
And there is the crux of the matter. I *
Paul Moore wrote:
> guess('y') is *both* a string and a callable. OK, so it's a contrived
> example
generalizing from one contrived example is worse than generalizing from
no example at all.
___
Python-3000 mailing list
[email protected]
http
On 5/8/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
Thomas Wouters wrote:> Duck typing isn't "ask the object whether it can do this". Duck typing is> "do this". I don't believe 'taking different actions based on capabilities'> is all that common, and it certainly breaks easily.
have you used callab
Paul Boddie wrote:
> Promoting a successor to stdwin doesn't seem like progress to me.
It's a bit hard to sort out what you're actually saying
in all that. Are you arguing for or against something
like PyGUI?
The Gnome vs. KDE issue seems like an argument in
favour to me. Because the alternative
Thomas Wouters wrote:
> Duck typing isn't "ask the object whether it can do this". Duck typing is
> "do this".
that's your own definition, by the way. the usual definition is the one in the
Python
tutorial:
Duck Typing
Pythonic programming style that determines an object's type by ins
Greg Ewing 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 calla
On 5/8/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
it's spelled callable(), is successfully used in popular and well-designed API:s, is well-defined in terms of duck-typing, and all counter-examples we've seen on this list areutterly contrived.
Dare I suggest you convince Guido not to remove calla
On 5/8/06, Talin <[EMAIL PROTECTED]> wrote:
> Before we go to much further on this point, I want to get a sense of
> what exactly people are objecting to:
> -- Are they saying that interface discovery is not important, or is
> bad style?
Not in principle.
In practice, certain implementation
On Mon, May 08, 2006, Paul Boddie wrote:
>
> Well, Tk is available on the "big three" (Windows, Mac, UNIX),
> but if you venture onto other platforms, don't expect to find it
> there. People may argue that the "big three" are all that matter,
> but that argument usually ends up with the "big two" a
On 5/8/06, Paul Boddie <[EMAIL PROTECTED]> wrote:
> Talin wrote:
> > There are two reasons why I think that bundling a GUI library with
> > Python is a good idea:
> > -- It makes it possible to include GUI-based tools and applications
> > in the base distribution.
> I agree with this, although
On 8-mei-2006, at 2:55, Greg Ewing wrote:
> There *isn't* currently any GUI in the core distribution
> except on Windows.
Given that Tk is open source, how much of a problem is this? Would it
be solved by simply including a snapshot of Tk in the source
distribution?
Most windows users cannot com
Le lundi 08 mai 2006 à 07:13 -0700, Aahz a écrit :
> Aside from Java and Swing (which has its own set of problems), is there
> any readily-available GUI that includes a significant number of platforms
> other than the Big Three?
>From the wxWidgets FAQ:
« What platforms are supported by wxWidgets
On Mon, 2006-05-08 at 15:55 +0200, Thomas Wouters wrote:
> Dare I suggest you convince Guido not to remove callable(), then? That
> is, after all, what this discussion is about.
We use callable() and PyCallable_Check() in a couple of places. I'm not
sure that our uses are enough to keep these al
Talin writes:
> Before we go to much further on this point, I want to get a sense of
> what exactly people are objecting to:
Good question. Answers below (speaking for myself only, of course!):
> -- Are they saying that interface discovery is not important, or is
> bad style? (Its hard to do
On Mon, May 08, 2006, Antoine Pitrou wrote:
> Le lundi 08 mai 2006 ? 07:13 -0700, Aahz a ?crit :
>>
>> Aside from Java and Swing (which has its own set of problems), is there
>> any readily-available GUI that includes a significant number of platforms
>> other than the Big Three?
>
> ? What platfo
On Monday 08 May 2006 15:30, Greg Ewing wrote:
> Paul Boddie wrote:
> > Promoting a successor to stdwin doesn't seem like progress to me.
>
> It's a bit hard to sort out what you're actually saying
> in all that. Are you arguing for or against something
> like PyGUI?
I'm not against PyGUI. Actuall
On Monday 08 May 2006 05:39, Ronald Oussoren wrote:
> Yes there is. Some distributors are lame enough to think they know better
> and ship parts of the standard library seperately, but that's not a valid
> reason for removing parts of the stdlib.
Hopefully they'll learn. This is been a regular
On 5/8/06, Barry Warsaw <[EMAIL PROTECTED]> wrote:
> Perhaps then, if we get rid of callable()/PyCallable_Check() it would be
> useful to add a NotCallableError (as a subclass of TypeError?) that
> would get thrown should you try to call something that's not callable.
> The argument to the exceptio
On Monday 08 May 2006 16:20, Jim Jewett wrote:
> On 5/8/06, Paul Boddie <[EMAIL PROTECTED]> wrote:
> >
> > I agree with this, although how ambitious are such tools? If you're just
> > popping a dialogue asking for user input, there are typically other means
> > of doing that without bringing in a w
On 8-mei-2006, at 17:38, Fred L. Drake, Jr. wrote:
On Monday 08 May 2006 05:39, Ronald Oussoren wrote:
Yes there is. Some distributors are lame enough to think they know
better
and ship parts of the standard library seperately, but that's not
a valid
reason for removing parts of the stdlib
On Monday 08 May 2006 11:47, Ronald Oussoren wrote:
> I don't think they'll ever learn, because there is a good reason for
> putting tkinter in a separate os package: the dependency on tcl/tk.
> Because of this it is probably save to assume that any GUI package
> will suffer from this split by
On 5/6/06, Talin <[EMAIL PROTECTED]> wrote:
> I'd be curious to know how many Python developers actually use IDLE?
I do.
The fact that 2.5 got to alpha 2 before anyone noticed that the new
Quitter object didn't work suggests that either I'm in the minority.
(Though that could just be not shutti
I think that there are at least six large GUI platforms these days:
Windows, Mac, X11, Java Swing, .NET Windows.Forms, and AJAX
(CSS/HTML/Javascript/DOM/SVG).
I think you could further argue that the X11 world splits into GNOME
and KDE subsets.
What's interesting about PyGUI is that while it's n
> As to whether PyGUI or anything else of that nature should be in the standard
> library, my feeling is that if it (PyGUI or anything else) cannot deliver the
> desired functionality without leaving various kinds of users looking for
> another toolkit at some level of ambition (eg. providing a
Barry Warsaw <[EMAIL PROTECTED]> writes:
> Obviously if someone registers a callback that isn't callable,
> we don't want to waste time on every iteration trying to call it,
> only to catch whatever error might occur.
Who cares about performance of wrong code?
--
__("< Marcin Kowalcz
Aahz wrote:
> On Mon, May 08, 2006, Paul Boddie wrote:
>>
>> Well, Tk is available on the "big three" (Windows, Mac, UNIX),
>> but if you venture onto other platforms, don't expect to find it
>> there. People may argue that the "big three" are all that matter,
>> but that argument usually ends up
On Mon, 2006-05-08 at 20:36 +0200, Marcin 'Qrczak' Kowalczyk wrote:
> Barry Warsaw <[EMAIL PROTECTED]> writes:
>
> > Obviously if someone registers a callback that isn't callable,
> > we don't want to waste time on every iteration trying to call it,
> > only to catch whatever error might occur.
>
On Mon, 2006-05-08 at 09:47 -0600, Steven Bethard wrote:
> On 5/8/06, Barry Warsaw <[EMAIL PROTECTED]> wrote:
> > Perhaps then, if we get rid of callable()/PyCallable_Check() it would be
> > useful to add a NotCallableError (as a subclass of TypeError?) that
> > would get thrown should you try to c
On 5/8/06, Giovanni Bajo <[EMAIL PROTECTED]> wrote:
...
> of Qt (it's not a case that Qt is leader in the C++ GUI market). It's not
I think Giovanni means "it's not by chance that" (&c), i.e. he's
asserting that Qt IS the leader, and that there are non-random
explanations for this (sorry for bu
On 5/7/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> 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 wa
Paul Boddie wrote:
> Perhaps you can say that "I'm going to do a small project which only needs
> the
> standard library API" or instead that "I'm going to write a mega-application
> which needs a complicated API"
There seems to be an assumption here that a big application
with a complicated U
Alex Martelli wrote:
> On 5/8/06, Giovanni Bajo <[EMAIL PROTECTED]> wrote:
>
>>of Qt (it's not a case that Qt is leader in the C++ GUI market). It's not
>
> I think Giovanni means "it's not by chance that" (&c), ...
> it looks to me like
> Giovanni's transliterating an Italian idiom too literally
Paul Boddie wrote:
> I think it would be
> a bad thing if something in the standard library claimed to provide, or just
> gave the vague impression of providing, a definitive solution for all
> environments
I would never claim that PyGUI provided a definitive solution
for all environments (and
On 5/8/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Alex Martelli wrote:
> > On 5/8/06, Giovanni Bajo <[EMAIL PROTECTED]> wrote:
> >
> >>of Qt (it's not a case that Qt is leader in the C++ GUI market). It's not
> >
> > I think Giovanni means "it's not by chance that" (&c), ...
> > it looks to me li
Can we just agree to disagree? Read the piece on python.org/dev about
knowing when to stop.
On 5/8/06, Collin Winter <[EMAIL PROTECTED]> wrote:
> On 5/7/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > On 5/7/06, Collin Winter <[EMAIL PROTECTED]> wrote:
> > > This -- more intuitive error messag
On 5/8/06, Steven Bethard <[EMAIL PROTECTED]> wrote:
> It'd certainly be nice to be able to tell the difference between
> the following two TypeErrors:
>
> >>> def s():
> ... raise TypeError()
> ...
> >>> 's'()
> Traceback (most recent call last):
> File "", line 1, in
On 5/8/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 5/8/06, Steven Bethard <[EMAIL PROTECTED]> wrote:
> > It'd certainly be nice to be able to tell the difference between
> > the following two TypeErrors:
> >
> > >>> def s():
> > ... raise TypeError()
> > ...
> > >>> 's'
Well, personally, I don't see the advantage. I don't see the point of
having lots of different exception types that say "you made a
programming error" in different ways, and I severely doubt the
usefulness of being able to distinguish between those different
failure modes at run time. Others do. I
On Mon, 2006-05-08 at 20:51 -0700, Guido van Rossum wrote:
> Well, personally, I don't see the advantage. I don't see the point of
> having lots of different exception types that say "you made a
> programming error" in different ways, and I severely doubt the
> usefulness of being able to distingui
Now we're talking. Although it might make more sense if (an
abbreviated form of) its repr() were included in the error message --
that would help most humans diagnose the situation most easily.
--Guido
On 5/8/06, Barry Warsaw <[EMAIL PROTECTED]> wrote:
> On Mon, 2006-05-08 at 20:51 -0700, Guido v
Guido van Rossum wrote:
> Well, personally, I don't see the advantage. I don't see the point of
> having lots of different exception types that say "you made a
> programming error" in different ways, and I severely doubt the
> usefulness of being able to distinguish between those different
> failur
Greg Ewing <[EMAIL PROTECTED]> wrote:
> In the interests of keeping it small (both in terms of API
> and code size) I don't consider it vital to provide a huge
> number of widgets. I'd rather have a compact library with
> 10 well-chosen generally-useful widgets that I can build on,
> than a bloate
Jim Jewett gmail.com> writes:
> On 5/8/06, Talin acm.org> wrote:
> > Before we go to much further on this point, I want to get a sense of
> > what exactly people are objecting to:
>
> > -- Are they saying that interface discovery is not important, or is
> > bad style?
>
> Not in principle.
Guido van Rossum wrote:
> Now we're talking. Although it might make more sense if (an
> abbreviated form of) its repr() were included in the error message --
> that would help most humans diagnose the situation most easily.
While we're on the subject, something that causes me
intense annoyance fro
57 matches
Mail list logo
