analysis of constants for wx namespace reorganization

The large quantity of wxPython constants are an obvious place to look
in considering breaking up the wx namespace. And a lot of the
constants have prefixes, making them logical candidates for a separate
namespace (with the potential to drop the prefix as well). So I did an
analysis and got the following results (the code is included
below). This list shows a count of any prefix having more than 9
occurences:

    231 LANGUAGE
    103 WXK
    90 SYS
    67 PAPER
    57 ID
    48 FONTENCODING
    44 LIST
    37 ART
    33 BITMAP
    30 CURSOR
    20 LC
    20 DF
    18 TE
    16 TR
    16 HT
    14 TREE
    12 SP
    10 SL
    10 MM
    10 LOG
    10 ALIGN

The first three seem like easy candidates for separate submodules,
perhaps lang, key, and sys. If we did move them, would we also want to
strip off their prefixes? The results would look like this:

lang.ABKHAZIAN
lang.AFAR
lang.AFRIKAANS
lang.ALBANIAN
...
key.ADD
key.ALT
key.BACK
key.CANCEL
...
sys.ANSI_FIXED_FONT
sys.ANSI_VAR_FONT
sys.BORDER_X
sys.BORDER_Y
...

Like everything in life, there are some issues with this approach that
need resolving, and questions that need answering:

* If we don't strip off the prefix, we get ugly redundant stuff like:

    lang.LANGUAGE_ABKHAZIAN

    key.WXK_ADD

* ``key`` is a common variable name in key handlers, but you could do:

    if key == wx.key.ADD: ...

* ``sys`` is in the Python library, but you could do:

    import sys
    import wx
    import wx.sys

    wx.sys.BORDER_X

* where do we draw the line? Do we move PAPER, ID, FONTENCODING? Or do
  we not move anything, and leave them all in one constants module?

* what about constants defined in other modules, like stc, html, etc?

···

----

Here is the code that generated the counts. Note that I have the
constants all going into a "con" module at the moment:

    >>> import wx
    >>> len(dir(wx))
    821
    >>> from wx import con
    >>> len(dir(con))
    1407
    >>> d = {}
    >>> for item in dir(con):
    ... l = item.split('_')
    ... if len(l) > 1:
    ... pre = l[0]
    ... d[pre] = d.get(pre, 0) + 1
    ...
    >>> l = [(value, key) for key, value in d.items()]
    >>> l.sort()
    >>> l.reverse()
    >>> for item in l:
    ... if item[0] > 9:
    ... print item[0], item[1]
    ...

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

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

Here is the code that generated the counts. Note that I have the
constants all going into a "con" module at the moment:

I forgot to mention that I'm already moving the wxEVT constants into
an evt module, based on previous discussions on how infrequently these
are needed. (Note that these will still have the wx prefix on them as
well.)

    >>> from wx import evt
    >>> len(dir(evt))
    183
    >>> evt.wxEVT_ACTIVATE
    10107

···

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

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

Here is the code that generated the counts. Note that I have the
constants all going into a "con" module at the moment:

    >>> import wx
    >>> len(dir(wx))
    821

That's a bit misleading because I was moving the Ptr classes to a
separate namespace, but that's an issue that Robin and others need to
render an opinion on. Moving them dynamically is easy; moving them in
the source code is probably hard. So the real wxPython.wx namespace
that we draw from won't get any smaller if these can't be moved. And,
some tools, like PythonCard, are doing isinstance() tests against the
Ptr classes and might not like to see the Ptr classes moved out of the
main wx namespace. Then again, moving them does help the clutter
problem:

    >>> from wx import ptr
    >>> len(dir(ptr))
    276

···

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

Patrick K. O'Brien wrote:

The large quantity of wxPython constants are an obvious place to look
in considering breaking up the wx namespace. And a lot of the
constants have prefixes, making them logical candidates for a separate
namespace (with the potential to drop the prefix as well). So I did an
analysis and got the following results (the code is included
below). This list shows a count of any prefix having more than 9
occurences:

   231 LANGUAGE
   103 WXK
   90 SYS
   67 PAPER
   57 ID
   48 FONTENCODING

A possibility with FONT would be to split FONTENCODING, FONTSTYLE, FONTWEIGHT and FONTFAMILY into a font module. Leading to code that looks like:

