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

[samjnaa]

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.

[James Stroud]

sa*****@gmail.com 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

[jamadagni]

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?

[James Stroud]

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

[James Stroud]

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

[Duncan Booth]

James Stroud <js*****@mbi.ucla.eduwrote:

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

[Bjoern Schliessmann]

sa*****@gmail.com 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.

[jamadagni]

On Apr 14, 5:06 pm, Duncan Booth <[e-mail]:

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.

[jamadagni]

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.

[=?ISO-8859-1?Q?BJ=F6rn_Lindqvist?=]

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

[jamadagni]

You already can emulate the using statement like this:

You can emulate only assignments like this. How would you emulate
function calls, like the ones in my example?

[Mel Wilson]

sa*****@gmail.com 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

This can be very useful especially in GUI programming when we have to
type the same object name in line-after-line.

q = quitCommandButton
q.enabled = true
q.default = true

Mel.

[Duncan Booth]

"BJörn Lindqvist" <bj*****@gmail.comwrote:

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

That is at least partly because Javascript with statements are badly
broken. Consider the following code:

function setit(a) {
with (a) { x = 1; };
return a;
}
var x;
delete x;
alert(setit({'x':0}).x);
alert(setit({'y':0}).x);
alert(x);
If 'a' has a property 'x' setit updates the property, otherwise it searches
out the scope chain until it finds an object with an 'x' property and
finally creates one on the global object if there isn't one.

So the output in this case is the sequence '1', 'undefined', '1'.

[Duncan Booth]

"jamadagni" <sa*****@gmail.comwrote:

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

Not as much as it would with your 'using' statement. Using a local alias
for an expression lets you use appropriate mnemonic abbreviations
for multiple expressions with. Nested 'using' statements means you have to
look back through the code to try to work out which is in scope at each
level.

[=?ISO-8859-1?Q?BJ=F6rn_Lindqvist?=]

On 14 Apr 2007 07:24:32 -0700, jamadagni <sa*****@gmail.comwrote:

You already can emulate the using statement like this:

You can emulate only assignments like this. How would you emulate
function calls, like the ones in my example?

You can't, of course. But using the with statement:

using self.q:
.doit()

becomes:

with self.quit as q:
q.doit()

:)

--
mvh Björn

[=?ISO-8859-1?Q?BJ=F6rn_Lindqvist?=]

On 4/14/07, BJörn Lindqvist <bj*****@gmail.comwrote:

On 14 Apr 2007 07:24:32 -0700, jamadagni <sa*****@gmail.comwrote:

You already can emulate the using statement like this:

You can emulate only assignments like this. How would you emulate
function calls, like the ones in my example?

You can't, of course. But using the with statement:

using self.q:
.doit()

becomes:

with self.quit as q:
q.doit()

Er.. I guess there are some details you need to work out for that. But
in principle, it works fine.

--
mvh Björn

[7stud]

On Apr 14, 4:42 am, [e-mail] wrote:

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.

....which is a bad practice in C++. When you expose the members of a
namespace, you create the potential for name clashes with the names in
your program. Why would you want to infect Python with that problem?

[7stud]

On Apr 14, 12:57 pm, "7stud" <[e-mail]:

On Apr 14, 4:42 am, [e-mail] wrote:

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.

...which is a bad practice in C++. When you expose the members of a
namespace, you create the potential for name clashes with the names in
your program. Why would you want to infect Python with that problem?

Oh. James Stroud's recommendation would fix that:

I would favor a convention with leading dots
to disambiguate from other variables.

[Georg Brandl]

BJörn Lindqvist schrieb:

On 4/14/07, BJörn Lindqvist <bj*****@gmail.comwrote:

>On 14 Apr 2007 07:24:32 -0700, jamadagni <sa*****@gmail.comwrote:

You already can emulate the using statement like this:

You can emulate only assignments like this. How would you emulate
function calls, like the ones in my example?

You can't, of course. But using the with statement:

using self.q:
.doit()

becomes:

with self.quit as q:
q.doit()

Er.. I guess there are some details you need to work out for that. But
in principle, it works fine.

No, it does not. The "q" here is *not* assigned to self.quit, but to the
result of self.quit.__enter__().

