Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > Python Feature Request: Add the "using" keyword which works like "with" in Visual Basic

Reply
Thread Tools

Python Feature Request: Add the "using" keyword which works like "with" in Visual Basic

 
 
samjnaa@gmail.com
Guest
Posts: n/a
 
      04-14-2007
Please check for sanity and approve for posting at python-dev.

In Visual Basic there is the keyword "with" which allows an object-
name to be declared as governing the following statements. For
example:

with quitCommandButton
.enabled = true
.default = true
end with

This is syntactic sugar for:

quitCommandButton.enabled=true
quitCommandButton.default=true

This can be very useful especially in GUI programming when we have to
type the same object name in line-after-line. I personally found
having to type the word "self" umpteen times inside classes very
irritating. Such a beautiful language is Python, she should have this
good feature from VB too.

Now I hear that the word "with" is being discussed for a different
purpose in Py 3 as a result of a PEP and I don't want to conflict with
that. So I propose the word "using" as a replacement. This also is
similar to the C++ "using" keyword which exposes the members of a
namespace to access without specifying the namespace scope for each
reference. For example after giving "using namespace std;" I can
change all references to "std::cout" to "cout", which is similar to
what I am proposing for Python now.

Some thoughts about how this "using" statement should behave. The word
using should be followed by an object name and a colon indicating the
start of a block. The object named after "using" must determine the
context (or whatever the technical word is) of the of the statements
in that block.

self.setFixedSize(200, 120)
self.quit = QtGui.QPushButton("Quit", self)
self.quit.setGeometry(62, 40, 75, 30)
self.quit.setFont(QtGui.QFont("Times", 18, QtGui.QFont.Bold))
self.connect(self.quit, QtCore.SIGNAL("clicked()"), QtGui.qApp,
QtCore.SLOT("quit()"))

to be rewritten as:

using self:
__setFixedSize(200,120)
__quit = QtGui.QPushButton("Quit", self)
__using quit:
____setGeometry(62, 40, 75, 30)
____setFont(QtGui.QFont("Times", 18, QtGui.QFont.Bold))
__connect(self.quit, QtCore.SIGNAL("clicked()"), QtGui.qApp,
QtCore.SLOT("quit()"))

[I don't know whether usenet will retain my indenting, so I changed
the tabs to underscores.]

This context governing may need to be limited to the first applicable
member - so that in the above example "self" governs setFixedSize,
quit, quit and connect only in each sentence and quit (self.quit)
governs setGeometry and setFont only. (Point is that the parser should
not search for self.QtGui, self.self or self.QtCore in sentences 3 and
7, and self.quit.QtGui in sentence 6.)

Due to my absence of professional experience, my request may be
somewhat unpolished technical-wise, but I believe that this is a very
useful feature for Python and hence request the technically-
knowledgeable to reformat it as necessary. Thank you.

 
Reply With Quote
 
 
 
 
James Stroud
Guest
Posts: n/a
 
      04-14-2007
http://www.velocityreviews.com/forums/(E-Mail Removed) wrote:
> Please check for sanity and approve for posting at python-dev.
>
> In Visual Basic there is the keyword "with" which allows an object-
> name to be declared as governing the following statements. For
> example:
>
> with quitCommandButton
> .enabled = true
> .default = true
> end with
>
> This is syntactic sugar for:
>
> quitCommandButton.enabled=true
> quitCommandButton.default=true
>
> This can be very useful especially in GUI programming when we have to
> type the same object name in line-after-line. I personally found
> having to type the word "self" umpteen times inside classes very
> irritating. Such a beautiful language is Python, she should have this
> good feature from VB too.
>
> Now I hear that the word "with" is being discussed for a different
> purpose in Py 3 as a result of a PEP and I don't want to conflict with
> that. So I propose the word "using" as a replacement. This also is
> similar to the C++ "using" keyword which exposes the members of a
> namespace to access without specifying the namespace scope for each
> reference. For example after giving "using namespace std;" I can
> change all references to "std::cout" to "cout", which is similar to
> what I am proposing for Python now.
>
> Some thoughts about how this "using" statement should behave. The word
> using should be followed by an object name and a colon indicating the
> start of a block. The object named after "using" must determine the
> context (or whatever the technical word is) of the of the statements
> in that block.
>
> self.setFixedSize(200, 120)
> self.quit = QtGui.QPushButton("Quit", self)
> self.quit.setGeometry(62, 40, 75, 30)
> self.quit.setFont(QtGui.QFont("Times", 18, QtGui.QFont.Bold))
> self.connect(self.quit, QtCore.SIGNAL("clicked()"), QtGui.qApp,
> QtCore.SLOT("quit()"))
>
> to be rewritten as:
>
> using self:
> __setFixedSize(200,120)
> __quit = QtGui.QPushButton("Quit", self)
> __using quit:
> ____setGeometry(62, 40, 75, 30)
> ____setFont(QtGui.QFont("Times", 18, QtGui.QFont.Bold))
> __connect(self.quit, QtCore.SIGNAL("clicked()"), QtGui.qApp,
> QtCore.SLOT("quit()"))
>
> [I don't know whether usenet will retain my indenting, so I changed
> the tabs to underscores.]
>
> This context governing may need to be limited to the first applicable
> member - so that in the above example "self" governs setFixedSize,
> quit, quit and connect only in each sentence and quit (self.quit)
> governs setGeometry and setFont only. (Point is that the parser should
> not search for self.QtGui, self.self or self.QtCore in sentences 3 and
> 7, and self.quit.QtGui in sentence 6.)
>
> Due to my absence of professional experience, my request may be
> somewhat unpolished technical-wise, but I believe that this is a very
> useful feature for Python and hence request the technically-
> knowledgeable to reformat it as necessary. Thank you.
>


