Mailing List Archive: Python: Dev

Update PEP 292

1 2 3

View All

Index | Next | Previous | View Threaded

barry at python

Aug 10, 2004, 3:42 PM

Post #1 of 66 (2260 views)
Permalink

Update PEP 292

Raymond and I had a chance to talk about PEP 292 on bug day, and we've
exchanged a few private emails and implementations. I think we've
finally knocked everything into shape for inclusion in Python 2.4's next
alpha.

In the sandbox you will find the updated implementation, along with
updated tests and documentation (libstring.tex).

The updated PEP is at:

http://www.python.org/peps/pep-0292.html

A summary of the most important changes:

* Renamed 'dstring' to 'template', and removed the other ?string
classes
* Added a 'safe_template' subclass for non KeyError-throwing
substitutions
* Got rid of safedicts; Raymond figured out the trick to retain
optional braces in the safe substitution case without needing
that class.
* Renamed the 'cre' class attribute for subclasses to 'pattern'

Now for the controversial bit <wink>.

I still think it's worthwhile to turn the string module into a package.
The sandbox has an implementation of this that is completely backward
compatible. I like it because it segregates the deprecated functions
into a separate sub-module and makes the whole shebang easier to
maintain. It also provides an existing namespace for future expansion,
as has been discussed before.

Please note: PEP 292 is not dependent on the string module -> package
reorganization, so it isn't documented in that PEP. I don't think it's
worth writing a PEP just for this library reorganization. Take a look
at the sandbox if you're interested.

http://cvs.sourceforge.net/viewcvs.py/python/python/nondist/sandbox/string/

As far as this aspect of the changes go, I would like BDFL pronouncement
on it. I'll abide by Guido's decision here. If he nixes the re-org,
then I propose to put the template and safe_template classes in
Lib/string.py. The libstring.tex changes will still be relevant.

-Barry

Attachments:

signature.asc (0.30 KB)

bac at OCF

Aug 10, 2004, 6:36 PM

Post #2 of 66 (2199 views)
Permalink

Re: Update PEP 292 [In reply to]

Barry Warsaw wrote:

[SNIP]
> Now for the controversial bit <wink>.
>

Can't leave well enough alone, can you, Barry? =)

> I still think it's worthwhile to turn the string module into a package.
> The sandbox has an implementation of this that is completely backward
> compatible. I like it because it segregates the deprecated functions
> into a separate sub-module and makes the whole shebang easier to
> maintain. It also provides an existing namespace for future expansion,
> as has been discussed before.
>

In case Guido cares, I personally am (and have been) +1 on the
re-organization.

-Brett
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

mwh at python

Aug 11, 2004, 4:22 AM

Post #3 of 66 (2232 views)
Permalink

Re: Update PEP 292 [In reply to]

Barry Warsaw <barry [at] python> writes:

> Raymond and I had a chance to talk about PEP 292 on bug day, and we've
> exchanged a few private emails and implementations. I think we've
> finally knocked everything into shape for inclusion in Python 2.4's next
> alpha.
>
> In the sandbox you will find the updated implementation, along with
> updated tests and documentation (libstring.tex).
>
> The updated PEP is at:
>
> http://www.python.org/peps/pep-0292.html

It's a silly point, but my instant impression on reading

This PEP describes a simpler string substitution feature, also
known as string interpolation.

is "simpler than *what*?". Perhaps a better title for the PEP would
just be "simple string interpolation".

Otherwise, I like it.

The only issue I have with putting it in string is that this makes it
a touch harder to bundle up for use with scripts that work with older
Python's (I take it the implementation is pure Python and works or can
be fairly easily be made to work with 2.2?). But I can live with

try:
from string import template
except ImportError:
from string_compat import template

Cheers,
mwh

--
Exam invigilation - it doesn't come much harder than that, esp if
the book you're reading turns out to be worse than expected.
-- Dirk Bruere, sci.physics.research
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

fredrik at pythonware

Aug 11, 2004, 4:38 AM

Post #4 of 66 (2191 views)
Permalink

Re: Update PEP 292 [In reply to]

