New Python 3.0 string formatting - really necessary?

B

bearophileHUGS

MRAB:
Interesting. The re module uses a form of bytecode. Not sure about the
relative cost of the dispatch code, though.

I was talking about the main CPython VM, but the same ideas may be
adapted for the RE engine too.

Bye,
bearophile
 
B

Bruno Desthuilliers

r a écrit :
(snip clueless rant)
One more big complaint "THE BACKSLASH PLAGUE". ever tried regexp?

Yes.

exp = re.compile(r"no \problem \with \backslashes")
, or
file paths?.

You mean _dos/windows_ file path separator ? It was indeed a stupid
choice _from microsoft_ to choose the by then well established escape
char (the backslash) as a file path separator. But hopefully, Python
handles it gracefully: you can either use raw strings (which I stronly
advise you learn about instead of whining) or just the traditional unix
one (forward slash) instead.
All because that little backslash char is a line
continuation character,

Totally clueless, as usual... Why don't you just READ THAT FUCKING MANUAL ?
 
R

r

I noticed when i mentioned "self" nobody wants to touch that subject.
There could be many reasons why...

0.) nobody but the 10 regulars i see here exists
1.) nobody cares(doubt it)
2.) nobody is brave enough to question it(maybe)
3.) most people like to type self over and over again(doubt it)
4.) most people here have given up on changing the BDFL's mind about
it. (good possibility)
5.) this is a hot-button topic(no doubt in my mind!)

I think Guido's intension's are pure, but this is a major turnoff to
new users. Do we really need to hold a new users hand that much. Does
it really matter if they know the path of said obj. If you can't
fiqure this out for yourself you have much greater problems.

I do not like self, and i lamented it from day one, now it is second
nature to me but does that mean it is really needed?? I feel i have
been brainwashed into its usage.

This was the reason for using indention over the bracket plague in
python. REDUNDANCY!!! Why not dump self and make the language cleaner.
I love python's classes, but HATE self.redundant! This really needs to
be fixed, and you have not heard the last from me about it!!!

3000 would have been the perfect time to dump self and really clean up
the language, and it's not too late, dawn is not upon us yet.
 
B

Bruno Desthuilliers

walterbyrd a écrit :
I guess it's good to know that there is, at least, one person in the
world doesn't like the % formatting. As least the move was not
entirely pointless.

But, you must admit, of all the things people complain about with
Python, the % formatting is probably one of the least common
complaints. Complaints about Python's speed seem much more common.

<dead-horse-beaten-to-hell-and-back>
People complaining about the perceived issues wrt/ Python's speed are
welcome to fix it. As far as I'm concerned, I find the perfs more than
acceptable when you take Python's dynamism into account. Strange enough,
no one seems to complain about PHP or Ruby's performances...
Yet, 3.0 makes the speed worse,

first make it right, then make it fast...
and "fixes" a non-problem.

I can see where the new formatting might be helpful in some cases.
But, I am not sure it's worth the cost.

Err... _Which_ cost exactly ?
 
B

Bruno Desthuilliers

r a écrit :
I noticed when i mentioned "self" nobody wants to touch that subject.
There could be many reasons why...

0.) nobody but the 10 regulars i see here exists
1.) nobody cares(doubt it)
2.) nobody is brave enough to question it(maybe)
3.) most people like to type self over and over again(doubt it)
4.) most people here have given up on changing the BDFL's mind about
it. (good possibility)
5.) this is a hot-button topic(no doubt in my mind!)

6.) you are definitevely clueless.

(snip)
I love python's classes, but HATE self.redundant!

This declaration only makes clear that answer to your above question is #6.
This really needs to
be fixed,

Your ignorance needs to be fixed, yes, indeed. Please go and fix it -
all the relevant materials is available in (or linked from somewhere in)
this newgroup's archives.
and you have not heard the last from me about it!!!

As far as I'm concerned, yes. Welcome to my bozo filter. Please come
back when you'll have grown a brain.
 
S

skip

r> I do not like self, and i lamented it from day one, now it is second
r> nature to me but does that mean it is really needed?? I feel i have
r> been brainwashed into its usage.

...

r> 3000 would have been the perfect time to dump self and really clean up
r> the language, and it's not too late, dawn is not upon us yet.

Bruce Eckel proposes removing self from argument lists:

http://www.artima.com/weblogs/viewpost.jsp?thread=239003

Guido responds:

http://neopythonic.blogspot.com/2008/10/why-explicit-self-has-to-stay.html
 
L

Luis Zarrabeitia

Quoting r said:
I noticed when i mentioned "self" nobody wants to touch that subject.
There could be many reasons why...

0.) nobody but the 10 regulars i see here exists
1.) nobody cares(doubt it)
2.) nobody is brave enough to question it(maybe)
3.) most people like to type self over and over again(doubt it)
4.) most people here have given up on changing the BDFL's mind about
it. (good possibility)
5.) this is a hot-button topic(no doubt in my mind!)

You forgot
6.) it is the best, cleanest, most consistent and extensible way to do it.
This was the reason for using indention over the bracket plague in
python. REDUNDANCY!!! Why not dump self and make the language cleaner.
I love python's classes, but HATE self.redundant! This really needs to
be fixed, and you have not heard the last from me about it!!!

Do you also hate cls.redundant on a classmethod? Would you rather type 'self'
even when it is referring to a class? Would you like to resort to a hack, like
C#3.0's 'this' explicit argument, when monkey-patching?

I used to hate 'self'. Then I met classmethods, metaclasses and decorators, and
the 'new'/'types' modules. It's just one of those examples where Guido's time
machine works flawlessly.
3000 would have been the perfect time to dump self and really clean up
the language, and it's not too late, dawn is not upon us yet.

No need to wait for python 3000.

You can have a 'selfless metaclass' right now:

http://www.voidspace.org.uk/python/articles/metaclasses.shtml

(BTW, I really hope you are complaining about the explicit self on the argument
list, and not about the 'self.' prefix - if that were the case, what magic would
you propose for the compiler to guess when you are referring to locals, globals,
class or instance variables?)
 
M

MRAB

r said:
I noticed when i mentioned "self" nobody wants to touch that subject.
There could be many reasons why...

0.) nobody but the 10 regulars i see here exists
1.) nobody cares(doubt it)
2.) nobody is brave enough to question it(maybe)
3.) most people like to type self over and over again(doubt it)
4.) most people here have given up on changing the BDFL's mind about
it. (good possibility)
5.) this is a hot-button topic(no doubt in my mind!)
6.) nobody here wants to go through that whole discussion yet again
 
R

r

Bruno,
I thought i had already gone up, up, and away to your kill filter.
hmm, guess you had a change of heart ;D
 
A

Aaron Brady

Let's assume that Format objects display their value like the equivalent
string format:

 >>> f = "%r %i"
 >>> f
'%r %i'
 >>> f = f % (2, 3, 4)
 >>> f
<Format '(2, 3, 4) %i'>
 >>> f = f % 1
 >>> f
'(2, 3, 4) 1'
 >>>
 >>> f = "%s %i"
 >>> f
'%s %i'
 >>> f = f % '%i'
 >>> f
<Format '%%i %i'>
 >>> f = f % 1
 >>> f
'%%i 1'

I assume you meant '%i 1' since there are no more flags in f, and it's
returned to a regular string.