font.ENCODING_CP1251, font.STYLE_ITALIC, etc.

The counts for the prefixes other than FONTENCODING are small, but it seems that they should go together. This would raise the total size of a font module to 67 items.

   44 LIST
   37 ART
   33 BITMAP
   30 CURSOR
   20 LC
   20 DF
   18 TE
   16 TR
   16 HT
   14 TREE
   12 SP
   10 SL
   10 MM
   10 LOG
   10 ALIGN

The first three seem like easy candidates for separate submodules,
perhaps lang, key, and sys. If we did move them, would we also want to
strip off their prefixes? The results would look like this:

lang.ABKHAZIAN
lang.AFAR
lang.AFRIKAANS
lang.ALBANIAN
...
key.ADD
key.ALT
key.BACK
key.CANCEL
...
sys.ANSI_FIXED_FONT
sys.ANSI_VAR_FONT
sys.BORDER_X
sys.BORDER_Y
...

Like everything in life, there are some issues with this approach that
need resolving, and questions that need answering:

* If we don't strip off the prefix, we get ugly redundant stuff like:

   lang.LANGUAGE_ABKHAZIAN

   key.WXK_ADD

I'd be inclined to strip the constants.

* ``key`` is a common variable name in key handlers, but you could do:

   if key == wx.key.ADD: ...

I'm a little uncomfortable with naming these things key, lang, etc. when only the constants, not the functions associated with them are going in these submodules. However, calling them "keyconst" or something similar instead seems pretty akward. Another option would be to make them submodules of const, not of wx, so the above would look like:

  if key == const.key.ADD: ....

I'm not sure that's an improvement, but something to think about.

* ``sys`` is in the Python library, but you could do:

   import sys
   import wx
   import wx.sys

   wx.sys.BORDER_X

Assuming other people use the SYS_ constants as much as I do (never?), I don't think this would be much of a hardship.

* where do we draw the line? Do we move PAPER, ID, FONTENCODING? Or do
we not move anything, and leave them all in one constants module?

I'd move everything down through Cursor.

* what about constants defined in other modules, like stc, html, etc?

I think these can wait.

-tim

···

----

Here is the code that generated the counts. Note that I have the
constants all going into a "con" module at the moment:

   >>> import wx
   >>> len(dir(wx))
   821
   >>> from wx import con
   >>> len(dir(con))
   1407
   >>> d = {}
   >>> for item in dir(con):
   ... l = item.split('_')
   ... if len(l) > 1:
   ... pre = l[0]
   ... d[pre] = d.get(pre, 0) + 1
   ... >>> l = [(value, key) for key, value in d.items()]
   >>> l.sort()
   >>> l.reverse()
   >>> for item in l:
   ... if item[0] > 9:
   ... print item[0], item[1]
   ...

Patrick K. O'Brien wrote:

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

Here is the code that generated the counts. Note that I have the
constants all going into a "con" module at the moment:
   
I forgot to mention that I'm already moving the wxEVT constants into
an evt module, based on previous discussions on how infrequently these
are needed. (Note that these will still have the wx prefix on them as
well.)

Is this something Robin pronounced on, or did he only pronounce on the EVT_ macros? If he didn't pronounce on this I'd think that these should follow whatever format the other constants end up using.

-tim

···

   >>> from wx import evt
   >>> len(dir(evt))
   183
   >>> evt.wxEVT_ACTIVATE
   10107
   >>>

Tim Hochberg <tim.hochberg@ieee.org> writes:

Patrick K. O'Brien wrote:

>I forgot to mention that I'm already moving the wxEVT constants into
>an evt module, based on previous discussions on how infrequently these
>are needed. (Note that these will still have the wx prefix on them as
>well.)
>
Is this something Robin pronounced on, or did he only pronounce on the
EVT_ macros? If he didn't pronounce on this I'd think that these
should follow whatever format the other constants end up using.

The decision was that EVT_ macros would remain in wx without a name
change. The wxEVT_ constants were free to move. If Robin is in favor
of dropping prefixes from constants that are moved to their own
modules, I suppose he will agree to do the same for the wxEVT_
constants, especially since they are infrequently used. The result
would be:

    wx.evt.ACTIVATE
    wx.evt.ACTIVATE_APP
    wx.evt.CALCULATE_LAYOUT
    wx.evt.CHAR
    ...