Michael Hudson wrote:

> It's a silly point, but my instant impression on reading
>
> This PEP describes a simpler string substitution feature, also
> known as string interpolation.
>
> is "simpler than *what*?".

that's explained in the next sentence, of course.

This PEP is "simpler" in two respects:
[...]

> The only issue I have with putting it in string is that this makes it
> a touch harder to bundle up for use with scripts that work with older
> Python's (I take it the implementation is pure Python and works or can
> be fairly easily be made to work with 2.2?).

here's code that implements the "simpler" syntax, and works with 1.6
and later:

http://effbot.org/zone/re-sub.htm#simple-templating

(from what I saw from the checkins, the PEP implementation isn't exactly
optimal, but I guess we can leave that for the next Optimization Day ;-)

</F>

_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

mwh at python

Aug 11, 2004, 4:40 AM

Post #5 of 66 (2180 views)
Permalink

Re: Re: Update PEP 292 [In reply to]

"Fredrik Lundh" <fredrik [at] pythonware> writes:

> Michael Hudson wrote:
>
>> It's a silly point, but my instant impression on reading
>>
>> This PEP describes a simpler string substitution feature, also
>> known as string interpolation.
>>
>> is "simpler than *what*?".
>
> that's explained in the next sentence, of course.
>
> This PEP is "simpler" in two respects:
> [...]

Yes, I know. It still annoyed me :-)

Cheers,
mwh

--
ZAPHOD: Listen three eyes, don't try to outwierd me, I get stranger
things than you free with my breakfast cereal.
-- The Hitch-Hikers Guide to the Galaxy, Episode 7
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

fperez528 at yahoo

Aug 11, 2004, 5:06 AM

Post #6 of 66 (2215 views)
Permalink

Re: Update PEP 292 [In reply to]

Barry Warsaw wrote:

> Raymond and I had a chance to talk about PEP 292 on bug day, and we've
> exchanged a few private emails and implementations. I think we've
> finally knocked everything into shape for inclusion in Python 2.4's next
> alpha.
>
> In the sandbox you will find the updated implementation, along with
> updated tests and documentation (libstring.tex).
>
> The updated PEP is at:
>
> http://www.python.org/peps/pep-0292.html

If I understood things correctly, this proposal will not allow the evaluation of
any kind of expression, including attributes. With the existing interpolation
system, the following happens:

In [2]: print 'sys.platform is: %(sys.platform)s' % locals()
---------------------------------------------------------------------------
KeyError Traceback (most recent call last)

?

KeyError: sys.platform

I understand why this is the case, but it has always struck me as an unpleasant
aspect of string interpolation, since it often forces me to create throw-away
locals when I want to print data stored as attributes of an object. It is easy
to end up with code that looks like:

_x,_y,_z = self.x, self.y,self.z # throwaways for printing

print """\
The coordinates are:
x = %(_x)s
y = %(_y)s
z = %(_z)s """ % locals()

Simply because trying to do %(self.x)s won't work. This just feels ugly, IMHO.

I wonder if it would be possible to at least allow this kind of expansion
(without going to the full-blown possibilities of PEP 215) in pep-292. I know
there are tricks to produce this kind of evaluation already (which I sometimes
use). But since pep-292 is trying to introduce a standard interpolation
mechanism which is easy to use for the common cases, and object attributes are
such a pervasive part of the language, I hope this addition can be considered.

Best,

f

ps. Forgive me if the above is already allowed; if that is the case, it might be
worth pointing it out in an example in the PEP.

_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

adurdin at gmail

Aug 11, 2004, 5:21 AM

Post #7 of 66 (2227 views)
Permalink

Re: Re: Update PEP 292 [In reply to]

On Wed, 11 Aug 2004 06:06:12 -0600, Fernando Perez <fperez528 [at] yahoo> wrote:
> Barry Warsaw wrote:
>
> > Raymond and I had a chance to talk about PEP 292 on bug day, and we've
> > exchanged a few private emails and implementations. I think we've
> > finally knocked everything into shape for inclusion in Python 2.4's next
> > alpha.
> >
> > In the sandbox you will find the updated implementation, along with
> > updated tests and documentation (libstring.tex).
> >
> > The updated PEP is at:
> >
> > http://www.python.org/peps/pep-0292.html

