On 06/02/2008, Christian Heimes <[EMAIL PROTECTED]> wrote:
> Nice, it's an elegant and easy solution to the problem. I like to get a
> quite similar solution into the core but I propose a slightly different
> path.
>
> Like your launcher.c, spam.exe looks for spam.py. It additionally looks
> for sp
Paul Moore wrote:
> On Windows, GUI vs Console is a property of the EXE file,
> and the differing behaviour is built into the OS loader.
Would it be feasible for it to always start up as a gui
app, and then create its own console window (a fake one
if necessary) if it decides it needs one?
Doing
Raymond Hettinger wrote:
>>I think the Zope/Twisted interfaces have gone here before.
>>I believe they have a separate validation call which is
>>typically only invoked in unittests.
>
> +1 That seems like a good idea.
Or maybe this is a task for pylint?
--
Greg
___
On Feb 7, 2008, at 11:27 AM, Christian Heimes wrote:
> You are correct. Normally interfaces are only validated in unit tests.
> The validation function of zope.interface checks if a class implements
> or object provides the promised methods and attributes. It also
> compares
> the method signatur
Raymond Hettinger rcn.com> writes:
>
> [Fred Drake]
> > I'd be happy seeing these methods added to tuple; there's
> > no reason that they would only be useful on mutable sequences.
>
Note that adding index and count to tuple will conflict with using these
names as attributes in classes generat
On Feb 7, 2008, at 3:34 PM, Greg Ewing wrote:
> Or maybe this is a task for pylint?
Maybe a lint tool could help, but it's not unusual for this to be
relevant only for specific instances, not necessarily all instances.
Certainly with zope.interface, you can create objects that provide a
pa
Guido van Rossum wrote:
> I think the Zope/Twisted interfaces have gone here before. I believe
> they have a separate validation call which is typically only invoked
> in unittests. The validation can be pretty expensive, so running the
> validation each time the interpreter is started would just s
At 09:52 AM 2/8/2008 +1300, Greg Ewing wrote:
>Would it be feasible for it to always start up as a gui
>app, and then create its own console window (a fake one
>if necessary) if it decides it needs one?
No, because that would make it impossible to write a sane
command-line app. Imagine if runnin
On 07/02/2008, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 09:52 AM 2/8/2008 +1300, Greg Ewing wrote:
> >Would it be feasible for it to always start up as a gui
> >app, and then create its own console window (a fake one
> >if necessary) if it decides it needs one?
>
> No, because that would make
Paul Moore wrote:
> As Phillip says. Windows console and GUI executables are completely
> different in behaviour. Don't try to fight it. You need two distinct
> EXEs.
Hmmm. So maybe what's needed is a *third* kind of exe that
gets launched when you double-click a .py file, that keeps
its console o
On Feb 7, 2008 8:59 PM, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Paul Moore wrote:
> > As Phillip says. Windows console and GUI executables are completely
> > different in behaviour. Don't try to fight it. You need two distinct
> > EXEs.
>
> Hmmm. So maybe what's needed is a *third* kind of exe tha
At 03:59 PM 2/8/2008 +1300, Greg Ewing wrote:
>Paul Moore wrote:
> > As Phillip says. Windows console and GUI executables are completely
> > different in behaviour. Don't try to fight it. You need two distinct
> > EXEs.
>
>Hmmm. So maybe what's needed is a *third* kind of exe that
>gets launched wh
12 matches
Mail list logo