Looks good to me.

···

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

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

> Here is the code that generated the counts. Note that I have the
> constants all going into a "con" module at the moment:

I forgot to mention that I'm already moving the wxEVT constants into
an evt module, based on previous discussions on how infrequently these
are needed. (Note that these will still have the wx prefix on them as
well.)

    >>> from wx import evt
    >>> len(dir(evt))
    183
    >>> evt.wxEVT_ACTIVATE
    10107
    >>>

If you are planning to move them into a module name wx.evt, then why not
simply do

wx.evt.ACTIVATE

assuming that all of the constants have the prefix "wxEVT_". I think it
is fairly easy to translate between

wxEVT_ACTIVATE

and

wx.evt.ACTIVATE

but maybe its just me... :slight_smile:

···

On Thu, 2003-03-06 at 09:24, Patrick K. O'Brien wrote:

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

---------------------------------------------------------------------
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

That's a bit misleading because I was moving the Ptr classes to a
separate namespace, but that's an issue that Robin and others need to
render an opinion on. Moving them dynamically is easy; moving them in
the source code is probably hard. So the real wxPython.wx namespace
that we draw from won't get any smaller if these can't be moved. And,
some tools, like PythonCard, are doing isinstance() tests against the
Ptr classes and might not like to see the Ptr classes moved out of the
main wx namespace. Then again, moving them does help the clutter
problem:

I'm not very happy about moving the constants, but I definitely think
that the Ptr classes should go away from the wx namespace. IMHO they
should be just implementation details, and I consider the fact that at
the moment we have to take their existence into account for isinstance()
and the like an issue to be solved.

Now, a question: why are you talking about "Moving them dynamically"? I'm
not very convinced about generating the wx module dynamically, I think
this should be done certainly in an automated way, but only when
installing wxPython. What's the benefit of a dynamic generation?

Alberto

Anthony Tuininga <anthony@computronix.com> writes:

If you are planning to move them into a module name wx.evt, then why not
simply do

wx.evt.ACTIVATE

assuming that all of the constants have the prefix "wxEVT_". I think it
is fairly easy to translate between

wxEVT_ACTIVATE

and

wx.evt.ACTIVATE

but maybe its just me... :slight_smile:

