wxFrame -> wx.Frame summary?

[David_C_Fox2]

I'm getting a bit lost in this discussion. I'm going to try to summarize what I think is the consensus so far, particularly with respect to backward compatability. If I get any of these points wrong, could Patrick or Robin (but not dozens of other people) correct me?

1. There will be a new module called in which Frame will be the same as what is now called wxFrame in the wxPython.wx module, etc.

2. The new module will be simply wx (as opposed to wxPython.wx which is the wx module in the wxPython package), so that you can say

     import wx
     class MyFrame(wx.Frame):

instead of

     from wxPython import wx
     class MyFrame(wx.wxFrame):

which is awkward, or

     from wxPython.wx import *
     class MyFrame(wxFrame):

which pollutes the global namespace of the importing module.

3. The EVT_XXX functions will remain all-caps for consistency with the corresponding preprocessor macros in wxWindows.

4. wxPython.wx will still exist for a significant period of time (perhaps even indefinitely), so that old code still works.

5. The exact implementation of the new wx module is still under discussion.

David

[Robin]

David C. Fox wrote:

I'm getting a bit lost in this discussion. I'm going to try to summarize what I think is the consensus so far, particularly with respect to backward compatability. If I get any of these points wrong, could Patrick or Robin (but not dozens of other people) correct me?

1. There will be a new module called in which Frame will be the same as what is now called wxFrame in the wxPython.wx module, etc.

2. The new module will be simply wx (as opposed to wxPython.wx which is the wx module in the wxPython package), so that you can say

    import wx
    class MyFrame(wx.Frame):

instead of

    from wxPython import wx
    class MyFrame(wx.wxFrame):

which is awkward, or

    from wxPython.wx import *
    class MyFrame(wxFrame):

which pollutes the global namespace of the importing module.

3. The EVT_XXX functions will remain all-caps for consistency with the corresponding preprocessor macros in wxWindows.

4. wxPython.wx will still exist for a significant period of time (perhaps even indefinitely), so that old code still works.

5. The exact implementation of the new wx module is still under discussion.

Good summary.

A few issues to still be resoved:

1. Will the wx be dropped from the wxEVT_* constants?

2. Will all the constants be moved to a sub module or just the less frequently used event contstants, (and, I suppose, if they are moved will it be a different sub module or the same one?)

3. What to do about all the modules in wxPython.lib with classes and such that have a wx prefix.

4. Who's going to rewrite the demo? <wink>

···

--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!

[Anthony_Tuininga1]

4. Who's going to rewrite the demo? <wink>

Well, I could assist with that one. Of course, maybe just suggesting
this will bring someone out of the woodwork who has already done
this.... Patrick?

···

On Wed, 2003-03-05 at 13:48, Robin Dunn wrote:

--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!

---------------------------------------------------------------------
To unsubscribe, e-mail: wxPython-users-unsubscribe@lists.wxwindows.org
For additional commands, e-mail: wxPython-users-help@lists.wxwindows.org

--
Anthony Tuininga
anthony@computronix.com

Computronix
Distinctive Software. Real People.
Suite 200, 10216 - 124 Street NW
Edmonton, AB, Canada T5N 4A3
Phone: (780) 454-3700
Fax: (780) 454-3838

Home - Computronix

[Jeff_Shannon]

Robin Dunn wrote:

2. Will all the constants be moved to a sub module or just the less frequently used event contstants, (and, I suppose, if they are moved will it be a different sub module or the same one?)

I'd be somewhat in favor of having all of the constants moved to a wx.const submodule. I don't think that there's a need to have separate modules for event constants and non-event constants, but having all the constants in one submodule would go a fair way to cleaning up the main wx namespace in a logical way.

Further along those lines, would special objects like wxDefaultSize and wxDefaultPosition belong in a const submodule or in the main wx module?

3. What to do about all the modules in wxPython.lib with classes and such that have a wx prefix.