'f %= 1' doesn't work any more as in-place modulo, since one time, 'f'
is a Format object, the other, 'f' is a string. Just raise an
exception for that (or assign to __class__ IINM if I'm not mistaken).

Actually, the class you showed is kind of nifty. Tuples are correctly
interpolated. I think on the whole you'll use more parenthesis, since
each term in the tuple appears separately, and might be an expression
(have a lower-precedence op.), as well as more modulo signs.

You can currently do-it-yourself, you just need a constructor in the
format string.
<type 'Format'>

Or, as someone suggested earlier, a new literal marking:
<type 'Format'>
 
M

MRAB

Aaron said:
I assume you meant '%i 1' since there are no more flags in f, and it's
returned to a regular string.
Correct.

'f %= 1' doesn't work any more as in-place modulo, since one time, 'f'
is a Format object, the other, 'f' is a string. Just raise an
exception for that (or assign to __class__ IINM if I'm not mistaken).
All assignments rebind, even the augmented form:
def __mod__(self, value):
return C2()
def __mod__(self, value):
return C2()

Actually, the class you showed is kind of nifty. Tuples are correctly
interpolated. I think on the whole you'll use more parenthesis, since
each term in the tuple appears separately, and might be an expression
(have a lower-precedence op.), as well as more modulo signs.

You can currently do-it-yourself, you just need a constructor in the
format string.

<type 'Format'>

Or, as someone suggested earlier, a new literal marking:
Yes, I suggested that earlier, but it isn't needed because you can
create a format object with "Format(string)". However, most of the time
you won't bother to create a format object explicitly because of:

class str(object):
def __mod__(self, value):
return Format(self) % value
<type 'Format'>
<Format '(2, 3, 4) %i'>

I'd also like to add that there's nothing to prevent format objects from
having other methods where multiple placeholders can be filled in one call:
>>> # By position
>>> f = Format("%r %i")
>>> f
>>> f.fill([(2, 3, 4), 1]) '(2, 3, 4) 1'
>>>
>>> # By name
>>> f = Format("%{tuple}r %{int}i")
>>> f
>>> f.fill({"tuple": (2, 3, 4), "int": 1})
'(2, 3, 4) 1'
 
A

alex23

Most of the complaints i hear are the redundant use of self.
Which I lamented about but have become accustom(brainwashed) to it. I
would remove this if it where up to me.

It's a shame Python wasn't released under some kind of license, one
that allowed its source to be, say, "opened" and modified. Otherwise
you would just implement this yourself and submit patches, right?
 
J

James Mills

It's a shame Python wasn't released under some kind of license, one
that allowed its source to be, say, "opened" and modified. Otherwise
you would just implement this yourself and submit patches, right?

+1 :)
 
A

Aaron Brady

I assume you meant '%i 1' since there are no more flags in f, and it's
returned to a regular string.
Correct.

'f %= 1' doesn't work any more as in-place modulo, since one time, 'f'
is a Format object, the other, 'f' is a string.  Just raise an
exception for that (or assign to __class__ IINM if I'm not mistaken).

All assignments rebind, even the augmented form:

 >>> class C1(object):
        def __mod__(self, value):
                return C2()

 >>> class C2(object):
        def __mod__(self, value):
                return C2()

 >>> f = C1()
 >>> f
<__main__.C1 object at 0x00D144F0>
 >>> f % 0
<__main__.C2 object at 0x00D143F0>
 >>> f %= 0
 >>> f
<__main__.C2 object at 0x00D145B0>


Actually, the class you showed is kind of nifty.  Tuples are correctly
interpolated.  I think on the whole you'll use more parenthesis, since
each term in the tuple appears separately, and might be an expression
(have a lower-precedence op.), as well as more modulo signs.
You can currently do-it-yourself, you just need a constructor in the
format string.

<type 'Format'>
Or, as someone suggested earlier, a new literal marking:

Yes, I suggested that earlier, but it isn't needed because you can
create a format object with "Format(string)". However, most of the time
you won't bother to create a format object explicitly because of:

class str(object):
     def __mod__(self, value):
         return Format(self) % value
<type 'Format'>

 >>> # Explicitly
 >>> f = Format("%r %i")
 >>> f
<Format '%r %i'>
 >>> f % (2, 3, 4)
<Format '(2, 3, 4) %i'>
 >>>
 >>> # Implicitly, relying on the __mod__ method of str
 >>> f = "%r %i"
 >>> f
'%r %i'
 >>> f % (2, 3, 4)
<Format '(2, 3, 4) %i'>

I'd also like to add that there's nothing to prevent format objects from
having other methods where multiple placeholders can be filled in one call:

 >>> # By position
 >>> f = Format("%r %i")
 >>> f
<Format '%r %i'>
 >>> f.fill([(2, 3, 4), 1])
'(2, 3, 4) 1'
 >>>
 >>> # By name
 >>> f = Format("%{tuple}r %{int}i")
 >>> f
<Format '%{tuple}r %{int}i'>
 >>> f.fill({"tuple": (2, 3, 4), "int": 1})
'(2, 3, 4) 1'

You're choosing to favor the '.chain()' method over the '.fill()'
method for the behavior of '%'. I don't think you've justified it
though.
'(2, 3, 4) 0'

Plus, I almost think we've almost attained defeating the purpose.
 
M

MRAB

Aaron said:
Aaron said:
Aaron Brady wrote:
snip
The original format is a string. The result of '%' is a string if
there's only 1 placeholder to fill, or a (partial) format object (class
"Format"?) if there's more than one. Similarly, the format object
supports '%'. The result of '%' is a string if there's only 1
placeholder to fill, or a new (partial) format object if there's more
than one.
f = "%r %i"
type(f)
<type 'str'>
f = f % (2, 3, 4)
type(f)
<type 'Format'>
f = f % 1
type(f)
<type 'str'>
Alright, so how are you handling:
f= "%s %i"
type( f )
<type 'str'>
f= f% '%i' #now '%i %i'
type( f )
<type 'Format'>
f= f% 1
type( f )
?
In other words, are you slipping '1' in to the very first available
slot, or the next, after the location of the prior?
Let's assume that Format objects display their value like the equivalent
string format:
f = "%r %i"
f
'%r %i'
f = f % (2, 3, 4)
f
<Format '(2, 3, 4) %i'>
f = f % 1
f
'(2, 3, 4) 1'
f = "%s %i"
f
'%s %i'
f = f % '%i'
f
<Format '%%i %i'>
f = f % 1
f
'%%i 1'
I assume you meant '%i 1' since there are no more flags in f, and it's
returned to a regular string. Correct.

'f %= 1' doesn't work any more as in-place modulo, since one time, 'f'
is a Format object, the other, 'f' is a string. Just raise an
exception for that (or assign to __class__ IINM if I'm not mistaken).
All assignments rebind, even the augmented form:
class C1(object):
def __mod__(self, value):
return C2()
class C2(object):
def __mod__(self, value):
return C2()
f = C1()
f
<__main__.C2 object at 0x00D145B0>


Actually, the class you showed is kind of nifty. Tuples are correctly
interpolated. I think on the whole you'll use more parenthesis, since
each term in the tuple appears separately, and might be an expression
(have a lower-precedence op.), as well as more modulo signs.
You can currently do-it-yourself, you just need a constructor in the
format string.
f = Format("%r %i")
type(f)
<type 'Format'>
f = f % (2, 3, 4)
type(f)
<type 'Format'>
Or, as someone suggested earlier, a new literal marking:
Yes, I suggested that earlier, but it isn't needed because you can
create a format object with "Format(string)". However, most of the time
you won't bother to create a format object explicitly because of:

class str(object):
def __mod__(self, value):
return Format(self) % value
f = f"%r %i"
type(f)
<type 'Format'>
# Explicitly
f = Format("%r %i")
f
f % (2, 3, 4)
# Implicitly, relying on the __mod__ method of str
f = "%r %i"
f '%r %i'
f % (2, 3, 4)
<Format '(2, 3, 4) %i'>

I'd also like to add that there's nothing to prevent format objects from
having other methods where multiple placeholders can be filled in one call:
# By position
f = Format("%r %i")
f
f.fill([(2, 3, 4), 1]) '(2, 3, 4) 1'

# By name
f = Format("%{tuple}r %{int}i")
f
f.fill({"tuple": (2, 3, 4), "int": 1})
'(2, 3, 4) 1'

You're choosing to favor the '.chain()' method over the '.fill()'
method for the behavior of '%'. I don't think you've justified it
though.
'(2, 3, 4) 0'

Plus, I almost think we've almost attained defeating the purpose.
The disadvantage of the chaining method is that it's positional,
left-to-right. For the purposes of i18n you want tagged placeholders,
whether they be integers or names. I think... OK, if the placeholders
include a positional tag, eg "%(0)s %(1)s", then they could be filled in
according to _that_ order. Not sure about named placeholders, though.
Perhaps, like at present, if a dict is given to a format with named
placeholders then several placeholders could be filled, the problem
being how to fill a _single_ named placeholder with a dict.
 
A

Aaron Brady

Aaron said:
Yes, I suggested that earlier, but it isn't needed because you can
create a format object with "Format(string)". However, most of the time
you won't bother to create a format object explicitly because of:
class str(object):
     def __mod__(self, value):
         return Format(self) % value
f = f"%r %i"
type(f)
<type 'Format'>
 >>> # Explicitly
 >>> f = Format("%r %i")
 >>> f
<Format '%r %i'>
 >>> f % (2, 3, 4)
<Format '(2, 3, 4) %i'>
 >>> # Implicitly, relying on the __mod__ method of str
 >>> f = "%r %i"
 >>> f
'%r %i'
 >>> f % (2, 3, 4)
<Format '(2, 3, 4) %i'>
I'd also like to add that there's nothing to prevent format objects from
having other methods where multiple placeholders can be filled in one call:
 >>> # By position
 >>> f = Format("%r %i")
 >>> f
<Format '%r %i'>
 >>> f.fill([(2, 3, 4), 1])
'(2, 3, 4) 1'
 >>> # By name
 >>> f = Format("%{tuple}r %{int}i")
 >>> f
<Format '%{tuple}r %{int}i'>
 >>> f.fill({"tuple": (2, 3, 4), "int": 1})
'(2, 3, 4) 1'
You're choosing to favor the '.chain()' method over the '.fill()'
method for the behavior of '%'.  I don't think you've justified it
though.
'(2, 3, 4) 0'
Plus, I almost think we've almost attained defeating the purpose.

The disadvantage of the chaining method is that it's positional,
left-to-right. For the purposes of i18n you want tagged placeholders,
whether they be integers or names. I think... OK, if the placeholders
include a positional tag, eg "%(0)s %(1)s", then they could be filled in
according to _that_ order. Not sure about named placeholders, though.
Perhaps, like at present, if a dict is given to a format with named
placeholders then several placeholders could be filled, the problem
being how to fill a _single_ named placeholder with a dict.

Just pass a keyword argument to chain.
'(2, 3, 4) 0'

You might want to call it 'fchain' or 'chainf'.
 
W

walterbyrd

Strange enough,
no one seems to complain about PHP or Ruby's performances...

A few years back, there was a certain amount of chest thumping, when
python/django easily beat ror in a benchmark test. Now that ruby is
faster, I guess speed is no big issue.

By the same reasoning, python advocates used to sneer at php because
php constantly broke backward compatibility. Now that python does it,
breaking backward compatibility is no big deal. I guess unicode
support was not that important, until python caught up to perl.

I guess, the way it works is: you first assume that python is
superior, then you figure out why.
 
M

Michael Torrie

r said:
Steven,
Would you like to elaborate on -why- escaped backslashes are needed in
strings... i waiting???

Some character was needed. It just happens that backslashes have been
used in this manner for composing nonprintable sequences, codes, etc.
It's only in use because someone arbitrarily picked it about 40 years
ago. Any character could have been used; any such character would still
be have to escaped.

Kind of funny that you are complaining about Python in particular when
this behavior is in almost all languages today, including Perl, Ruby,

Don't blame python for a mistake that Microsoft made, that of choosing a
commonly-accepted escape character (long before Python was even though
of!) as their path delimiter. Fortunately sane operating systems use a
standard slash. Even Windows APIs accept forward slashes as path
delimiters.

So really your complaint about the backslash is a bit silly. Are you
going to campaign that C# and Java also "fix" this problem by choosing
another character?
 
S

Steve Holden

walterbyrd said:
A few years back, there was a certain amount of chest thumping, when
python/django easily beat ror in a benchmark test. Now that ruby is
faster, I guess speed is no big issue.
A fairly limited amount of chest-thumping, as I remember it.
By the same reasoning, python advocates used to sneer at php because
php constantly broke backward compatibility. Now that python does it,
breaking backward compatibility is no big deal. I guess unicode
support was not that important, until python caught up to perl.
Python advocates shouldn't sneer at other languages. There's no need. If
you like Python, use it because of its merits, not because it's better
than something else.

Having said which, I must say that Python's "breaking backward
incompatibility" is of a somewhat different nature than (say) Visual
Basic's. It was known about for *several years* in advance, even before
Guido went to work for Google and finally had time to get the work
underway. Also it's defined to be a singular event, not a continuous set
of creeping changes. Python 3's updated syntax now constrains the
developers in the same way that Python 2's used to.

I wouldn't say that could remotely be described as "constantly" breaking
backward compatibility.
I guess, the way it works is: you first assume that python is
superior, then you figure out why.
That's the way some people operate, but by no means all. Is it the
language or the people that are pissing you off. You sound a little
discontented for a c.l.py reader.

regards
Steve
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,781
Messages
2,569,616
Members
45,306
Latest member
TeddyWeath

Latest Threads

Top