I like this one for some reason. Just the "using self" would save hella
typing in a lot of classes. I would favor a convention with leading dots
to disambiguate from other variables. This wouldn't conflict with, say,
floats, because variable names can't begin with a number.

James
 
Reply With Quote
 
 
 
 
jamadagni
Guest
Posts: n/a
 
      04-14-2007
> I like this one for some reason. Just the "using self" would save hella
> typing in a lot of classes. I would favor a convention with leading dots
> to disambiguate from other variables. This wouldn't conflict with, say,
> floats, because variable names can't begin with a number.


Excellent. Now we don't have to worry about the "first applicable
instance" etc. Any member that begins with a dot will have the context
governer auto-prefixed by the parser. This means that nested using
statements should be like follows:

using self:
__using .quit:

with the dot preceding quit also. Excellent!

But you have said "variable names can't begin with a number". The
point this, they shouldn't be able to begin with a *dot*. We are not
worried about numbers here, right?

 
Reply With Quote
 
James Stroud
Guest
Posts: n/a
 
      04-14-2007
jamadagni wrote:
>> I like this one for some reason. Just the "using self" would save hella
>> typing in a lot of classes. I would favor a convention with leading dots
>> to disambiguate from other variables. This wouldn't conflict with, say,
>> floats, because variable names can't begin with a number.

>
> Excellent. Now we don't have to worry about the "first applicable
> instance" etc. Any member that begins with a dot will have the context
> governer auto-prefixed by the parser. This means that nested using
> statements should be like follows:
>
> using self:
> __using .quit:


Under what circumstances would this not mean "using self.quit"? I think
one must be refreshingly imaginative to infer that I was proposing that
we add "." to variable names in general. The idea would be that it
specifies to which names the using statement applies.

James
 
Reply With Quote
 
James Stroud
Guest
Posts: n/a
 
      04-14-2007
jamadagni wrote:
>> I like this one for some reason. Just the "using self" would save hella
>> typing in a lot of classes. I would favor a convention with leading dots
>> to disambiguate from other variables. This wouldn't conflict with, say,
>> floats, because variable names can't begin with a number.

>
> Excellent. Now we don't have to worry about the "first applicable
> instance" etc. Any member that begins with a dot will have the context
> governer auto-prefixed by the parser. This means that nested using
> statements should be like follows:
>
> using self:
> __using .quit:
>
> with the dot preceding quit also. Excellent!
>
> But you have said "variable names can't begin with a number". The
> point this, they shouldn't be able to begin with a *dot*. We are not
> worried about numbers here, right?
>


On third or fourth read, I think you are not being sarcastic and
rhetorical--sorry for my misunderstanding you--I think fatigue is
affecting the little voices in my head. I'm just saying that a preceding
dot is not otherwise used in the language except for perhaps floats.

James
 
Reply With Quote
 
Duncan Booth
Guest
Posts: n/a
 
      04-14-2007
James Stroud <(E-Mail Removed)> wrote:
> I like this one for some reason. Just the "using self" would save
> hella typing in a lot of classes. I would favor a convention with
> leading dots to disambiguate from other variables. This wouldn't
> conflict with, say, floats, because variable names can't begin with a
> number.


I can't see how it is going to save you any typing over what you can
already do.

The suggested example:

self.setFixedSize(200, 120)
self.quit = QtGui.QPushButton("Quit", self)
self.quit.setGeometry(62, 40, 75, 30)
self.quit.setFont(QtGui.QFont("Times", 18, QtGui.QFont.Bold))
self.connect(self.quit, QtCore.SIGNAL("clicked()"), QtGui.qApp,
QtCore.SLOT("quit()"))

(259 characters including newlines but not leading indents).

would become:

using self:
.setFixedSize(200,120)
.quit = QtGui.QPushButton("Quit", self)
using quit:
.setGeometry(62, 40, 75, 30)
.setFont(QtGui.QFont("Times", 18, QtGui.QFont.Bold))
.connect(self.quit, QtCore.SIGNAL("clicked()"), QtGui.qApp, QtCore.SLOT("quit()"))

(251 characters including newlines but not leading indents).

If you are going to reference self.quit a lot of times then it makes
sense to also assign it to a local variable and then you already get
even fewer characters (239):

self.setFixedSize(200, 120)
q = self.quit = QtGui.QPushButton("Quit", self)
q.setGeometry(62, 40, 75, 30)
f = QtGui.QFont
q.setFont(f("Times", 18, f.Bold))
self.connect(q, QtCore.SIGNAL("clicked()"), QtGui.qApp, QtCore.SLOT("quit()"))

Assigning 's=self' would save even more typing, but there are limits
to how unreadable you want it.

Using local variables also means you don't have any ambiguity and can
use a variety of such shorthands interchangeably (e.g. q and f above).
 
Reply With Quote
 
Bjoern Schliessmann
Guest
Posts: n/a
 
      04-14-2007
(E-Mail Removed) wrote:

> In Visual Basic there is the keyword "with" which allows an
> object- name to be declared as governing the following statements.
> For example:
>
> with quitCommandButton
> .enabled = true
> .default = true
> end with
>
> This is syntactic sugar for:
>
> quitCommandButton.enabled=true
> quitCommandButton.default=true


Personally, I'd never use it. In more complex modules, when you are
looking for, e. g., self.myVar and anotherObject.myVar,
this "using" statement decreases readability and maintainability
(in full text searching). IMHO.

Regards,


Björn

--
BOFH excuse #406:

Bad cafeteria food landed all the sysadmins in the hospital.

 
Reply With Quote
 
jamadagni
Guest
Posts: n/a
 
      04-14-2007
On Apr 14, 5:06 pm, Duncan Booth <(E-Mail Removed)> wrote:

> I can't see how it is going to save you any typing over what you can
> already do.
>
> The suggested example:


The suggested example is only a small case. I realize that the main
usage would be when there are a lot of repetitive usages when the five
characters "using", the space and the colon at the end would be worth
the full typing.

> (259 characters including newlines but not leading indents).
> would become:
> (251 characters including newlines but not leading indents).


So there *is* gain even in this small case. It's a matter of avoiding
the bore and potential scope for typos in repetitive typing.

> If you are going to reference self.quit a lot of times then it makes
> sense to also assign it to a local variable and then you already get
> even fewer characters (239):


But you realize readability decreases considerably.

 
Reply With Quote
 
jamadagni
Guest
Posts: n/a
 
      04-14-2007
> Personally, I'd never use it.

You are free to avoid using it of course.

> In more complex modules, when you are
> looking for, e. g., self.myVar and anotherObject.myVar,
> this "using" statement decreases readability and maintainability
> (in full text searching). IMHO.


Why? Just search for self and you turn up using self. Just scan down
(the block) and you get myVar. Similarly for anotherObject.myVar.

Of course, you lose the possibility of just searching for self.myVar
-- something lost, something gained, IMHO.

 
Reply With Quote
 
=?ISO-8859-1?Q?BJ=F6rn_Lindqvist?=
Guest
Posts: n/a
 
      04-14-2007
Your idea isn't new and has already been discussed lots of time
before. It was once planned to be implemented in py3k, but no longer
is.

One of the problems is that with a "using" statement, you always have
to decide whether your code repeats some prefix enough times to use a
"using" statement. Should you write:

self.quit.action = self.bar
self.quit.name = "End it"

or should it be:

using self.quit:
.action = self.bar
.name = "End it"

? Not having to bother with petty things like that is an advantage.
Javascript has with-statements that are equivalent to your
using-statements but from what I've seen most programmers avoid them.
They don't increase readability one bit.

You already can emulate the using statement like this:

def using(obj, **kw):
for key, val in kw.items():
setattr(obj, key, val)

using(self.quit,
action = self.bar,
name = "End it")

But I have never seen anyone do that, which I think, is a sign that
nobody wants the feature.

--
mvh Björn
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
RE: keyword checker - keyword.kwlist Hamilton, William Python 4 05-13-2007 06:31 AM
keyword checker - keyword.kwlist tom@finland.com Python 6 05-10-2007 04:53 PM
which feature of python do you like most? zelzel.zsu@gmail.com Python 26 11-13-2005 11:42 PM
What is the difference between Visual Basic.NET and Visual Basic 6? Jimmy Dean Computer Support 3 07-25-2005 07:05 AM
Upgrading Microsoft Visual Basic 6.0 to Microsoft Visual Basic .NET Jaime MCSD 2 09-20-2003 05:16 AM



Advertisments