I think it'd be good to see them lose the prefix as well, but I'm hesitant to mandate lots of (more) work for other people. Jeff Shannon
Technician/Programmer
Credit International

[Patrick_K_O_Brien]

Anthony Tuininga <anthony@computronix.com> writes:

···

On Wed, 2003-03-05 at 13:48, Robin Dunn wrote:
> 4. Who's going to rewrite the demo? <wink>

Well, I could assist with that one. Of course, maybe just suggesting
this will bring someone out of the woodwork who has already done
this.... Patrick?

Feel free to pitch in. I had no plans to convert the demo, but it
would be very good to do so. But let's make sure we are all on board
with the changes before we tackle that. I've got some smaller samples
I'm testing. And I'll want to convert PyCrust at some point.

--
Patrick K. O'Brien
Orbtech http://www.orbtech.com/web/pobrien
-----------------------------------------------
"Your source for Python programming expertise."
-----------------------------------------------

[Mike_C_Fletcher2]

Jeff Shannon wrote:

Robin Dunn wrote:

2. Will all the constants be moved to a sub module or just the less frequently used event contstants, (and, I suppose, if they are moved will it be a different sub module or the same one?)

I'd be somewhat in favor of having all of the constants moved to a wx.const submodule. I don't think that there's a need to have separate modules for event constants and non-event constants, but having all the constants in one submodule would go a fair way to cleaning up the main wx namespace in a logical way.

Further along those lines, would special objects like wxDefaultSize and wxDefaultPosition belong in a const submodule or in the main wx module?

I'd pretty strongly suggest that constants should be kept in the wx namespace wherever possible, otherwise every single file is going to have to import const and use it throughout (wxPython is littered with constants). May as well just keep the namespace together.

Put all constants into their own module:

    extra import +
    sizer.Add( win, 1, const.EXPAND | const.LEFT | const.RIGHT | const.TOP, 3 )
vs
    sizer.Add( win, 1, wx.EXPAND | wx.LEFT | wx.RIGHT | wx.TOP, 3 )