No, that's a good point. It just depends on how Robin and others feel
about dropping the prefixes from constants that are in their own
module. (And the fact that there will be that slight inconsistency
between constants in their own modules versus constants in the
catchall "con" or "const" or whatever-the-name-will-be module.

···

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

Alberto Griggio <albgrig@tiscalinet.it> writes:

> That's a bit misleading because I was moving the Ptr classes to a
> separate namespace, but that's an issue that Robin and others need to
> render an opinion on. Moving them dynamically is easy; moving them in
> the source code is probably hard. So the real wxPython.wx namespace
> that we draw from won't get any smaller if these can't be moved. And,
> some tools, like PythonCard, are doing isinstance() tests against the
> Ptr classes and might not like to see the Ptr classes moved out of the
> main wx namespace. Then again, moving them does help the clutter
> problem:

I'm not very happy about moving the constants, but I definitely think
that the Ptr classes should go away from the wx namespace. IMHO they
should be just implementation details, and I consider the fact that at
the moment we have to take their existence into account for isinstance()
and the like an issue to be solved.

I agree.

Now, a question: why are you talking about "Moving them dynamically"? I'm
not very convinced about generating the wx module dynamically, I think
this should be done certainly in an automated way, but only when
installing wxPython. What's the benefit of a dynamic generation?

It is just a temporary approach that allows us to hash out these
issues without making any changes to wxPython. And it works now. You
can get the code for the wx package here:

Once we have agreed on the semantics, I can go back to writing the
wxPython book, using the new semantics. And I can test my code with
the new semantics using the dynamic wx namespace code that I've
written. So I'm simply scratching an itch I have right now.

Long-term the SWIG generation will have to be altered by Robin to
conform to the new naming convention while still supporting backward
compatibility. Using the dynamic approach buys us time to figure out
exactly how to make those changes.

···

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

Patrick K. O'Brien wrote:

Alberto Griggio <albgrig@tiscalinet.it> writes:

...

I'm not very happy about moving the constants, but I definitely think
that the Ptr classes should go away from the wx namespace. IMHO they
should be just implementation details, and I consider the fact that at
the moment we have to take their existence into account for isinstance()
and the like an issue to be solved.
   
I agree.

...
Ack! Guys. Please, restrain yourselves. Tackle one issue at a time. Moving the Ptr classes from the namespace will make the transition require yet one more step, and that much more testing, but won't actually eliminate the wart. The Ptr classes are used all through code that needs to check for resource/window-type to decide what to do with the window. If you move them, we have to alter all code that uses them. They may be implementation details, but they're core details at the moment.

Unless you're fixing the whole issue (i.e. eliminating the Ptr classes entirely so that pointers passed back from SWIG are full instances of the named class) please don't arbitrarily start partitioning the namespace so that we have to alter the code twice (once now, to use the 'ptr' space, once when the wart is actually fixed (to use the same class for all instances)).

Morning all,
Mike

···

_______________________________________
  Mike C. Fletcher
  Designer, VR Plumber, Coder
  http://members.rogers.com/mcfletch/

"Mike C. Fletcher" <mcfletch@rogers.com> writes:

Patrick K. O'Brien wrote:

>Alberto Griggio <albgrig@tiscalinet.it> writes:
>
...

>>I'm not very happy about moving the constants, but I definitely think
>>that the Ptr classes should go away from the wx namespace. IMHO they
>>should be just implementation details, and I consider the fact that at
>>the moment we have to take their existence into account for isinstance()
>>and the like an issue to be solved.
>>
>
>I agree.
>
...
Ack! Guys. Please, restrain yourselves. Tackle one issue at a
time. Moving the Ptr classes from the namespace will make the
transition require yet one more step, and that much more testing, but
won't actually eliminate the wart. The Ptr classes are used all
through code that needs to check for resource/window-type to decide
what to do with the window. If you move them, we have to alter all
code that uses them. They may be implementation details, but they're
core details at the moment.

<soapbox>First, I am exhibiting a lot of restraint. Nothing has been
changed yet, and all proposed changes are getting a fair hearing on
this list. Second, I'm implementing code so that all proposed changes
can get tested before any final decisions are made. Third, none of
what I am doing is "arbitrary" and I'm starting to hate that
word.</soabox>

Now that *I* feel better... :slight_smile:

Your concerns are why I'm cautious about moving Ptr classes out of the
main namespace. At the same time, I have to believe you are in the
minority of users who fiddle with this sort of thing, because you are
building low-level tools, like the PythonCard and wxGlade folks.

Unless you're fixing the whole issue (i.e. eliminating the Ptr classes
entirely so that pointers passed back from SWIG are full instances of
the named class) please don't arbitrarily start partitioning the
namespace so that we have to alter the code twice (once now, to use
the 'ptr' space, once when the wart is actually fixed (to use the same
class for all instances)).

If we want to reduce the size of the wx namespace then the 250+ Ptr
classes, that most wxPython users don't even know exist, are a prime
target. Raising the issue is valid and there's nothing arbitrary about
it. But whether it is a wise thing to do or not will need to be
decided based on feedback from power users such as yourself. That's
all I'm trying to do at this point.

Morning all,

Same to you. Thanks for letting me vent. (Like you had a choice. :wink:

···

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

Patrick K. O'Brien wrote:

The large quantity of wxPython constants are an obvious place to look
in considering breaking up the wx namespace. And a lot of the
constants have prefixes, making them logical candidates for a separate
namespace (with the potential to drop the prefix as well). So I did an
analysis and got the following results (the code is included
below). This list shows a count of any prefix having more than 9
occurences:

[...]

* where do we draw the line? Do we move PAPER, ID, FONTENCODING? Or do
  we not move anything, and leave them all in one constants module?

I'd rather see them left in a single module. The main reason for this is in looking forward to the 2nd phase of the transition I want to be able to easily generate all the new modules and names from SWIG with no runtime renaming or reorganization and hopefully without any build time post-processing. Creating a new sumbodule just for a group of constants means a whole new Python _extension_ module (that's C++ code). That seems like overkill to me. I don't mind doing it once but there are already too many extension modules in wxPython to think about doing it for each logical grouping of constants.