Forgive me for being obtuse, but I can't see anything significantly
simpler in this PEP than the standard string interpolation, except for
the case where the identifier doesn't need braces:

template("Hello, $name, how are you?") % {name: "Jim"}
versus
"Hello, %(name)s, how are you?") % {name: "Jim"}

Apart from removing the need for the parentheses/braces in this case,
all it does is consistently remove the "s", and replace the % with $,
and then limiting the interpolated values to strings (or will it
automatically use str(x) for any non-string variable x?).
Is there any other benefit to this that I'm overlooking?
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

barry at python

Aug 11, 2004, 6:50 AM

Post #8 of 66 (2196 views)
Permalink

Re: Update PEP 292 [In reply to]

On Wed, 2004-08-11 at 07:22, Michael Hudson wrote:

> It's a silly point, but my instant impression on reading
>
> This PEP describes a simpler string substitution feature, also
> known as string interpolation.
>
> is "simpler than *what*?". Perhaps a better title for the PEP would
> just be "simple string interpolation".

As others have pointed out, that's described in the text of the PEP.

> Otherwise, I like it.

Cool!

> The only issue I have with putting it in string is that this makes it
> a touch harder to bundle up for use with scripts that work with older
> Python's (I take it the implementation is pure Python and works or can
> be fairly easily be made to work with 2.2?). But I can live with
>
> try:
> from string import template
> except ImportError:
> from string_compat import template

To be brutally honest (about our work, that is ;), the template class is
so damn simple you could stick its definition in the except clause.

-Barry

Attachments:

signature.asc (0.30 KB)

barry at python

Aug 11, 2004, 6:55 AM

Post #9 of 66 (2192 views)
Permalink

Re: Re: Update PEP 292 [In reply to]

On Wed, 2004-08-11 at 08:06, Fernando Perez wrote:

> If I understood things correctly, this proposal will not allow the evaluation of
> any kind of expression, including attributes. With the existing interpolation
> system, the following happens:
>
> In [2]: print 'sys.platform is: %(sys.platform)s' % locals()
> ---------------------------------------------------------------------------
> KeyError Traceback (most recent call last)
>
> ?
>
> KeyError: sys.platform

You don't mean the 'existing' interpolation system, because this
obviously doesn't work in Python today, although with a fancy enough
implementation of 'locals()', it could. That actually doesn't change
much with PEP 292. I specifically designed it so that you could
subclass from template, so as to accept the extended placeholder syntax
(i.e. dots), and then implement a mapping-like class to do the lookups
in any namespace you want. In fact, my earlier implementation contained
such a class, but it was deemed too complex to win the name 'simpler' so
it was left out of the library. It's a trivial amount of code and my
own personal use case has a need for such a feature.

-Barry

Attachments:

signature.asc (0.30 KB)

barry at python

Aug 11, 2004, 6:58 AM

Post #10 of 66 (2199 views)
Permalink

Re: Re: Update PEP 292 [In reply to]

On Wed, 2004-08-11 at 08:21, Andrew Durdin wrote:

> Forgive me for being obtuse, but I can't see anything significantly
> simpler in this PEP than the standard string interpolation, except for
> the case where the identifier doesn't need braces:
>
> template("Hello, $name, how are you?") % {name: "Jim"}
> versus
> "Hello, %(name)s, how are you?") % {name: "Jim"}
>
> Apart from removing the need for the parentheses/braces in this case,
> all it does is consistently remove the "s", and replace the % with $,
> and then limiting the interpolated values to strings (or will it
> automatically use str(x) for any non-string variable x?).
> Is there any other benefit to this that I'm overlooking?

The elimination of the trailing 's' is definitely a benefit, as is the
adoption of $-placeholders, since that tends to be the placeholder
introducing character in many other languages. In terms of usability,
it's a win.

-Barry

Attachments:

signature.asc (0.30 KB)

fperez528 at yahoo

Aug 11, 2004, 7:54 AM

Post #11 of 66 (2211 views)
Permalink

Re: Re: Update PEP 292 [In reply to]

Barry Warsaw wrote:

> On Wed, 2004-08-11 at 08:06, Fernando Perez wrote:
>
>> If I understood things correctly, this proposal will not allow the evaluation
>> of
>> any kind of expression, including attributes. With the existing
>> interpolation system, the following happens:
>>
>> In [2]: print 'sys.platform is: %(sys.platform)s' % locals()
>> ---------------------------------------------------------------------------
>> KeyError Traceback (most recent call last)
>>
>> ?
>>
>> KeyError: sys.platform
>
> You don't mean the 'existing' interpolation system, because this
> obviously doesn't work in Python today, although with a fancy enough
> implementation of 'locals()', it could. That actually doesn't change
> much with PEP 292. I specifically designed it so that you could
> subclass from template, so as to accept the extended placeholder syntax
> (i.e. dots), and then implement a mapping-like class to do the lookups
> in any namespace you want. In fact, my earlier implementation contained
> such a class, but it was deemed too complex to win the name 'simpler' so
> it was left out of the library. It's a trivial amount of code and my
> own personal use case has a need for such a feature.

I guess my post wasn't worded too clearly. I did mean existing, in the sense
that the error above occurs with current python (it's cut-and-paste from python
2.2). My point was precisely to illustrate this failure with a simple example,
to then ask whether the new scheme could be made, _as shipped_, to accept this
kind of expansion:

print template('sys.platform is: $sys.platform') % locals()

It may be trivial to extend pep-292 for this, but not having to do it in every
small utility you write/ship would be very useful, IMHO. If there are no
technical reasons to prevent it, is the 'too complex' argument really that
strong (especially since you state it's a trivial amount of code)?

I hope this clarifies better my question.

Regards,

f

_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

skip at pobox

Aug 11, 2004, 7:55 AM

Post #12 of 66 (2173 views)
Permalink

Re: Update PEP 292 [In reply to]

Barry> On Wed, 2004-08-11 at 07:22, Michael Hudson wrote:
>> It's a silly point, but my instant impression on reading
>>
>> This PEP describes a simpler string substitution feature, also
>> known as string interpolation.
>>
>> is "simpler than *what*?". Perhaps a better title for the PEP would
>> just be "simple string interpolation".

Barry> As others have pointed out, that's described in the text of the
Barry> PEP.

>> Otherwise, I like it.

Barry> Cool!

...

I would personally like to thank Barry for stepping up to the plate and
providing a much-needed distraction from the D-word. ;-)

Skip
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

amk at amk

Aug 11, 2004, 8:13 AM

Post #13 of 66 (2199 views)
Permalink

Re: Update PEP 292 [In reply to]

On Tue, Aug 10, 2004 at 06:42:51PM -0400, Barry Warsaw wrote:
> The updated PEP is at:
> http://www.python.org/peps/pep-0292.html

Are you sure that people aren't going to want to format numbers
as they do with % (e.g. %4.2f)?

You should post the PEP to c.l.py.announce, too. (Perhaps you have
and it's still sitting in the queue.)

--amk
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

fredrik at pythonware

Aug 11, 2004, 12:16 PM

Post #14 of 66 (2222 views)
Permalink

Re: Re: Update PEP 292 [In reply to]

Barry Warsaw wrote:

> I specifically designed it so that you could subclass from template, so as to
> accept the extended placeholder syntax (i.e. dots), and then implement a
> mapping-like class to do the lookups in any namespace you want.

on the other hand, to do that, you need to replace the pattern, and
make sure that you have the same number of groups, with the same
meaning. it's doable, but it's rather fragile.

two suggestions:

- refactor the RE, and use lastindex to extract the name (see the link
I posted earlier). This would let users add any number of patterns,
without having to rewrite the __mod__ method. And indexing by
lastindex should be faster than tuple unpacking, too.

- Consider changing the ${} to accept arbitrary patterns, instead of
just Python-style identifiers. \${([^}]+)} should do the trick.