The conflicting names are not, AFAIK, commonly used ones, they're things like the integer constants for eventIDs, which almost no-one on the Python side uses. If you need to put something like those in a sub-module, that's fine (though I'd prefer not), but let's not make transition between the two versions too horrifically messy.

3. What to do about all the modules in wxPython.lib with classes and such that have a wx prefix.

I think it'd be good to see them lose the prefix as well, but I'm hesitant to mandate lots of (more) work for other people. Jeff Shannon
Technician/Programmer
Credit International

There is going to be a lot of work regardless . If the lib classes are considered part of wxPython, then they should be following the same naming rules so that users don't need to guess what language each class is implemented in just to guess it's name.

Okay, enough thinking about this stuff, I have work to do,
Mike

[Patrick_K_O_Brien]

"Jeff Shannon" <jeff@ccvcorp.com> writes:

Robin Dunn wrote:
>
> 2. Will all the constants be moved to a sub module or just the less
> frequently used event contstants, (and, I suppose, if they are moved
> will it be a different sub module or the same one?)

I'd be somewhat in favor of having all of the constants moved to a
wx.const submodule. I don't think that there's a need to have
separate modules for event constants and non-event constants, but
having all the constants in one submodule would go a fair way to
cleaning up the main wx namespace in a logical way.

I agree that some submodule should be plenty. Right now I've got them
all going into a wx.const submodule, and I'm not thrilled with the
semantics. Here is an example:

import wx
import wx.const

class Frame(wx.Frame):
    """Frame class."""

    def __init__(self, parent=None, id=-1, title="Frame Title",
                 pos=wx.DefaultPosition, size=wx.DefaultSize):
        """Create a Frame instance."""
        wx.Frame.__init__(self, parent, id, title, pos, size)
        choices = ['One', 'Two', 'Buckle my shoe', 'Three', 'Four']
        style = wx.const.CB_DROPDOWN | wx.const.CB_READONLY | wx.const.CB_SORT
        self.combo = wx.ComboBox(parent=self, id=-1,
                                 choices=choices, style=style)

I don't like how much typing is required to use the constants. Here
are some alternatives:

import wx.const as const # still a bit long

import wx.const as wxc # why should you have to rename it?

from wx import wxc # too similar and will be confusing?

I'm not wild about any of these alternatives. Can anyone think of
something better?

···

--
Patrick K. O'Brien
Orbtech http://www.orbtech.com/web/pobrien
-----------------------------------------------
"Your source for Python programming expertise."
-----------------------------------------------

[Tim_Hochberg1]

Patrick K. O'Brien wrote:

"Jeff Shannon" <jeff@ccvcorp.com> writes:

Robin Dunn wrote:
   

2. Will all the constants be moved to a sub module or just the less
frequently used event contstants, (and, I suppose, if they are moved
will it be a different sub module or the same one?)
     

I'd be somewhat in favor of having all of the constants moved to a
wx.const submodule. I don't think that there's a need to have
separate modules for event constants and non-event constants, but
having all the constants in one submodule would go a fair way to
cleaning up the main wx namespace in a logical way.
   
I agree that some submodule should be plenty. Right now I've got them
all going into a wx.const submodule, and I'm not thrilled with the
semantics. Here is an example:

import wx
import wx.const

class Frame(wx.Frame):
   """Frame class."""

   def __init__(self, parent=None, id=-1, title="Frame Title",
                pos=wx.DefaultPosition, size=wx.DefaultSize):
       """Create a Frame instance."""
       wx.Frame.__init__(self, parent, id, title, pos, size)
       choices = ['One', 'Two', 'Buckle my shoe', 'Three', 'Four']
       style = wx.const.CB_DROPDOWN | wx.const.CB_READONLY | wx.const.CB_SORT
       self.combo = wx.ComboBox(parent=self, id=-1,
                                choices=choices, style=style)

I don't like how much typing is required to use the constants. Here
are some alternatives:

import wx.const as const # still a bit long

import wx.const as wxc # why should you have to rename it?

from wx import wxc # too similar and will be confusing?

I'm not wild about any of these alternatives. Can anyone think of
something better?

This is a little out there, but an idea I just had would be to leave the common, nonconflicting names in the wx namespace (with their leading wx stripped off) and attach the remaining names to appropriate class objects. So, instead of:

   wx.wxCURSOR_BULLSEYE
   wx.wxBITMAP_TYPE_XPM_DATA
   wx.wxEVT_SCROLL_PAGEDOWN

we would have:

   wx.Cursor.BULLSEYE
   wx.Bitmap.TYPE_XPM_DATA
   wx.Event.SCROLL_PAGEDOWN

etc.

I like the look of this a lot, and it would do a lot to reduce the namespace clutter. I don't know if there are appropriate classes to attach everything to though.

-tim

[Robin]

Anthony Tuininga wrote:

4. Who's going to rewrite the demo? <wink>

Well, I could assist with that one.

If you (or somebody) does there are a few other things that should probably be done to help modernize it since a number of the samples really show their age.

1. Usage of wxSize and wxPoint should be dropped and just use a tuple instead.

2. Samples still using absolute positioning should be changed to use sizers.

3. Everything should get overview text, or be updated to be more meaningful. Many are still empty, and many are still just a copy/paste from the C++ docs.

4. More inline comments describing what is being done and why.

5. etc.

Sheesh! With that list I guess it'll probably be something I have to do myself...

···

On Wed, 2003-03-05 at 13:48, Robin Dunn wrote:

--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!

[Robin]

Jeff Shannon wrote:

Further along those lines, would special objects like wxDefaultSize and wxDefaultPosition belong in a const submodule or in the main wx module?

Good question...

3. What to do about all the modules in wxPython.lib with classes and such that have a wx prefix.

I think it'd be good to see them lose the prefix as well, but I'm hesitant to mandate lots of (more) work for other people.

Yes, but how to do the transition?

···

--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!

[Robin]

Patrick K. O'Brien wrote:

I'm not wild about any of these alternatives. Can anyone think of
something better?

Other than leaving non-wxEVT contsants in wx? No.

···

--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!

[Robin]

Tim Hochberg wrote:

This is a little out there,

Yes.

but an idea I just had would be to leave the common, nonconflicting names in the wx namespace (with their leading wx stripped off) and attach the remaining names to appropriate class objects. So, instead of:

  wx.wxCURSOR_BULLSEYE
  wx.wxBITMAP_TYPE_XPM_DATA
  wx.wxEVT_SCROLL_PAGEDOWN

we would have:

  wx.Cursor.BULLSEYE
  wx.Bitmap.TYPE_XPM_DATA
  wx.Event.SCROLL_PAGEDOWN

etc.

I like the look of this a lot, and it would do a lot to reduce the namespace clutter. I don't know if there are appropriate classes to attach everything to though.

Probably not, and there are several constants that are used a few different types of places...

···

--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!

[Alberto_Griggio2]

I'd pretty strongly suggest that constants should be kept in the wx
namespace wherever possible, otherwise every single file is going to
have to import const and use it throughout (wxPython is littered with
constants). May as well just keep the namespace together.

[...]

The conflicting names are not, AFAIK, commonly used ones, they're things
like the integer constants for eventIDs, which almost no-one on the
Python side uses. If you need to put something like those in a
sub-module, that's fine (though I'd prefer not), but let's not make
transition between the two versions too horrifically messy.

