On Wednesday, May 10, 2006, at 08:26AM, Bill Janssen <[EMAIL PROTECTED]> wrote:
>> If I understand your proposal correctly, this approach doesn't do anything
>> beyond what Java does, and is inferior to already-available adaptation and
>> interface systems for today's Python.
>
>Inferior is in
>> [Antoine Pitrou]
>> But magic numbers are ugly, even if they are hidden behind an
>> enumeration. If you try to print them for debugging, it will only show
>> the numeric values, which is hardly intuitive.
>> [...]
>> [Giovanni Bajo]
>> No, you're over-generalizing. What if I wanted the buttons
Greg Ewing wrote:
>>Qt, Java Swing, and .Net Windows.Forms are all examples of what I would
>>consider "good" API designs. All three of them are powerful,
>>comprehensive, and have relatively clean APIs. I would be perfectly
>>satisfied to have the equivalent of any one of them in the Python sp
[EMAIL PROTECTED] wrote on
09/05/2006 18:25:29:
> On Tuesday 09 May 2006 13:10, Antoine Pitrou wrote:
> > Interestingly, there was a GNU addition to C++ named "signatures"
which
> > achieved roughly the same thing: some kind of compile-time
duck-typing.
> >
> > http://gcc.gnu.org/onlinedocs
Greg Ewing <[EMAIL PROTECTED]> wrote:
> PyGUI currently has a form of this, except that you
> only get to plug in one handler at a time. This is
> enough to avoid the need for subclassing in many
> cases, though.
>
> I could support multiple handlers, but it would
> make things substantially more
On Wednesday, May 10, 2006, at 12:24PM, Giovanni Bajo <[EMAIL PROTECTED]> wrote:
>
>> and then I find that
>> multiple-handler systems (e.g. gtk signals) tend
>> to hinder more than they help.
>
>Is there a production-ready GUI toolkit that *doesn't* have multiple handlers?
AFAIK Cocoa doesn't
joe user wrote:
> Does this mean you have no more actual technical reasons to oppose this
> change, but are just stomping your foot and implying bad things about
> Winter? Because there are people who agree with him, and I haven't seen
> any really compelling reasons to avoid this ten-line modific
Greg Ewing wrote:
> Antoine Pitrou wrote:
>
>
>>button = gui.Button(...)
>>button.on_clicked += my_on_clicked_button
>
>
>>Has anyone had any experience with this idiom? Are there any drawbacks?
>>It looks more elegant than inheritance and overriding methods to me.
>
>
> PyGUI currently has
Baptiste Carvello wrote:
> "if it looks like a duck from half a mile away, then it *might* be a duck"
>
> Sometimes, you just don't want to walk half a mile for nothing :)
That's beautiful. Now we just need somewhere to put a QOTW for the Py3k list ;)
> Sorry for this "philosophical" post. I hop
On Wed, 10 May 2006 08:46 am, Talin wrote:
> Michael Chermside mcherm.com> writes:
> > Talin writes:
> > > Lets start a new top-level thread to discuss this specific
> > > proposal.
> >
> > tomer filiba writes:
> > > i'm sure my idea has flaws, but i'm very much pro-changing the type
> > > system.
On 5/10/06, Bill Birch <[EMAIL PROTECTED]> wrote:
> A simple test to see where your thinking is at. Consider:
[...]
> The manual for isinstance() says: "return true if classinfo is a type object
> and object is an object of that type". So consider this:
>
> isinstance( D(), I1 )
>
> Is thi
Talin <[EMAIL PROTECTED]> writes:
> OK, so I hope I have established the requirement for duck typing.
> Now, I want to establish the requirement for interface discovery
> or 'type testing'.
These two are mutually incompatible. At least if we expect libraries
to be reliable and robust.
Python mus
At 04:59 PM 5/10/2006 +0200, Marcin 'Qrczak' Kowalczyk <[EMAIL PROTECTED]>
wrote:
>Explicitly declared interfaces have a partial order, which is useful
>for dispatch.
Note that if the notion of "interface" is reduced to "a set of generic
functions to which an object may be passed", then it's not
At 11:21 AM 5/10/2006 +0100, [EMAIL PROTECTED] wrote:
>Have you taken a look at ConceptGCC? (
>http://www.osl.iu.edu/~dgregor/ConceptGCC/)
>
>It's basically a first cut at implementing the Concepts which will be
>availiable in the next version of C++. They basically provide full compile
>time "duck
> >> this approach doesn't do anything beyond what Java does
> >
> >Actually, it does. It lets you inherit behavior, as well as interfaces.
>
> It only lets you inherit behaviour to new subclasses
Not that it matters, but... Yes, that's right. In systems like
these, that's how you "add functio
At 10:12 AM 5/10/2006 -0700, Bill Janssen wrote:
> > >> this approach doesn't do anything beyond what Java does
> > >
> > >Actually, it does. It lets you inherit behavior, as well as interfaces.
> >
> > It only lets you inherit behaviour to new subclasses
>
>Not that it matters, but...
Clearly it
On 5/10/06, Bill Janssen <[EMAIL PROTECTED]> wrote:
> > It only lets you inherit behaviour to new subclasses
> Not that it matters, but... Yes, that's right. In systems like
> these, that's how you "add functionality to already existing classes";
> you mix them with the new functionality into a
"Phillip J. Eby" <[EMAIL PROTECTED]> writes:
> Note that if the notion of "interface" is reduced to "a set of generic
> functions to which an object may be passed", then it's not necessary
> to have explicit interface declaration - it's an automatic side effect
> of implementing methods for the ge
At 11:31 AM 5/10/2006 -0700, Bill Janssen wrote:
> > Which makes them inferior to existing adaptation systems for Python, which
> > in turn are inferior to generic functions.
>
>"Inferior" according to some belief system you obviously feel strongly
>about.
According to a very straightforward defin
On 5/9/06, Giovanni Bajo <[EMAIL PROTECTED]> wrote:
> ??? Events, slots and signals are all public parts of a GUI API.
They happen to be public parts of many existing GUI APIs.
This does not mean that they need to be exposed unchanged as part of
the default python UI API. I know that there are
On 5/8/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
> While we're on the subject, something that causes me
> intense annoyance from time to time is when I get a
> message like "Method foobar expects m args, got n",
> but it doesn't tell me *which* of the myriad foobar
> methods in my program it was tr
i think it's only Bill who said that, but i wanted to show why interfaces
(and inheritance) shouldn't be the basis for type-checking.
here's a nice interface:
class IFile(object):
def write(self, data):
pass
def read(self, count):
pass
and here's a class that "implements/
"tomer filiba" <[EMAIL PROTECTED]> writes:
> one thing that worries me with generic methods is, they would
> dispatch based on types... which means my proxies would all break.
> please, think of the proxies! ;)
OTOH proxies generated by my Python<->Kogut bridge would break if
hasattr was used to
Greg Ewing wrote:
> Travis E. Oliphant wrote:
>> Just get a
>> window-area from each platform's lowest-level tool and then draw your
>> widgets to the screen directly.
>
> But then you have something that looks totally non-native
> on all platforms. While it may be useful to have such a thing,
>
I'm sorry if this has been discussed before.
One of the things that is really nice about slice syntax is the ability
to construct slice objects to pass to __getitem__ using []
Would it be possible to extend the syntax so that slice syntax is
acceptable in more places in Python? In particular
On 5/10/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> Many people (including Guido, IIRC) have pointed out the severe limitations
> of your proposal, but you keep ignoring them. As far as I can tell, it is
> you who has proposed to break Python's type system by eliminating
> attribute-based duck
Travis E. Oliphant wrote:
> Greg Ewing wrote:
>
>>Travis E. Oliphant wrote:
>>
>>>Just get a
>>>window-area from each platform's lowest-level tool and then draw your
>>>widgets to the screen directly.
>>
>>But then you have something that looks totally non-native
>>on all platforms. While it may
"Giovanni Bajo" <[EMAIL PROTECTED]> wrote:
> Show me a combo-box with selects among items with both text and a
> bitmap, done with wxPython, on all platforms.
How about I describe how one can make it happen?
There was a somewhat recent post in wxpython-users which offered a
reimplementation of w
Josiah Carlson wrote:
>> Show me a combo-box with selects among items with both text and a
>> bitmap, done with wxPython, on all platforms.
>
> How about I describe how one can make it happen?
>
> There was a somewhat recent post in wxpython-users which offered a
> reimplementation of wx.PopupWind
Guido writes:
> The crux of the matter seems to be how to add behavior *after* you
> already have an instance of a class -- or, equivalently (?), how to
> add behavior to a class when you have no control over the code that
> creates instances of it.
I have no contribution to make about either of t
On 5/10/06, Bill Janssen <[EMAIL PROTECTED]> wrote:
> Guido writes:
> > The crux of the matter seems to be how to add behavior *after* you
> > already have an instance of a class -- or, equivalently (?), how to
> > add behavior to a class when you have no control over the code that
> > creates inst
Paul Moore gmail.com> writes:
> On 5/7/06, Greg Wilson cs.utoronto.ca> wrote:
> > > From: Greg Ewing canterbury.ac.nz>
> > > 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
Giovanni Bajo wrote:
> Then, I'd like to have a name for 1,0,-1 instead of using the bare numbers (in
> case there are 4 buttons...).
There aren't any standard dialogs in PyGUI with 4 buttons,
so that problem doesn't arise. :-)
I could provide some names, Yes = 1, No = 0, etc. But
since you can
Giovanni Bajo wrote:
> And how do you enable two controls when a checkbox is pressed?
In Gtk you'd have to write either one handler to enable
both controls, or two handlers to enable one control
each, and connect them to the signal. There's actually
*more* code to write in the multiple-handler ca
Guido van Rossum wrote:
> Would it be okay to list the filename and line no instead of the
> class? That information is readily available from the code object.
Yes, that would be fine.
> (I'm assuming you're talking about Python functions/methods, not C
> ones --
Mainly, yes.
> for those, teh
Talin wrote:
> So my thought is this: How hard would it be to make
> a curses-based debugger?
The curses module isn't available on windows. But if anyone wants to
make a better debugger for python, it would certainly make me happy. :)
-Edward
___
Pyth
Travis E. Oliphant wrote:
> The only thing I would wish different is to get rid of the PyGTK
> dependency. I think PyGUI should be a wrapper directly on top of GNOME
Perhaps you have Gnome and Gtk confused? Gnome is the
desktop, Gtk is the UI library that Gnome applications
use.
> In short, I
Edward Loper <[EMAIL PROTECTED]> wrote:
>
> Talin wrote:
> > So my thought is this: How hard would it be to make
> > a curses-based debugger?
>
> The curses module isn't available on windows. But if anyone wants to
> make a better debugger for python, it would certainly make me happy. :)
I he
"Travis E. Oliphant" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Not much different at all except in breadth. I like the idea of PyGUI
> (it doesn't cover all backends, yet though). Sorry I wasn't more
> clear. The only thing I would wish different is to get rid of the PyGTK
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
On 5/10/06, tomer filiba <[EMAIL PROTECTED]> wrote:
> i think it's only Bill who said that, but i wanted to show why interfaces
> (and inheritance) shouldn't be the basis for type-checking.
>
> here's a nice interface:
>
> class IFile(object):
> def write(self, data):
> pass
> def r
The problem is that it's a slippery slope. I think Paul Dubois once
proposed this too, but not much came of it. Once you can write
foo(1:10), why not x = (1:10); and then why not x = 1:10. But you
can't have "if x == 1:10: ..." because the first colon would be
ambiguous. So you'd end up with even m
Talin <[EMAIL PROTECTED]> wrote:
> I don't think we really need an IDE, but a debugger that is
> at least able to show source code, call stack, and local
> variables in a window would be extremely useful.
>
> So my thought is this: How hard would it be to make
> a curses-based debugger?
For
I haven't been able to find any mention of these things in the
python-3000 archive (nor in Bill Birch's proto-PEP on the subject
[1]). These are all issues I've encountered while writing my typecheck
package [2], which I think still need to be discussed and addressed
for py3k's proposed type annota
[Michael Chermside]
> > I think the idea of creating a new language with some of the wonderful
> > syntax of Python along with the wonderful type system of Haskell sounds
> > GREAT! I would be very interested, and would like to join in the
> > discussion.
> >
> > But I don't think it belongs in the
"Guido van Rossum" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> You seem to be still under the influence of the type-safety mafia, who
> want to make you believe that with enough type-checking you can
> prevent all bugs (though they don't believe it themselves).
>
> Python alread
Travis E. Oliphant wrote:
> In short, I don't like the chaining effect of wrapper on top of wrapper.
> I want to make the connection to platform libraries as simple as
> possible. Ultimately, I also think PyGUI should provide a simple
> look-and-feel of its own as well for situations where t
On 5/10/06, Collin Winter <[EMAIL PROTECTED]> wrote:
> I haven't been able to find any mention of these things in the
> python-3000 archive (nor in Bill Birch's proto-PEP on the subject
> [1]). These are all issues I've encountered while writing my typecheck
> package [2], which I think still need
On 5/10/06, Edward C. Jones <[EMAIL PROTECTED]> wrote:
> Talin <[EMAIL PROTECTED]> wrote:
> > I don't think we really need an IDE, but a debugger that is
> > at least able to show source code, call stack, and local
> > variables in a window would be extremely useful.
> >
> > So my thought is t
On 5/10/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>
> Regarding the question what to do if something un-annotated is passed,
> you could have a strict and a lenient mode, sort of the equivalents of
> guilty-unless-proven-innocent and innocent-unless-proven-guilty. I
> guess the latter is more
Guido van Rossum wrote:
> [Talin]
>
>> Ordinarily I would agree with you on this point, and in fact I
>> wouldn't even bring it up at all, except for two data points:
>>
>> 1) The proposal to include generic function dispatch
>>in Python 3000, based on explicit typing.
>>
>> 2) The proposal to
Guido van Rossum wrote:
> I think it would be useful to have a notation that can express
> signatures. I haven't spent much time thinking about what this would
> look like, but I'd like it to require no new syntax beyond the concept
> of type annotations. If this means you can't have the inline
> e
"Giovanni Bajo" <[EMAIL PROTECTED]> wrote:
> It's sufficient to show that a library that uses native widget has to go
> through many hoops to implement any slightly non-standard feature. And
> causes the mental overhead which makes it unpythonic.
I would disagree.
The fact that it can be done, i
Josiah Carlson wrote:
> Having identical behavior on all platforms is wonderful, I'm very happy
> for you and everyone else with a toolkit (programming language, etc.) that
> does the same. For the rest of us who cannot use PyQt for one reason or
> another (licensing...), we must rely on non-Qt too
54 matches
Mail list logo