- Consider using character classes instead of re.IGNORECASE (easier
to read, and IIRC, slightly faster).

</F>

_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

mcherm at mcherm

Aug 11, 2004, 4:31 PM

Post #15 of 66 (2196 views)
Permalink

RE: Re: Re: Update PEP 292 [In reply to]

Fredrik writes:
> - Consider changing the ${} to accept arbitrary patterns, instead of
> just Python-style identifiers. \${([^}]+)} should do the trick.

+1

And hey, I'd be +1 on releasing a less-simple template that allowed
arbitrary Python expressions (but no '}' characters) instead of just
identifiers. But that's another issue -- and my liking it doesn't
detract from my liking SIMPLE templates too.

As Barry said elsewhere... even if all it does is to replace '%()s'
with '${}' it's still an improvement.

-- Michael Chermside

_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

greg at cosc

Aug 11, 2004, 6:24 PM

Post #16 of 66 (2192 views)
Permalink

Re: Re: Update PEP 292 [In reply to]

> Apart from removing the need for the parentheses/braces in this case,
> all it does is consistently remove the "s",

I believe that just removing the 's' alone would be a
substantial benefit. It's easy to forget when writing,
and tends to get lost or confused with the surrounding
text when reading.

Greg Ewing, Computer Science Dept, +--------------------------------------+
University of Canterbury, | A citizen of NewZealandCorp, a |
Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. |
greg [at] cosc +--------------------------------------+
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

aahz at pythoncraft

Aug 11, 2004, 8:54 PM

Post #17 of 66 (2211 views)
Permalink

Re: Re: Update PEP 292 [In reply to]

On Thu, Aug 12, 2004, Greg Ewing wrote:
>
>> Apart from removing the need for the parentheses/braces in this case,
>> all it does is consistently remove the "s",
>
> I believe that just removing the 's' alone would be a substantial
> benefit. It's easy to forget when writing, and tends to get lost or
> confused with the surrounding text when reading.

I'll say. I've been doing a lot of work with interpolated strings
lately, and even though I've been bitten several times, I keep making
the same mistake. Maybe I'm just stupid, though...
--
Aahz (aahz [at] pythoncraft) <*> http://www.pythoncraft.com/

"To me vi is Zen. To use vi is to practice zen. Every command is a
koan. Profound to the user, unintelligible to the uninitiated. You
discover truth everytime you use it." --reddy [at] lion
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

tim.peters at gmail

Aug 11, 2004, 10:19 PM

Post #18 of 66 (2216 views)
Permalink

Re: Re: Update PEP 292 [In reply to]

[Barry Warsaw]
> The elimination of the trailing 's' is definitely a benefit, as is the
> adoption of $-placeholders, since that tends to be the placeholder
> introducing character in many other languages. In terms of usability,
> it's a win.

Allowing to skip the {} brackets when they aren't needed is also a win
-- and I expect the most common case.

I do object to this part:

If the $ character appears at the end of the line, or is followed
by any other character than those described above, it is treated
as if it had been escaped, appearing in the resulting string
unchanged.

There's already a facility to escape $, and it's dead easy to use. $
isn't a frequently needed character either in most apps. So escaping
$ "by magic" too is, I think, more likely to make typing errors harder
to find than to do anyone real good.

Better to reserve that magic for the Sloppy^H^H^H^H^H^HSafeTemplate() class.
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

guido at python

Aug 11, 2004, 10:39 PM

Post #19 of 66 (2173 views)
Permalink

Re: Re: Update PEP 292 [In reply to]