* what about constants defined in other modules, like stc, html, etc?

They should probably be left where they are. Those namespaces will already be relativly small, and the constants will be logically related with the classes there so it probably makes sense to leave them.

On a related note, another way to redice the size of the core namespace is to remove some classes (and any related constants) that are currently there and put them in new submodules. A few that come immediatly to mind are already in separate modules but are import-*'d into wxPython.wx. They are printfw, streams and filesys. Perhaps your renamer code could import wxPython.streams and etc. and check if the wxPython.wx names are also in those modules and if so don't add them to the new wx namespace.

···

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

Patrick K. O'Brien wrote:

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

Here is the code that generated the counts. Note that I have the
constants all going into a "con" module at the moment:

   >>> import wx
   >>> len(dir(wx))
   821

That's a bit misleading because I was moving the Ptr classes to a
separate namespace, but that's an issue that Robin and others need to
render an opinion on.

I don't think they should be moved. Not only is some code expecting to be able to use them, but I won't be able to control where they go in phase 2 anyway.

···

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

Tim Hochberg wrote:

I forgot to mention that I'm already moving the wxEVT constants into
an evt module, based on previous discussions on how infrequently these
are needed. (Note that these will still have the wx prefix on them as
well.)

Is this something Robin pronounced on, or did he only pronounce on the EVT_ macros? If he didn't pronounce on this I'd think that these should follow whatever format the other constants end up using.

I could make an argument either way so I only said to figure out which way is least confusing.

···

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

"Patrick K. O'Brien" wrote:

The large quantity of wxPython constants are an obvious place to look
in considering breaking up the wx namespace.

I'd love to see this done. Looking at the list of contstnt type, I find
that there are a huge number that I have never used, so I suggest that
even those that only have 10 or so constants could be kept separate.
This would allow us to clean up the names, an my experience is that I
would only be importing a small number of these contant modules into a
given module anyway. I'd be interested to hear if other think they'd end
up importing most of them into a single module.

* ``sys`` is in the Python library, but you could do:

or call it wxsys, even though we are trying to get rid of wx-s, not add
them!

Your concerns are why I'm cautious about moving Ptr classes out of the
main namespace. At the same time, I have to believe you are in the
minority of users who fiddle with this sort of thing, because you are
building low-level tools, like the PythonCard and wxGlade folks.

As one data point, I've never had to use them.

> namespace so that we have to alter the code twice (once now, to use
> the 'ptr' space, once when the wart is actually fixed (to use the same
> class for all instances)).

If we know for sure that the wart will be removed (killed, warts are a
virus, aren't they?), then this is a good point, and we might as well
wait till then. Otherwise, let's make it work well now, and worry about
future changes later. The same goes for wxWindows intself using
namespaces. If we know that's goin to happen (in our lifetimes) then we
should wait, but we don't know that it will.

Same to you. Thanks for letting me vent. (Like you had a choice. :wink:

I didn't have to read it. Personally, I really appreciate all the work
you are doing on this idea.

-Chris

···

--
Christopher Barker, Ph.D.
Oceanographer
                                        
NOAA/OR&R/HAZMAT (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception

Chris.Barker@noaa.gov

I second that and looking forward to the new version. Also, I'd skip the "developers" list. This is a rare event, and occasionally its interesting to hear what's going on. And it seems to be coming to a head.

Bob

···

At 11:46 AM 3/6/2003 -0800, Chris Barker: >"Patrick K. O'Brien" wrote:

> Same to you. Thanks for letting me vent. (Like you had a choice. :wink:

I didn't have to read it. Personally, I really appreciate all the work
you are doing on this idea.

Robin Dunn <robin@alldunn.com> writes:

Patrick K. O'Brien wrote:
> The large quantity of wxPython constants are an obvious place to look
> in considering breaking up the wx namespace. And a lot of the
> constants have prefixes, making them logical candidates for a separate
> namespace (with the potential to drop the prefix as well). So I did an
> analysis and got the following results (the code is included
> below). This list shows a count of any prefix having more than 9
> occurences:

[...]

> * where do we draw the line? Do we move PAPER, ID, FONTENCODING? Or
> do
> we not move anything, and leave them all in one constants module?

I'd rather see them left in a single module. The main reason for this
is in looking forward to the 2nd phase of the transition I want to be
able to easily generate all the new modules and names from SWIG with
no runtime renaming or reorganization and hopefully without any build
time post-processing. Creating a new sumbodule just for a group of
constants means a whole new Python _extension_ module (that's C++
code). That seems like overkill to me. I don't mind doing it once
but there are already too many extension modules in wxPython to think
about doing it for each logical grouping of constants.

Okay. What should we name this constants module? I think it is pretty
important to keep the name short. Here are some possibilities:

* const (a bit long when you look at real code):

    import wx
    from wx import const

    if key == const.WXK_DOWN

    if lang = const.LANGUAGE_ABKHAZIAN

    style = const.CB_DROPDOWN | const.CB_READONLY | const.CB_SORT

* con (a bit vague, but it is short)

    import wx
    from wx import con

    if key == con.WXK_DOWN

    if lang = con.LANGUAGE_ABKHAZIAN

    style = con.CB_DROPDOWN | con.CB_READONLY | con.CB_SORT

* wxcon (same length as const, but avoids having to possibly write
  wx.const):

    import wx
    from wx import wxcon

    if key == wxcon.WXK_DOWN

    if lang = wxcon.LANGUAGE_ABKHAZIAN

    style = wxcon.CB_DROPDOWN | wxcon.CB_READONLY | wxcon.CB_SORT

* wxc (too similar to wx for my liking, but I could be convinced):

    import wx
    from wx import wxc

    if key == wxc.WXK_DOWN

    if lang = wxc.LANGUAGE_ABKHAZIAN

    style = wxc.CB_DROPDOWN | wxc.CB_READONLY | wxc.CB_SORT

* WX (because we can, and it matches the idea that constants are
  usually in ALLCAPS):

    import wx
    from wx import WX

    if key == WX.WXK_DOWN

    if lang = WX.LANGUAGE_ABKHAZIAN

    style = WX.CB_DROPDOWN | WX.CB_READONLY | WX.CB_SORT

Hey! I kind of like that WX one. It doesn't break the habit of typing
"wx" and it looks right as a module for constants.

Any other suggestions?

> * what about constants defined in other modules, like stc, html, etc?

They should probably be left where they are. Those namespaces will
already be relativly small, and the constants will be logically
related with the classes there so it probably makes sense to leave
them.

I agree. Especially if we break up wx the way you describe next.

On a related note, another way to redice the size of the core
namespace is to remove some classes (and any related constants) that
are currently there and put them in new submodules. A few that come
immediatly to mind are already in separate modules but are import-*'d
into wxPython.wx. They are printfw, streams and filesys. Perhaps
your renamer code could import wxPython.streams and etc. and check if
the wxPython.wx names are also in those modules and if so don't add
them to the new wx namespace.

I'll look into this and report back.

···

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

Patrick K. O'Brien wrote:

Okay. What should we name this constants module? I think it is pretty
important to keep the name short. Here are some possibilities:

[...]

* WX (because we can, and it matches the idea that constants are
  usually in ALLCAPS):

    import wx
    from wx import WX

    if key == WX.WXK_DOWN

    if lang = WX.LANGUAGE_ABKHAZIAN

    style = WX.CB_DROPDOWN | WX.CB_READONLY | WX.CB_SORT

Hey! I kind of like that WX one. It doesn't break the habit of typing
"wx" and it looks right as a module for constants.

I like this one too.

···

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

Robin Dunn wrote:

Patrick K. O'Brien wrote:

Okay. What should we name this constants module? I think it is pretty
important to keep the name short. Here are some possibilities:

[...]

* WX (because we can, and it matches the idea that constants are
  usually in ALLCAPS):

    import wx
    from wx import WX

    if key == WX.WXK_DOWN

    if lang = WX.LANGUAGE_ABKHAZIAN

    style = WX.CB_DROPDOWN | WX.CB_READONLY | WX.CB_SORT

Hey! I kind of like that WX one. It doesn't break the habit of typing
"wx" and it looks right as a module for constants.

I like this one too.

me 3

-tim

(don't show it those on CLP who are sensitive to case sensistivity though!)