I agree with this.

There is going to be a lot of work regardless . If the lib classes
are considered part of wxPython, then they should be following the same
naming rules so that users don't need to guess what language each class
is implemented in just to guess it's name.

And with this too

Okay, enough thinking about this stuff, I have work to do,
Mike

And I have to sleep...
Alberto

[Patrick_K_O_Brien]

"Jeff Shannon" <jeff@ccvcorp.com> writes:

Further along those lines, would special objects like wxDefaultSize
and wxDefaultPosition belong in a const submodule or in the main wx
module?

In the current implementation they are still in the main wx namespace,
and I don't think they should move. They just loose the "wx" prefix.

···

--
Patrick K. O'Brien
Orbtech http://www.orbtech.com/web/pobrien
-----------------------------------------------
"Your source for Python programming expertise."
-----------------------------------------------

[Patrick_K_O_Brien]

pobrien@orbtech.com (Patrick K. O'Brien) writes:

I agree that some submodule should be plenty. Right now I've got them

               ^ one submodule

···

--
Patrick K. O'Brien
Orbtech http://www.orbtech.com/web/pobrien
-----------------------------------------------
"Your source for Python programming expertise."
-----------------------------------------------

[Patrick_K_O_Brien]

Robin Dunn <robin@alldunn.com> writes:

Patrick K. O'Brien wrote:
> I'm not wild about any of these alternatives. Can anyone think of
> something better?

Other than leaving non-wxEVT contsants in wx? No.

Then does it even make sense to move those? The event functions, which
do get used a lot, don't have a wx prefix as it is. So the only
benefit we gain is moving a few constants (176 out of 1428) out of the
wx namespace, and the ability to drop their wx prefix. It's starting
to sound like a dud to me. Unfortunately, however, the wx namespace
isn't getting any smaller.

···

--
Patrick K. O'Brien
Orbtech http://www.orbtech.com/web/pobrien
-----------------------------------------------
"Your source for Python programming expertise."
-----------------------------------------------

[Patrick_K_O_Brien]

Robin Dunn <robin@alldunn.com> writes:

>> 3. What to do about all the modules in wxPython.lib with classes
>> and such that have a wx prefix.
> I think it'd be good to see them lose the prefix as well, but I'm
> hesitant to mandate lots of (more) work for other people.

Yes, but how to do the transition?

These are handled the same as any other wxPython module. I've already
implemented this and posted a message with details.

···

--
Patrick K. O'Brien
Orbtech http://www.orbtech.com/web/pobrien
-----------------------------------------------
"Your source for Python programming expertise."
-----------------------------------------------

[Patrick_K_O_Brien]

Robin Dunn <robin@alldunn.com> writes:

Anthony Tuininga wrote:
>
>>4. Who's going to rewrite the demo? <wink>
> Well, I could assist with that one.

[todo list snipped]

Sheesh! With that list I guess it'll probably be something I have to
do myself...

I disagree. If anything could be delegated it is this. You've got more
important concerns. The community needs to pitch in and help, and
working on the demo would be a really good thing.

···

> On Wed, 2003-03-05 at 13:48, Robin Dunn wrote:

--
Patrick K. O'Brien
Orbtech http://www.orbtech.com/web/pobrien
-----------------------------------------------
"Your source for Python programming expertise."
-----------------------------------------------

[Anthony_Tuininga1]

#1 could definitely be done without having to understand the code very
much. The others, though, would take considerable more effort. I could
do the name changes and #1 though and then pass off the result to you
for doing #2-5. Let me know when (or if) you would like help.

···

On Wed, 2003-03-05 at 15:33, Robin Dunn wrote:

Anthony Tuininga wrote:
> On Wed, 2003-03-05 at 13:48, Robin Dunn wrote:
>
>>4. Who's going to rewrite the demo? <wink>
>
>
> Well, I could assist with that one.

If you (or somebody) does there are a few other things that should
probably be done to help modernize it since a number of the samples
really show their age.

1. Usage of wxSize and wxPoint should be dropped and just use a tuple
instead.

2. Samples still using absolute positioning should be changed to use sizers.

3. Everything should get overview text, or be updated to be more
meaningful. Many are still empty, and many are still just a copy/paste
from the C++ docs.

4. More inline comments describing what is being done and why.

5. etc.

Sheesh! With that list I guess it'll probably be something I have to do
myself...

--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!

---------------------------------------------------------------------
To unsubscribe, e-mail: wxPython-users-unsubscribe@lists.wxwindows.org
For additional commands, e-mail: wxPython-users-help@lists.wxwindows.org

--
Anthony Tuininga
anthony@computronix.com

Computronix
Distinctive Software. Real People.
Suite 200, 10216 - 124 Street NW
Edmonton, AB, Canada T5N 4A3
Phone: (780) 454-3700
Fax: (780) 454-3838

Home - Computronix

[Jeff_Shannon]

Robin Dunn wrote:

Tim Hochberg wrote:

This is a little out there, [...]

we would have:

  wx.Cursor.BULLSEYE
  wx.Bitmap.TYPE_XPM_DATA
  wx.Event.SCROLL_PAGEDOWN

etc.

I like the look of this a lot, and it would do a lot to reduce the namespace clutter. I don't know if there are appropriate classes to attach everything to though.

Probably not, and there are several constants that are used a few different types of places...

In particular, there's constants like wxVERTICAL and wxCENTRE that don't belong with any class, but are used in quite a few places.

If we were desigining a purely Python library from scratch, it might make sense to use class attributes as much as possible, but we're not, and maintaining parallels with the C++ base is very important. To my mind, this gets too far away from wxWindows to be a good idea.

I personally don't see a big problem with using, say,

    from wx import const
    style = const.CB_DROPDOWN | const.CB_READONLY | const.CB_SORT

as opposed to

    style = wx.CB_DROPDOWN | wx.CB_READONLY | wx.CB_SORT

but I don't have a particular strong feeling either way. Using a const module does let us clean up the wx namespace, though, and it seems to me that if, at some time in the future, we're going to split the namespace into multiple chunks anyhow, all the disadvantages of this will apply equally to any new submodules (i.e., we'll be dealing with it anyhow), and this is a logical and (relatively) easy first step down that road.

Jeff Shannon
Technician/Programmer
Credit International