This PEP reminded me of the "boo" language (http://boo.codehaus.org/),
a new scripting language for the CLI strongly inspired by Python
(especially the Python 3000 variant :-).

It has string interpolation like this
(http://boo.codehaus.org/String+Interpolation):

print("Now is ${date.Now}.")
print("Tomorrow will be ${date.Now + 1d}")

They require use of {...} after the $, and you don't need to escape
the $ if not followed by {.

Just another design variant (of course they may change it all tomorrow
:-).

--Guido van Rossum (home page: http://www.python.org/~guido/)
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

adurdin at gmail

Aug 11, 2004, 11:05 PM

Post #20 of 66 (2190 views)
Permalink

Re: Re: Update PEP 292 [In reply to]

One thing the PEP doesn't make clear: do these templates only
interpolate string variables, or will they handle anything with a
__str__ method?

e.g., will the following raise an exception:

print Template("I am ${height} centimetres tall.") % {height: 183}
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

python at rcn

Aug 12, 2004, 2:12 PM

Post #21 of 66 (2235 views)
Permalink

RE: Update PEP 292 [In reply to]

[Barry]
> Now for the controversial bit <wink>.
>
> I still think it's worthwhile to turn the string module into a
package.
> The sandbox has an implementation of this that is completely backward
> compatible. I like it because it segregates the deprecated functions
> into a separate sub-module and makes the whole shebang easier to
> maintain. It also provides an existing namespace for future
expansion,
> as has been discussed before.
>
> Please note: PEP 292 is not dependent on the string module -> package
> reorganization, so it isn't documented in that PEP. I don't think
it's
> worth writing a PEP just for this library reorganization. Take a look
> at the sandbox if you're interested.
>
>
http://cvs.sourceforge.net/viewcvs.py/python/python/nondist/sandbox/stri
ng
> /
>
> As far as this aspect of the changes go, I would like BDFL
pronouncement
> on it. I'll abide by Guido's decision here. If he nixes the re-org,
> then I propose to put the template and safe_template classes in
> Lib/string.py. The libstring.tex changes will still be relevant.

After more thought, I would like to voice a strong -1 on the packaging
of string.

At the outset, I felt that it introduced unnecessary complexity. Adding
a new directory, an __init__.py, and two modules just to add a few lines
of code is overkill. Package logic should be reserved for organizing
voluminous code like the email package. Arguably, the logging package
should have been just a single module -- putting it in a package just
made it more difficult to read and maintain.

To test the existing sandbox code, I moved it into the library and found
a circular import issue: importing the string package, causes
template.py to be imported, which in turn imports re which uses
sre_parse.py, needs to import string. So, the whole thing fails. It is
fixable, but it sucks to have to start doing work-arounds from the
outset just to compensate for something that adds no value to begin
with.

The package has already complicated review and updates. I'm having to
re-write it in non-package form just to add doctest (which fails by the
way) and other small fix-ups.

My recommendation: Create a stringtools module with the new template
stuff in it and with room for growth. Leave string.py alone and let it
die in peace.

The business end of the template code is only a few lines long.
Wrapping it in a package is like using cannon to kill a mosquito. Let's
not make something hard out of something trivially simple.

Raymond

P.S. Side rant: Also, in the last few months, the #ifdefs have
multiplied. While I understand that some things like time stamping are
worthwhile, the code is getting harder to read and maintain because of
all this b.s.

At some point, someone changed a definition and I had to add an #ifdef
to import addrinfo.h for VC++ 6.0. I noticed the same had to be done
for Cygwin and there was a similar GCC entry. Each checkin was done by
a separate person fixing a crash in their own part of the universe. The
right answer would have likely been to refactor the original change that
mucked up everyone else's compile. Instead we ended up with a pile of
conditionals that will be hard to maintain going forward because the
surrounding code has become so stiff.

_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

barry at python

Aug 17, 2004, 9:23 PM

Post #22 of 66 (2210 views)
Permalink

Re: Re: Re: Update PEP 292 [In reply to]

On Wed, 2004-08-11 at 10:54, Fernando Perez wrote:

> I guess my post wasn't worded too clearly. I did mean existing, in the sense
> that the error above occurs with current python (it's cut-and-paste from python
> 2.2). My point was precisely to illustrate this failure with a simple example,
> to then ask whether the new scheme could be made, _as shipped_, to accept this
> kind of expansion:
>
> print template('sys.platform is: $sys.platform') % locals()

Not as shipped. You'd have you derive from the Template class and write
a regular expression (or adapt the existing pattern).

> It may be trivial to extend pep-292 for this, but not having to do it in every
> small utility you write/ship would be very useful, IMHO. If there are no
> technical reasons to prevent it, is the 'too complex' argument really that
> strong (especially since you state it's a trivial amount of code)?

Well, it's about 3 lines of Python, but what would you call the class,
AttributeTemplate? I wouldn't be opposed to adding the class, since I
think it would be pretty useful.

-Barry

Attachments:

signature.asc (0.30 KB)

barry at python

Aug 17, 2004, 9:24 PM

Post #23 of 66 (2234 views)
Permalink

Re: Update PEP 292 [In reply to]

On Wed, 2004-08-11 at 11:13, A.M. Kuchling wrote:
> On Tue, Aug 10, 2004 at 06:42:51PM -0400, Barry Warsaw wrote:
> > The updated PEP is at:
> > http://www.python.org/peps/pep-0292.html
>
> Are you sure that people aren't going to want to format numbers
> as they do with % (e.g. %4.2f)?

I'm sure they will, but I think they should just use %-interpolation
then. ;) I'm personally not interested in supporting that for (default)
$-strings.

> You should post the PEP to c.l.py.announce, too. (Perhaps you have
> and it's still sitting in the queue.)

I hadn't, but good point. I'll do that.

-Barry

Attachments:

signature.asc (0.30 KB)

fperez528 at yahoo

Aug 18, 2004, 11:07 AM

Post #24 of 66 (2194 views)
Permalink

Re: Re: Re: Update PEP 292 [In reply to]

Barry Warsaw wrote:

> On Wed, 2004-08-11 at 10:54, Fernando Perez wrote:

>> It may be trivial to extend pep-292 for this, but not having to do it in
>> every
>> small utility you write/ship would be very useful, IMHO. If there are no
>> technical reasons to prevent it, is the 'too complex' argument really that
>> strong (especially since you state it's a trivial amount of code)?
>
> Well, it's about 3 lines of Python, but what would you call the class,
> AttributeTemplate? I wouldn't be opposed to adding the class, since I
> think it would be pretty useful.

I'd like to argue that this form may be the most useful for common tasks, so
you can mix and match "this is foo: $foo and this is foo.bar: $foo.bar"
without having to worry too much about which template class you are using.

How about making a BaseTemplate class which does NOT allow $foo.bar, and having
the default Template implement attributes? This would give us:

- A default class covering what I think is a reasonable, common-case behavior.
I'm a big fan of covering most _reasonable_ default behavior out-of-the-box,
and I think python's stdlib achieves this very well in most cases. I'd argue
this is one of the reasons for its success, and I have the feeling that in
this case (PEP-292) the proposed default would be sub-par.

- A clean base class for user-defined subclasses which want to be very exacting
about what they want to implement or not.

This sounds like a reasonable compromise to me, but ymmv.

Best, and thanks for keeping an open mind about this issue (string
interpolation is one of the very few areas where python's syntax bugs me, even
after years of daily use).

f

_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

barry at python

Aug 19, 2004, 3:32 PM

Post #25 of 66 (2215 views)
Permalink

Re: Re: Update PEP 292 [In reply to]

On Thu, 2004-08-12 at 01:19, Tim Peters wrote:

> I do object to this part:
>
> If the $ character appears at the end of the line, or is followed
> by any other character than those described above, it is treated
> as if it had been escaped, appearing in the resulting string
> unchanged.
>
> There's already a facility to escape $, and it's dead easy to use. $
> isn't a frequently needed character either in most apps. So escaping
> $ "by magic" too is, I think, more likely to make typing errors harder
> to find than to do anyone real good.

What would you do about $'s at the end of the string? I think the
implementation would be much more complex if you didn't have this rule,
e.g. you'd have to match \$$ and the $-placeholder regexps would
basically have to match everything. Then the .sub call would have to be
more complex too, because it would have to check for the existence of
those match groups and then raise an exception. Or something like that.

-Barry

Attachments:

signature.asc (0.30 KB)

1 2 3

View All

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads