FW: going from UpperUpper to lower Uppermeth od names

wxPython Users
21

Oh well. I thought it was too good to be true. :wink:

But if the other changes are implemented it's a great
improvement IMO.

···

At 09:42 2003-03-05 -0800, Robin Dunn wrote:

Patrick K. O'Brien wrote:

Magnus Lycka <magnus@thinkware.se> writes:

In the Leibnizian best of all worlds I'd prefer
something like wx.evt.size() and wx.evt.SIZE.

I happen to like this. I like having uppercase names limited to
constants. And I think having an evt module is more Pythonic, while
still allowing us to communicate with other wxWindows developers. What
do the rest of you think? Robin?

Sorry, I can't explain it but this is something I'm not willing to budge on.

--
Magnus Lycka, Thinkware AB
Alvans vag 99, SE-907 50 UMEA, SWEDEN
phone: int+46 70 582 80 65, fax: int+46 70 612 80 65
http://www.thinkware.se/ mailto:magnus@thinkware.se

22

Patrick K. O'Brien wrote:

I happen to like this. I like having uppercase names limited to
constants. And I think having an evt module is more Pythonic, while
still allowing us to communicate with other wxWindows developers. What
do the rest of you think? Robin?

Sorry, I can't explain it but this is something I'm not willing to
budge on.

That's all I needed to hear. Case closed.

Thanks.

Next question: If we move
the wxEVT constants into a separate submodule, do we want to drop the
wx prefix, or leave it on?

Which way would cause the least confusion? On the one hand there will be some names (but not nearly all) that are the same between the two modules, and on the other you would be leaving the wx prefix on the names where you are removing them from everything else...

···

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

23

Robin Dunn wrote:

Patrick K. O'Brien wrote:

Next question: If we move
the wxEVT constants into a separate submodule, do we want to drop the
wx prefix, or leave it on?

Which way would cause the least confusion? On the one hand there will be some names (but not nearly all) that are the same between the two modules, and on the other you would be leaving the wx prefix on the names where you are removing them from everything else...

I think I'd prefer having wx.EVT_SIZE() and wx.const.EVT_SIZE, as opposed to wx.const.wxEVT_SIZE. Having names the same between two modules won't be much problem unless people do 'from wx.const import *', which we're trying to discourage anyhow. :wink: I think that the parallel between wx.const.EVT_SIZE and the C++ wxEVT_SIZE should be close enough that it won't hinder translation significantly (but then, I've never translated between wxPython and wxWindows, so I may not know what I'm talking about here).

Jeff Shannon
Technician/Programmer
Credit International

24

Robin Dunn <robin@alldunn.com> writes:

> Next question: If we move
> the wxEVT constants into a separate submodule, do we want to drop the
> wx prefix, or leave it on?

Which way would cause the least confusion? On the one hand there will
be some names (but not nearly all) that are the same between the two
modules, and on the other you would be leaving the wx prefix on the
names where you are removing them from everything else...

I don't feel too strongly either way. Here are some considerations.

Reasons to leave the wx prefix in place

···

=======================================

* We can only drop the prefix if we *do* move the constants to a
  separate namespace. Even with a separate module (const, perhaps) in
  place, doing the following would be disasterous if we dropped the
  prefix:

      from wx import *
      from wx.const import *

* Folks who mess with these constants should know what they are doing,
  and should be able to handle the "wx" prefix wart. (Sure, she's got
  a big wart on her nose. But we've known each other since we were
  babies. So be nice to her. She's like a sister to me.)

Reasons to drop the wx prefix

* If we don't do it now it will likely never happen.

* We're dropping them everywhere else, why not here? (Eventually the
  __class__.__name__ attribute will catch up and there won't be a
  prefix there either.)

* Moving them to a new namespace is going to require user code changes
  anyway, so they might as well drop the prefix while they are at it.

* Introducing a new namespace (const?) is going to require more typing
  then the old way. Dropping the prefix reduces the keystroke burden:

     Before
     ------
     from wxPython import wx
     wx.wxEVT_CLOSE_WINDOW

     After (with prefix)
     -------------------
     from wx import const
     const.wxEVT_CLOSE_WINDOW

     After (without prefix)
     ----------------------
     from wx import const
     const.EVT_CLOSE_WINDOW

* Anyone who does import * with the new packaging ought to suffer
  (extensively, and for as long as possible).

That's all I could think of. I'm leaning toward dropping the prefix.

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

25

Patrick K. O'Brien wrote:

Robin Dunn <robin@alldunn.com> writes:

Next question: If we move
the wxEVT constants into a separate submodule, do we want to drop the
wx prefix, or leave it on?
     

Which way would cause the least confusion? On the one hand there will
be some names (but not nearly all) that are the same between the two
modules, and on the other you would be leaving the wx prefix on the
names where you are removing them from everything else...
   
I don't feel too strongly either way. Here are some considerations.

[SNIPPED good summary of reasons to keep or drop the prefix]

FWIW,

I feel that the prefix should be dropped. I find
   const.EVT_CLOSE_WINDOW
easier to read than.
   const.wxEVT_CLOSE_WINDOW
In addition, if we move the constants and keep the prefix it will be an incentive to use the evil
   from wx.const import *
The two extra characters may not seem like much, but I suspect that they will push at least some people to the dark side. Plus, if the constants do get dropped, it'll be a strong disincentive to to import *.

-tim