analysis of constants for wx namespace reorganization

[Chris_Olds1]

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

+0 on a constants module, +1 on a short name

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

-1

I'd vote a lerger negative number if I could. Your argument is correct,
but names that differ only in case is asking for trouble. In addition,
not all filesystems preserve case. I know there has been a lot done in
the import machinery to mitigate this, but I don't think it's good to
depend on it, especially not in the name of simplification. Of the list
you gave, I'd choose 'wxc' (+0.6).

Thanks for all the effort; I use wx.wxFoo now, and like wx.Foo better...

    /cco

···

On 6 Mar 2003, Patrick K. O'Brien wrote:

[Robin]

Chris Olds wrote:

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

+0 on a constants module, +1 on a short name

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

-1

I'd vote a lerger negative number if I could. Your argument is correct,
but names that differ only in case is asking for trouble. In addition,
not all filesystems preserve case. I know there has been a lot done in
the import machinery to mitigate this, but I don't think it's good to
depend on it, especially not in the name of simplification.

There wouldn't be a case conflict because the WX.py file would be inside the wx package, so there wouldn't be any files at the same location in the filesystem differing only by case.

···

On 6 Mar 2003, Patrick K. O'Brien wrote:

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

[Mike_C_Fletcher2]

Patrick K. O'Brien wrote:

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

...

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

Sorry to have offended. I'm one of those people who see "namespace pollution" as a non-issue, so for me breaking code to support minimising it is far more arbitrary seeming (last time I'll use the word in this message, promise) than it would be for someone who sees it as a real problem.

As I've stated, I'm +0 on the whole issue because the original idea will require (hopefully) less than a month for converting, testing and re-deploying all of my code. I get nervous when the conversion costs creep upward, and I obviously should have stated my concerns with a little more tact. My appologies.

Now that *I* feel better...

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.

I'm willing to admit the possibility that I'm in the minority here. I'm so used to the Ptr classes being needed for membership-checks that I've probably long-since lost all contact with the world of new users.

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

Ah there's the rub. While lots of people care about it, apparently. I don't really see the size of the namespace as any sort of problem worth thinking about, so changing things to solve the problem aren't high on my list of priorities. Oh well, sucks to be me .

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.

Sorry to have caused you any angst. Was intending no disrespect.

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

Oh, like most people, I can reach the del key pretty easily . You're doing work that will benefit the community, you deserve the chance to rant.

Peace, and have fun all,
Mike

···

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

[Patrick_K_O_Brien]

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

><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>
>
Sorry to have offended. I'm one of those people who see "namespace
pollution" as a non-issue, so for me breaking code to support
minimising it is far more arbitrary seeming (last time I'll use the
word in this message, promise) than it would be for someone who sees
it as a real problem.

No offense taken. I just needed another cup of coffee. And I'm on
the other end of the spectrum when it comes to clean namespaces.

As I've stated, I'm +0 on the whole issue because the original idea
will require (hopefully) less than a month for converting, testing and
re-deploying all of my code. I get nervous when the conversion costs
creep upward, and I obviously should have stated my concerns with a
little more tact. My appologies.

No problem. I do appreciate your concerns. I think you'll find we'll
end up being very conservative in the end with any changes we do make.

[snip]

>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.
>
Sorry to have caused you any angst. Was intending no disrespect.

Again, no problem. I just happened to read your message after a couple
of others that kind of irritated me. Since I knew you, and knew you'd
understand, I blew off a little steam.