Georg
--
Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
Four shall be the number of spaces thou shalt indent, and the number of thy
indenting shall be four. Eight shalt thou not indent, nor either indent thou
two, excepting that thou then proceed to four. Tabs are right out.

[Bjoern Schliessmann]

jamadagni wrote:

Bjoern Schliessmann wrote:

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

It seems to me that the biggest module you've ever written has less
than 100 lines.

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

So, the gain is the loss of something different? If you say so.

IMHO, the ability to find something quickly weighs much stronger
than needing to write 5 characters more. After all, working on the
code doesn't mean writing new stuff all the time, but modifying and
extending the existing code. A few characters more can enhance
readability vastly. IMHO.

Regards,
Björn

--
BOFH excuse #261:

The Usenet news is out of date

[Terry Reedy]

<sa*****@gmail.comwrote in message
news:11*********************@q75g2000hsh.googlegro ups.com...
| 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()"))

If you want to save typing, you are free to use 's' instead of 'self' as
the parameter name. No need to make a fairly major language change.

I do things like 'import math as m' to save repetition.

tjr

[jamadagni]

On Apr 15, 2:01 am, Bjoern Schliessmann <usenet-
[e-mail]:

self.myVar -- something lost, something gained, IMHO.

So, the gain is the loss of something different? If you say so.

My mistake - I should have said "no pain, no gain".

IMHO, the ability to find something quickly weighs much stronger
than needing to write 5 characters more.

Five characters more how many times?

[Steven D'Aprano]

On Sat, 14 Apr 2007 03:42:52 -0700, samjnaa 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

Which is very much like Pascal's with block.

This question has been asked before:

http://effbot.org/pyfaq/why-doesn-t-...-languages.htm

Despite what the Effbot says, I believe that there is no ambiguity that
can't be resolved.

Specifying that names used in a using-block have a leading dot makes it
obvious to the compiler which names are shortened:

using longname:
x = .attribute # must be longname.attribute
If we forbid nested using-blocks, then all you need is a pre-processor to
change ".attribute" to "longname.attribute". There's never any ambiguity.

But if you want to be really ambitious, one might allow nested
using-blocks. Now the compiler can't resolve names with leading dots at
parse-time, and has to search namespaces at runtime, but that's no
different from what Python already does.
using longname:
using anotherlongname:
x = .attr

In this case, at Python has to determine at runtime which object has an
attribute "attr". If that sounds familiar, it should: that's exactly what
happens when you say instance.attribute: Python searches
instance.__dict__ then instance.__class__.__dict__, and any superclasses.

There is one slight ambiguity left: should Python search longname first or
anotherlongname? But that decision has come up before, for nested scopes
in functions. It seems obvious to me that Python should search deepest to
most shallow, the same way that function nested scopes work.

So the above nested block would be equivalent to:

try:
x = anotherlongname.attr
except AttributeError:
try:
x = longname.attr
except AttributeError:
raise UsingError('no such attribute')
One might even allow a construct like this:

using longname, anotherlongname:
x = .attr

In this case, the search resolution order would be from left to right,
that is, longname before anotherlongname.

--
Steven.

[Colin J. Williams]

James Stroud wrote:

sa*****@gmail.com 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

Yes, I like the idea too. It has deeper roots than Visual Basic. In
Pascal, Nicklaus Wirth used "with" for record access.

It's an idea that can be used with any object which has attributes.
The value of an attribute could be a function or a class.

It's a pity that the word "with" was used for a context declaration -
PEP 343. On the other hand, I believe "using" has been suggested as
an alternative, that seems a reasonable alternative.

Colin W.

[Paul Boddie]

sa*****@gmail.com wrote:

Please check for sanity and approve for posting at python-dev.

Technically, you can post it yourself to python-dev, but you'll just
get bounced back here to discuss it with us. ;-)

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 how the discussion started for the current "with" statement,
although it ended up doing something somewhat different.

[...]

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.

The "with" keyword appears in 2.5 onwards.

Paul

[Alex Martelli]

Paul Boddie <pa**@boddie.org.ukwrote:

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.

The "with" keyword appears in 2.5 onwards.

....but needs a "from __future__ import with_statement" in 2.5 itself.
Alex