>Same to you. Thanks for letting me vent. (Like you had a choice.
>
Oh, like most people, I can reach the del key pretty easily .
You're doing work that will benefit the community, you deserve the
chance to rant.

Thanks.

···

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

[Jeff_Shannon]

Patrick K. O'Brien wrote

* 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 this goes through (which I'm about +0.5 on), then this should probably be WX.K_DOWN, to maintain consistency with all the other constants.

As already noted by others, I'm not too worried about case sensitivity. It's not a problem for filesystems, since this is (essentially) the wx.WX module being referred to by an alias, and is clearly distinct from the wx package (site-packages/wx/WX.py vs site-packages/wx/__init__.py), and in code this is visually much more distinct than the Widget/widget class/instance distinction that many programmers find acceptable. (While many others *don't* find that acceptable, I think the visual distinction between wx/WX should be enough to appease many of them.)

Jeff Shannon
Technician/Programmer
Credit International

[Alberto_Griggio2]

Sorry to have offended. I'm one of those people who see "namespace
pollution" as a non-issue, so for me breaking code to support minimising
it is far more arbitrary seeming (last time I'll use the word in this
message, promise) than it would be for someone who sees it as a real
problem.

As I've stated, I'm +0 on the whole issue because the original idea will
require (hopefully) less than a month for converting, testing and
re-deploying all of my code. I get nervous when the conversion costs
creep upward, and I obviously should have stated my concerns with a
little more tact. My appologies.

I think that my opinion is not that different than yours. Personally, I
don't use IDEs, and the only auto-completion I need is dabbrev-expand, so
the size of the wx module is not a big issue for me either. Anyway, the
namespace pollution could be: it is not just because nearly all the names
have a wx prefix, which acts as a sort of namespace. But:

1. Python does have real namespaces
2. Not all names follows this, and in particular I'm referring to TRUE,
   false, NULL and the like (although I've not been affected by this)

so I was thinking that changing from wxSomething to wx.Something was a
good idea (and I still think it is).
Anyway, I have more concerns about splitting the wx namespace, since
this, as you pointed out, would require more changes, and would depart
significantly from wxWindows.

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

I'm willing to admit the possibility that I'm in the minority here. I'm
so used to the Ptr classes being needed for membership-checks that I've
probably long-since lost all contact with the world of new users.

Well, Robin wants them to stay, so this is not an issue anymore I guess.

Ah there's the rub. While lots of people care about it, apparently. I
don't really see the size of the namespace as any sort of problem worth
thinking about, so changing things to solve the problem aren't high on
my list of priorities. Oh well, sucks to be me .

I don't care about the size of the namespace at all either, but I do care
about its existence

Bye,
Alberto

[Patrick_K_O_Brien]

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

Patrick K. O'Brien wrote

>* 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 this goes through (which I'm about +0.5 on), then this should
probably be WX.K_DOWN, to maintain consistency with all the other
constants. As already noted by others, I'm not too worried about case
sensitivity. It's not a problem for filesystems, since this is
(essentially) the wx.WX module being referred to by an alias, and is
clearly distinct from the wx package (site-packages/wx/WX.py vs
site-packages/wx/__init__.py), and in code this is visually much more
distinct than the Widget/widget class/instance distinction that many
programmers find acceptable. (While many others *don't* find that
acceptable, I think the visual distinction between wx/WX should be
enough to appease many of them.)

I'll let Robin decide on the WX.WXK_DOWN versus WX.K_DOWN issue.

As for the case sensitivity issue, thank you for the very nice
summary. Here is my opinion on this matter. I just implemented WX as
the constants module in my prototype:

PyCrust

I'm going to play with it and see what it's like. If we decide to move
the constants, I think the WX module name is a good one. If moving the
constants is a hassle, they'll go right back into the wx
namespace. That will leave us with dropping the "wx" prefix on class
names as the only change in the new wx package. And that may very well
be the only change we make in the short term.

That still leaves us with a very large wx namespace, which does
concern some people, including me. We've tried to segment it
"horizontally" and didn't get very far. The next thing to try is to
segment it "vertically." Robin hinted at this by suggesting we look at
the existing printfw, streams, and filesys modules. And there is
already some vertical segmentation in place: stc, html, lib, etc.

···

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

[Greg_Brunet]

"Jeff Shannon" <jeff@ccvcorp.com> wrote in message
news:3E67CDD4.2040409@ccvcorp.com...

(While many others *don't* find that acceptable, I think the visual
distinction between wx/WX should be enough to appease many of them.)

If you were going to argue for something like "rt" vs. "RT" I would
agree that there is a significant visual distinction. However, I think
that the distinction between "wx" and "WX" is significantly less. I
agree with Chris Olds' comment that names that differ only in case is
asking for trouble. Please don't do it - even though it may seem
elegant to some, it difficult on the case insensitive folks.

···

--
Greg
(though I've also been known to answer to GREG on a regular basis)

[Bob_Klimek]

I'm -1 on ALLCAPS. The most important point is in the above statement, but in addition to that, something like WX.WXK_DOWN is quite ugly to me. OTOH const.WXK_DOWN or even wx.const.WXK_DOWN looks right.

Bob

···

At 11:30 PM 3/6/2003 -0600, you wrote:

"Jeff Shannon" <jeff@ccvcorp.com> wrote in message
news:3E67CDD4.2040409@ccvcorp.com...

> (While many others *don't* find that acceptable, I think the visual
> distinction between wx/WX should be enough to appease many of them.)

If you were going to argue for something like "rt" vs. "RT" I would
agree that there is a significant visual distinction. However, I think
that the distinction between "wx" and "WX" is significantly less. I
agree with Chris Olds' comment that names that differ only in case is
asking for trouble. Please don't do it -

[Tim_Hochberg1]

Bob Klimek wrote:

"Jeff Shannon" <jeff@ccvcorp.com> wrote in message
news:3E67CDD4.2040409@ccvcorp.com...

> (While many others *don't* find that acceptable, I think the visual
> distinction between wx/WX should be enough to appease many of them.)

If you were going to argue for something like "rt" vs. "RT" I would
agree that there is a significant visual distinction. However, I think
that the distinction between "wx" and "WX" is significantly less. I
agree with Chris Olds' comment that names that differ only in case is
asking for trouble. Please don't do it -

I'm -1 on ALLCAPS. The most important point is in the above statement, but in addition to that, something like WX.WXK_DOWN is quite ugly to me. OTOH const.WXK_DOWN or even wx.const.WXK_DOWN looks right.

Would WXK_DOWN become WX.WXK_DOWN or WX.K_DOWN? Probably the latter. In any event the "standard" constants would allmost certainly just have their leading "wx" transmute to a "WX." so that wxEXPAND would become WX.EXPAND.

I would encourage everyone to rewrite a small to medium sized module in their favorite new style. I was quite happy with const until I tried this and I then decided it was somewhat unpleasant both to write and read.

I terms of readablility, I find the flat namespace the best with everything lumped into wx, dropping their wx prefix if they have one. The EVT constants would have to be special cased, but that's not a huge deal. A close second is the wx/WX split. However, since the latter breaks up the namespace into more reasonable sized chunks, something I consider useful in and of itself, I favor it slightly.

As for documentation, most of the changes proposed so far are sufficiently straightforward that I don't expect the wxWindows docs would be signifigantly less useful than they are now. This might not be true if the namespace was being broken up into a bunch of different pieces, but none of those proposals are still on the table.

-tim

···

At 11:30 PM 3/6/2003 -0600, you wrote:

Bob

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

[Patrick_K_O_Brien]

Bob Klimek <klimek@grc.nasa.gov> writes:

I'm -1 on ALLCAPS. The most important point is in the above statement,
but in addition to that, something like WX.WXK_DOWN is quite ugly to
me. OTOH const.WXK_DOWN or even wx.const.WXK_DOWN looks right.

Fair enough. I think that sums up the debate. There is no completely
rational way to decide this because a good part of the issue is
aesthetic. In general I hate ALLCAPS. In the context of wx constants,
I really like WX.WXK_DOWN and it looks completely natural to
me. Others clearly disagree, and I doubt there will be any argument
that would convince either group to change their opinion.

So allow me to try to bring this perspective to the debate. Remember,
there is a very good chance that constants will remain in the main wx
namespace. In many ways this simplifies things, although it forces us
to look elsewhere for a solution to the wx namespace size "problem"
(assuming you think big is bad).

But if enough people agree that constants are an easy win and should
go into a separate module, we'll have to agree on a name for it. I've
outlined some options with their pros and cons elsewhere. Several
people have expressed a preference for const. I happen to think it is
too long in the code samples that I tested. But I certainly wouldn't
oppose this if everyone were happy with it.

But I have one concern and one request to make. My concern is that I
wouldn't want to choose a name and then find out a year from now that
everyone is renaming the module on import because in practice the name
turned out to be impractical or inconvenient. I think if we started to
regularly see things like the following examples, it would be a sign
that we failed in our name choice:

    from wx import const as con

    from wx import const as WX

    from wx import const as wxc

So my request is that we let this issue rest for a few days, and that
anyone with a vested interest take a look at their own actual code,
convert a few samples, and figure out if they could truly live with
their choice of module name. Then we can revisit this issue and
(hopefully) reach a consensus (if a constants module hasn't been ruled
out by then).

···

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

[Bryan_Klimt]

Differentiating two namespaces solely by case-sensitivity is
unacceptable. There are many people who prefer case-insensitivity in
languages because of how they think. (I remember variable names by
sound, rather than by typographic means.) We put up with
case-sensitivity in languages like python and C++ because they are such
great languages otherwise.

-1 on having both WX and wx

-Bryan

From: Tim Hochberg [mailto:tim.hochberg@ieee.org]
Sent: Friday, March 07, 2003 10:48 AM
To: wxPython-users@lists.wxwindows.org
Subject: Re: [wxPython-users] Re: analysis of constants for wx

namespace

reorganization

Bob Klimek wrote:

>
>> "Jeff Shannon" <jeff@ccvcorp.com> wrote in message
>> news:3E67CDD4.2040409@ccvcorp.com...
>>
>> > (While many others *don't* find that acceptable, I think the

visual

>> > distinction between wx/WX should be enough to appease many of

them.)

>>
>> If you were going to argue for something like "rt" vs. "RT" I would
>> agree that there is a significant visual distinction. However, I

think

>> that the distinction between "wx" and "WX" is significantly less.

I

>> agree with Chris Olds' comment that names that differ only in case

is

>> asking for trouble. Please don't do it -
>
>
> I'm -1 on ALLCAPS. The most important point is in the above

statement,

> but in addition to that, something like WX.WXK_DOWN is quite ugly to
> me. OTOH const.WXK_DOWN or even wx.const.WXK_DOWN looks right.

Would WXK_DOWN become WX.WXK_DOWN or WX.K_DOWN? Probably the latter.

In

any event the "standard" constants would allmost certainly just have
their leading "wx" transmute to a "WX." so that wxEXPAND would become
WX.EXPAND.

I would encourage everyone to rewrite a small to medium sized module

in

their favorite new style. I was quite happy with const until I tried
this and I then decided it was somewhat unpleasant both to write and

read.

I terms of readablility, I find the flat namespace the best with
everything lumped into wx, dropping their wx prefix if they have one.
The EVT constants would have to be special cased, but that's not a

huge

deal. A close second is the wx/WX split. However, since the latter
breaks up the namespace into more reasonable sized chunks, something I
consider useful in and of itself, I favor it slightly.

As for documentation, most of the changes proposed so far are
sufficiently straightforward that I don't expect the wxWindows docs
would be signifigantly less useful than they are now. This might not

be

···

-----Original Message-----
> At 11:30 PM 3/6/2003 -0600, you wrote:
true if the namespace was being broken up into a bunch of different
pieces, but none of those proposals are still on the table.

-tim

>
> Bob
>
>
>
>
>
>
>

---------------------------------------------------------------------

> To unsubscribe, e-mail:

wxPython-users-unsubscribe@lists.wxwindows.org

> For additional commands, e-mail:

wxPython-users-help@lists.wxwindows.org

>
>

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

wxPython-users-help@lists.wxwindows.org

[Patrick_K_O_Brien]

"Bryan Klimt" <bryan_klimt@baylor.edu> writes:

Differentiating two namespaces solely by case-sensitivity is
unacceptable.

While I disagree with this general statement...

There are many people who prefer case-insensitivity in
languages because of how they think. (I remember variable names by
sound, rather than by typographic means.) We put up with
case-sensitivity in languages like python and C++ because they are such
great languages otherwise.

... I can appreciate this argument. (I'm a visual person and would
never have thought about the auditory implications.)

-1 on having both WX and wx

Point taken.

···

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

[Joe_Brown2]

From what I've been reading, name change should be limited:

from wxPython. wx import *
vs.
import wx (and apply wart removal)
or
import wx (and apply wart removal)
import wx.const as whaterver (and apply wart removal)

Without a logical breakdown of name space in the parent wxWindows, the child
wxPython's classing hierarchy cannot not assume further breadown without
causing more trouble than it's worth.

Constants don't have a natural place residence. Wx is the prefix in perl,
that sounds like a natural choice for perl, we're talking about Python, so a
Python convention should be assumed. I can't think of anything more
naturally Python than wx.const.*

IMO, further debate should be limited to segregating the constants from the
base wx name space, or not.

-Joe