Re: bug or feature in enum34 py2.7 backport?
On 11/26/2014 10:32 AM, random...@fastmail.us wrote: It seems like if it is a bug to reject long where int is accepted, I do not believe that is universally true is 2.7. But even if it is... Short ints were, value-wise, a subset of longs. Thus, for example, binary operations could always convert the int to long and continue. In 3.0, short ints were removed and long renamed int. should be likewise considered a bug to reject ASCII-only unicode where str is accepted. That would require an O(n) check. Bytes and unicode have an ascii overlap when bytes are interpreted as ascii chars, but neither is a subset of the other. Mixed binary operations were removed in 3.x. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: bug or feature in enum34 py2.7 backport?
On 11/26/2014 07:32 AM, random...@fastmail.us wrote: > > It seems like if it is a bug to reject long where int is accepted, it > should be likewise considered a bug to reject ASCII-only unicode where > str is accepted. While I agree, I don't know if there are currently any parts of core 2.7 that follow that philosophy -- and if there aren't, it's extremely unlikely to change now. However, enum34 has now been updated to handle unicode class names. Thanks for the bug report. :) -- ~Ethan~ signature.asc Description: OpenPGP digital signature -- https://mail.python.org/mailman/listinfo/python-list
Re: bug or feature in enum34 py2.7 backport?
On Thu, Nov 27, 2014 at 2:32 AM, wrote: > But why shouldn't the type constructor do the conversion (and any > validation of being ASCII-only) when parsing the arguments? The root > cause seems to be that it parses its arguments with "SO!O!:type" > (typeobject.c, line 2097). Does anyone know what problems would be > caused, in general, by having S do a conversion if provided with a > unicode object? > > It seems like if it is a bug to reject long where int is accepted, it > should be likewise considered a bug to reject ASCII-only unicode where > str is accepted. Hmm, that sounds like it would be a feature improvement, rather than a bug fix. But you could take that up with the release manager. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: bug or feature in enum34 py2.7 backport?
On Wed, Nov 26, 2014, at 09:40, Chris Angelico wrote: > I'd say that's a limitation, not a bug. A lot of stuff in Python 2 > depends on identifiers being ASCII-only byte strings, including - > apparently - parts of the core code. But why shouldn't the type constructor do the conversion (and any validation of being ASCII-only) when parsing the arguments? The root cause seems to be that it parses its arguments with "SO!O!:type" (typeobject.c, line 2097). Does anyone know what problems would be caused, in general, by having S do a conversion if provided with a unicode object? It seems like if it is a bug to reject long where int is accepted, it should be likewise considered a bug to reject ASCII-only unicode where str is accepted. -- https://mail.python.org/mailman/listinfo/python-list
Re: bug or feature in enum34 py2.7 backport?
On Thu, Nov 27, 2014 at 2:14 AM, Mark Summerfield wrote: > I only mentioned it since I noticed it. I actually use Python 3 so it isn't a > problem for me, but sometimes I have to teach Python 2.7 and I wanted to > cover enum because it is so much nicer and easier to debug than FOO = 1 etc. > > However, the problem is that enum's function API doesn't play nicely with > unicode literals. One solution is to use the class API instead: > > > from __future__ import print_function > from __future__ import unicode_literals > import enum > print(enum.version) > class A(enum.Enum): >b = 1 >c = 2 > print(A.b, A.c) Yeah, because now "class A" is not a literal, and is therefore not affected by the unicode_literals directive. But I think that notation looks just fine anyway, so that would probably be the cleanest solution. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: bug or feature in enum34 py2.7 backport?
I only mentioned it since I noticed it. I actually use Python 3 so it isn't a
problem for me, but sometimes I have to teach Python 2.7 and I wanted to cover
enum because it is so much nicer and easier to debug than FOO = 1 etc.
However, the problem is that enum's function API doesn't play nicely with
unicode literals. One solution is to use the class API instead:
from __future__ import print_function
from __future__ import unicode_literals
import enum
print(enum.version)
class A(enum.Enum):
b = 1
c = 2
print(A.b, A.c)
On Wednesday, November 26, 2014 2:41:16 PM UTC, Chris Angelico wrote:
> On Thu, Nov 27, 2014 at 1:05 AM, wrote:
> > On Wed, Nov 26, 2014, at 06:29, Mark Summerfield wrote:
> >> TypeError: type() argument 1 must be string, not unicode
> >
> > If this is a bug, maybe it is one in type() itself - I get the same
> > error with type('X', (object,), dict(a=1))
>
> I'd say that's a limitation, not a bug. A lot of stuff in Python 2
> depends on identifiers being ASCII-only byte strings, including -
> apparently - parts of the core code. Suggestion: Switch to Python 3,
> or if you can't do that, pass your identifiers through str(). When you
> do eventually switch to Py3, that won't do anything, but in Py2, it'll
> force them to be byte strings. As long as they are actually
> ASCII-only, that'll solve your problem.
>
> ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: bug or feature in enum34 py2.7 backport?
On Thu, Nov 27, 2014 at 1:05 AM, wrote:
> On Wed, Nov 26, 2014, at 06:29, Mark Summerfield wrote:
>> TypeError: type() argument 1 must be string, not unicode
>
> If this is a bug, maybe it is one in type() itself - I get the same
> error with type('X', (object,), dict(a=1))
I'd say that's a limitation, not a bug. A lot of stuff in Python 2
depends on identifiers being ASCII-only byte strings, including -
apparently - parts of the core code. Suggestion: Switch to Python 3,
or if you can't do that, pass your identifiers through str(). When you
do eventually switch to Py3, that won't do anything, but in Py2, it'll
force them to be byte strings. As long as they are actually
ASCII-only, that'll solve your problem.
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: bug or feature in enum34 py2.7 backport?
On Wed, Nov 26, 2014, at 06:29, Mark Summerfield wrote:
> TypeError: type() argument 1 must be string, not unicode
If this is a bug, maybe it is one in type() itself - I get the same
error with type('X', (object,), dict(a=1))
--
https://mail.python.org/mailman/listinfo/python-list
bug or feature in enum34 py2.7 backport?
Hi,
Here are two programs both executed with Python 2.7 with the enum34 backport
and their output. Is this a bug or intended behavior? (It may well be intended
to help ensure that the class name is ASCII for Python 2; but maybe it would be
nicer to check a unicode to see if it is ASCII and if so, use it, and otherwise
raise a more helpful exception?)
# t1.py
from __future__ import print_function
import enum
print(enum.version)
A = enum.Enum("A", "b c")
print(A.b, A.c)
$ python2 t1.py
(1, 0, 3)
A.b A.c
# t2.py
from __future__ import print_function
from __future__ import unicode_literals
import enum
print(enum.version)
A = enum.Enum("A", "b c")
print(A.b, A.c)
$ python2 t2.py
(1, 0, 3)
Traceback (most recent call last):
File "t2.py", line 5, in
A = enum.Enum("A", "b c")
File "/usr/local/lib/python2.7/dist-packages/enum/__init__.py", line 326, in
__call__
return cls._create_(value, names, module=module, type=type)
File "/usr/local/lib/python2.7/dist-packages/enum/__init__.py", line 434, in
_create_
enum_class = metacls.__new__(metacls, class_name, bases, classdict)
File "/usr/local/lib/python2.7/dist-packages/enum/__init__.py", line 188, in
__new__
enum_class = super(EnumMeta, metacls).__new__(metacls, cls, bases,
classdict)
TypeError: type() argument 1 must be string, not unicode
--
https://mail.python.org/mailman/listinfo/python-list
Re: Gvim, bug or feature?
Sorry, this seems a temporary bug of gvim, and they already fix it, post closed. 2012/12/28 Pengfei Hao > When you are using gvim, the command line vim can not open a current > directory os.py, do you think this is a bug or a feature? I like python and > I like gvim, but the vim of gvim is now a python program , it will import > module like os.py first in current directory, so any file the same name as > os.py will cause the vim startup failure. I find this today and I was > shocked about the truth, a editor will be affected by the filename you want > to edit! > > What do you think about this? > -- http://mail.python.org/mailman/listinfo/python-list
Gvim, bug or feature?
When you are using gvim, the command line vim can not open a current directory os.py, do you think this is a bug or a feature? I like python and I like gvim, but the vim of gvim is now a python program , it will import module like os.py first in current directory, so any file the same name as os.py will cause the vim startup failure. I find this today and I was shocked about the truth, a editor will be affected by the filename you want to edit! What do you think about this? -- http://mail.python.org/mailman/listinfo/python-list
Re: Lack of whitespace between contain operator ("in") and other expression tokens doesn't result in SyntaxError: bug or feature?
On Thu, May 3, 2012 at 12:21 PM, Garrett Cooper wrote: > On Thu, May 3, 2012 at 12:03 PM, Ian Kelly wrote: > > On Thu, May 3, 2012 at 12:49 PM, Garrett Cooper > wrote: > >>I was wondering whether this was a parser bug or feature (seems > >> like a bug, in particular because it implicitly encourages bad syntax, > >> but I could be wrong). The grammar notes (for 2.7 at least [1]) don't > >> seem to explicitly require a space between 'in' and another parser > >> token (reserved work, expression, operand, etc), but I could be > >> misreading the documentation. > > > > The grammar doesn't require whitespace there. It tends to be flexible > > about whitespace wherever it's not necessary to resolve ambiguity. > > > >>>> x = [3, 2, 1] > >>>> x [0]if x [1]else x [2] > > 3 > >>>> 1 . real > > 1 > >>>> 1.5.real > > 1.5 > > Sure.. it's just somewhat inconsistent with other expectations in > other languages, and seems somewhat unpythonic. >Not really a big deal (if it was I would have filed a bug > instead), but this was definitely a bit confusing when I ran it > through the interpreter a couple of times... > Thanks! > -Garrett > -- > http://mail.python.org/mailman/listinfo/python-list > For the code prettiness police, check out pep8 and/or pylint. I highly value pylint for projects more than a couple hundred lines. For the whitespace matter that's been beaten to death: http://stromberg.dnsalias.org/~strombrg/significant-whitespace.html I'll include one issue about whitespace here. In FORTRAN 77, the following two statements look very similar, but have completely different meanings, because FORTRAN had too little significant whitespace: DO10I=1,10 DO10I=1.10 The first is the start of a loop, the second is an assignment statement. -- http://mail.python.org/mailman/listinfo/python-list
RE: Lack of whitespace between contain operator ("in") and other expression tokens doesn't result in SyntaxError: bug or feature?
> > Sure.. it's just somewhat inconsistent with other expectations in
> > other languages, and seems somewhat unpythonic.
>
> Never done FORTRAN, have you... Classic FORTRAN even allows
> white-space INSIDE keywords.
Java tends to ignore a lot of spaces as well...though not as much
as classic FORTRAN it would seem.
class test{
public static void main( String []args ){
System.out.
println( "test" );
for (String each : args){
System.out. println( each );
}
System.out. println( args [0] );
}
}
Ramit
Ramit Prasad | JPMorgan Chase Investment Bank | Currencies Technology
712 Main Street | Houston, TX 77002
work phone: 713 - 216 - 5423
--
This email is confidential and subject to important disclaimers and
conditions including on offers for the purchase or sale of
securities, accuracy and completeness of information, viruses,
confidentiality, legal privilege, and legal entity disclaimers,
available at http://www.jpmorgan.com/pages/disclosures/email.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Lack of whitespace between contain operator ("in") and other expression tokens doesn't result in SyntaxError: bug or feature?
On Thu, May 3, 2012 at 12:03 PM, Ian Kelly wrote: > On Thu, May 3, 2012 at 12:49 PM, Garrett Cooper wrote: >> I was wondering whether this was a parser bug or feature (seems >> like a bug, in particular because it implicitly encourages bad syntax, >> but I could be wrong). The grammar notes (for 2.7 at least [1]) don't >> seem to explicitly require a space between 'in' and another parser >> token (reserved work, expression, operand, etc), but I could be >> misreading the documentation. > > The grammar doesn't require whitespace there. It tends to be flexible > about whitespace wherever it's not necessary to resolve ambiguity. > >>>> x = [3, 2, 1] >>>> x [0]if x [1]else x [2] > 3 >>>> 1 . real > 1 >>>> 1.5.real > 1.5 Sure.. it's just somewhat inconsistent with other expectations in other languages, and seems somewhat unpythonic. Not really a big deal (if it was I would have filed a bug instead), but this was definitely a bit confusing when I ran it through the interpreter a couple of times... Thanks! -Garrett -- http://mail.python.org/mailman/listinfo/python-list
Re: Lack of whitespace between contain operator ("in") and other expression tokens doesn't result in SyntaxError: bug or feature?
On Thu, May 3, 2012 at 12:49 PM, Garrett Cooper wrote: > I was wondering whether this was a parser bug or feature (seems > like a bug, in particular because it implicitly encourages bad syntax, > but I could be wrong). The grammar notes (for 2.7 at least [1]) don't > seem to explicitly require a space between 'in' and another parser > token (reserved work, expression, operand, etc), but I could be > misreading the documentation. The grammar doesn't require whitespace there. It tends to be flexible about whitespace wherever it's not necessary to resolve ambiguity. >>> x = [3, 2, 1] >>> x [0]if x [1]else x [2] 3 >>> 1 . real 1 >>> 1.5.real 1.5 -- http://mail.python.org/mailman/listinfo/python-list
Lack of whitespace between contain operator ("in") and other expression tokens doesn't result in SyntaxError: bug or feature?
Hi Python folks!
I came across a piece of code kicking around a sourcebase that
does something similar to the following:
>>> START >>>>
#!/usr/bin/env python
import sys
def foo():
bar = 'abcdefg'
foo = [ 'a' ]
# Should throw SyntaxError?
for foo[0]in bar:
sys.stdout.write('%s' % foo[0])
sys.stdout.write('\n')
sys.stdout.write('%s\n' % (str(foo)))
# Should throw SyntaxError?
if foo[0]in bar:
return True
return False
sys.stdout.write('%r\n' % (repr(sys.version_info)))
sys.stdout.write('%s\n' % (str(foo(
>>> END >>>>
I ran it against several versions of python to ensure that it
wasn't a regression or fixed in a later release:
$ /scratch/bin/bin/python ~/test_bad_in.py
"(2, 3, 7, 'final', 0)"
abcdefg
['g']
True
$ python2.7 ~/test_bad_in.py
"sys.version_info(major=2, minor=7, micro=3, releaselevel='final', serial=0)"
abcdefg
['g']
True
$ python3.2 ~/test_bad_in.py
"sys.version_info(major=3, minor=2, micro=3, releaselevel='final', serial=0)"
abcdefg
['g']
True
$ uname -rom
FreeBSD 9.0-STABLE amd64
$
And even tried a different OS, just to make sure it wasn't a
FreeBSD thing...
% python test_bad_in.py
"(2, 6, 5, 'final', 0)"
abcdefg
['g']
True
% uname -rom
2.6.32-71.el6.x86_64 x86_64 GNU/Linux
I was wondering whether this was a parser bug or feature (seems
like a bug, in particular because it implicitly encourages bad syntax,
but I could be wrong). The grammar notes (for 2.7 at least [1]) don't
seem to explicitly require a space between 'in' and another parser
token (reserved work, expression, operand, etc), but I could be
misreading the documentation.
Thanks!
-Garrett
1. http://docs.python.org/reference/grammar.html
--
http://mail.python.org/mailman/listinfo/python-list
Re: zlib.decompress fails, zlib.decompressobj succeeds - bug or feature?
Hi, > > Do you mean, that you would then expect the decompressobj method to > > fail as well? > > Yes. > > > But, no, d.flush() returns the empty string after decompressing > > ``data``. > > Hmm, then it's a bug. Can you report it tohttp://bugs.python.org? I will - thanks for your advice, Matthew -- http://mail.python.org/mailman/listinfo/python-list
Re: zlib.decompress fails, zlib.decompressobj succeeds - bug or feature?
On Sun, 9 May 2010 09:25:16 -0700 (PDT) Matthew Brett wrote: > > How about: > > > > d = zlib.decompressobj() > > out = d.decompress(data) + d.flush() > > Do you mean, that you would then expect the decompressobj method to > fail as well? Yes. > But, no, d.flush() returns the empty string after decompressing > ``data``. Hmm, then it's a bug. Can you report it to http://bugs.python.org ? Thank you Antoine. -- http://mail.python.org/mailman/listinfo/python-list
Re: zlib.decompress fails, zlib.decompressobj succeeds - bug or feature?
Hi, Thanks for the reply. > > If instead I do this: > > > out = zlib.decompressobj().decompress(data) > > How about: > > d = zlib.decompressobj() > out = d.decompress(data) + d.flush() Do you mean, that you would then expect the decompressobj method to fail as well? But, no, d.flush() returns the empty string after decompressing ``data``. Thanks again, Matthew -- http://mail.python.org/mailman/listinfo/python-list
Re: zlib.decompress fails, zlib.decompressobj succeeds - bug or feature?
On Sun, 9 May 2010 01:28:14 -0700 (PDT) Matthew Brett wrote: > > If instead I do this: > > out = zlib.decompressobj().decompress(data) How about: d = zlib.decompressobj() out = d.decompress(data) + d.flush() ? Notice the documentation for decompressobj.decompress (emphasis mine): “Decompress string, returning a string containing the uncompressed data corresponding to *at least part* of the data in string”. -- http://mail.python.org/mailman/listinfo/python-list
zlib.decompress fails, zlib.decompressobj succeeds - bug or feature?
Hi,
I sorry if this is a bad place to ask, but I wanted to find out if the
behavior I'm seeing is a bug.
I maintain scipy's matlab file readers, and I came across a zlib
compressed string that causes a zlib error on decompression, but only
with zlib.decompress, not zlib.decompressobj.
I saved the original compressed string as a binary file at
http://dl.dropbox.com/u/794947/mat.bin
Now if I do:
import zlib
data = open('mat.bin', 'rb').read()
out = zlib.decompress(data)
I get an error : Error -5 while decompressing data)
If instead I do this:
out = zlib.decompressobj().decompress(data)
I get a usable uncompressed string. I was expecting these two calls
to do the same thing. Is that expectation right? If not, is there
somewhere I could find out why?
Thanks a lot,
Matthew
--
http://mail.python.org/mailman/listinfo/python-list
Re: Bug or feature: double strings as one
Jan Kaliszewski wrote: 09-08-2009 o 23:43:14 r wrote: #-- el bueno --# "hello i am a very long string that\ does not like newlines so please \ escape me, Thank you!" You probably ment: """hello i am... [etc.] Anyway... You're right that generally it's good idea to define dialog prompts and such stuff separately rather that to hardcode it, especially in big projects. Then certainly multiline string literals are useful (though, if you need to get rid of newlines, IMHO "el feo" method is more elegant and less error prone than your "el bueno" [possible invisible space after '\']). But there are plenty of other situations when it's better (in practice) to have strings (even long) together with your code, e.g. log information for debugging, or Here's an idea that you're probably going to hate: indented strings. :-) A string prefixed with 'i' would be an 'indented' string. Leading space and tab characters at the start of the string (just after the quote) or the start of each line within a multiline string would be ignored. >>> """Line 1 Line 2 """ 'Line 1\n Line 2\n' >>> i"""Line 1 Line 2 """ 'Line 1\nLine 2\n' An additional feature could be to make '\ ' == ' ', perhaps only for indented strings if you're worried that it could breaking existing code: >>> i"""Line 1 \ Line 2 """ 'Line 1\n Line 2\n' This would save you having to write '\x20'. -- http://mail.python.org/mailman/listinfo/python-list
Re: Bug or feature: double strings as one
09-08-2009 o 23:43:14 r wrote: #-- el bueno --# "hello i am a very long string that\ does not like newlines so please \ escape me, Thank you!" You probably ment: """hello i am... [etc.] Anyway... You're right that generally it's good idea to define dialog prompts and such stuff separately rather that to hardcode it, especially in big projects. Then certainly multiline string literals are useful (though, if you need to get rid of newlines, IMHO "el feo" method is more elegant and less error prone than your "el bueno" [possible invisible space after '\']). But there are plenty of other situations when it's better (in practice) to have strings (even long) together with your code, e.g. log information for debugging, or Cheers, *j -- http://mail.python.org/mailman/listinfo/python-list
Re: Bug or feature: double strings as one
#-- el bueno --# "hello i am a very long string that\ does not like newlines so please \ escape me, Thank you!" #-- el malo --# "hello i am a very long string that"+ "does not like newlines but i have no"+ "idea what to do with myself" #-- el feo --# "hello i am a very long string that" "does not like newlines but i have no" "idea what to do with myself" just ideas people! -- http://mail.python.org/mailman/listinfo/python-list
Re: Bug or feature: double strings as one
On Aug 9, 12:10 pm, "Jan Kaliszewski" wrote: ..(snip) > Sorry, you are wrong, '''-way would be usefull only if: > > * you want to have '\n' in each place where you wrap the > literal in your code, > > and > > * you use '''-literal at a module (non-indented) level > > or you need not only '\n'-s but also indentations > (dependent on indentation of your code), > > or such ugly indentation is ok for you: > > some indentated code... > prompt = '''quite long string %s quite long string > ''' quite long string quite long string %s > ''' quite %s long string quite long string > ''' > some indentated code... > > That's why I wrote it's "useless in such cases." @ Jan & Anny No, of course putting a multi-line string inside a block does not solve anything. What i meant for you to do is to declare the string outside the block or as a module level Constant. i typically declare all multi-line strings (ig for dialog prompts etc..) right after my globals at the top of my modules or within an imported module like... from thisModuleConstants import * -- http://mail.python.org/mailman/listinfo/python-list
Re: Bug or feature: double strings as one
09-08-2009 r wrote:
On Aug 8, 12:43 pm, "Jan Kaliszewski" wrote:
08-08-2009 Steven D'Aprano wrote:
...(snip)
I use it very often, e.g.:
afunction('quite long string %s quite long string '
'quite long string quite long string %s '
'quite %s long string quite long string'
% (variable1, variable2, variable3))
It seems nicer to me than:
afunction(('quite long string %s quite long string '
+ 'quite long string quite long string %s '
+ 'quite %s long string quite long string')
% (variable1, variable2, variable3))
(Note that multiline-'''-strings are usless in such cases).
uhh? A much better way to handle such a problem is like this...
prompt1 = '''
Some people like to use %s
ways of doing things just
so they can support their %s
way of coding
'''
Sorry, you are wrong, '''-way would be usefull only if:
* you want to have '\n' in each place where you wrap the
literal in your code,
and
* you use '''-literal at a module (non-indented) level
or you need not only '\n'-s but also indentations
(dependent on indentation of your code),
or such ugly indentation is ok for you:
some indentated code...
prompt = '''quite long string %s quite long string
''' quite long string quite long string %s
''' quite %s long string quite long string
'''
some indentated code...
That's why I wrote it's "useless in such cases."
Regards,
*j
--
Jan Kaliszewski (zuo)
--
http://mail.python.org/mailman/listinfo/python-list
Re: Bug or feature: double strings as one
r wrote: > On Aug 8, 12:43 pm, "Jan Kaliszewski" wrote: >> (Note that multiline-'''-strings are usless in such cases). >> > > uhh? A much better way to handle such a problem is like this... > > prompt1 = ''' > Some people like to use %s > ways of doing things just > so they can support their %s > way of coding > ''' Oh wow, you so need to work on your reading comprehension skills! Didn't you notice Jan's comment that multiline ''' strings are useless??? They add extra newlines into the string which aren't wanted. > WOW!, that just somehow looks more professional to me? I hate to long > strings in the middle of a code block. Please be smart when writing > code people!! Because totally failing to pay attention to the requirements is "smart". -- http://mail.python.org/mailman/listinfo/python-list
Re: Bug or feature: double strings as one
On Aug 8, 12:43 pm, "Jan Kaliszewski" wrote:
> 08-08-2009 Steven D'Aprano wrote:
...(snip)
> I use it very often, e.g.:
>
> afunction('quite long string %s quite long string '
> 'quite long string quite long string %s '
> 'quite %s long string quite long string'
> % (variable1, variable2, variable3))
>
> It seems nicer to me than:
>
> afunction(('quite long string %s quite long string '
> + 'quite long string quite long string %s '
> + 'quite %s long string quite long string')
> % (variable1, variable2, variable3))
>
> (Note that multiline-'''-strings are usless in such cases).
>
uhh? A much better way to handle such a problem is like this...
prompt1 = '''
Some people like to use %s
ways of doing things just
so they can support their %s
way of coding
'''
afunction(prompt1 %(var1, var2))
WOW!, that just somehow looks more professional to me? I hate to long
strings in the middle of a code block. Please be smart when writing
code people!!
--
http://mail.python.org/mailman/listinfo/python-list
Re: Bug or feature: double strings as one
08-08-2009 Steven D'Aprano wrote:
On Fri, 07 Aug 2009 17:35:28 +, kj wrote:
I fail to see why
x = ("first part of a very long string "
"second part of a very long string")
That's done by the compiler at compile time and is fast.
Moreover, it's also more readable, when you use str calling its
methods or using formatting on it.
I use it very often, e.g.:
afunction('quite long string %s quite long string '
'quite long string quite long string %s '
'quite %s long string quite long string'
% (variable1, variable2, variable3))
It seems nicer to me than:
afunction(('quite long string %s quite long string '
+ 'quite long string quite long string %s '
+ 'quite %s long string quite long string')
% (variable1, variable2, variable3))
(Note that multiline-'''-strings are usless in such cases).
*j
--
Jan Kaliszewski (zuo)
--
http://mail.python.org/mailman/listinfo/python-list
Re: Bug or feature: double strings as one
"Carl Banks" wrote: http://www.geocities.com/connorbd/tarpit/magentaaarm.html (It's on Geocities, yikes, someone better archive that) http://web.archive.org/web/*/http://www.geocities.com/connorbd/tarpit/magentaaarm.html :) -- http://mail.python.org/mailman/listinfo/python-list
Re: Bug or feature: double strings as one
Unknown wrote: On 2009-08-07, Scott David Daniels wrote: Grant Edwards wrote: On 2009-08-07, durumdara wrote: In other languages, like Delphi (Pascal), Javascript, SQL, etc., I must concatenate the strings with some sign, like "+" or "||". In other languages like Ruby, awk, C, C++, etc. adjacent string constants are concatenated. I must learn this "etc." language, I hear it mentioned all the time :-) Definitely. Not only does it have _all_ the features, it even manages to simultaneously have several mutually-exclusive features. I have tried google for this "etc." language but failed dismally. Does it belong here? http://www.thefreecountry.com/compilers/esoteric.shtml -- Kindest regards. Mark Lawrence. -- http://mail.python.org/mailman/listinfo/python-list
Re: Bug or feature: double strings as one
On Aug 7, 10:00 am, Grant Edwards wrote: > On 2009-08-07, Scott David Daniels wrote: > > > Grant Edwards wrote: > >> On 2009-08-07, durumdara wrote: > >>> In other languages, like Delphi (Pascal), Javascript, SQL, etc., I > >>> must concatenate the strings with some sign, like "+" or "||". > > >> In other languages like Ruby, awk, C, C++, etc. adjacent string > >> constants are concatenated. > > > I must learn this "etc." language, I hear it mentioned all the time :-) > > Definitely. Not only does it have _all_ the features, it even > manages to simultaneously have several mutually-exclusive > features. http://www.geocities.com/connorbd/tarpit/magentaaarm.html (It's on Geocities, yikes, someone better archive that) Carl Banks -- http://mail.python.org/mailman/listinfo/python-list
Re: Bug or feature: double strings as one
On Aug 7, 10:31 pm, Steven D'Aprano wrote: ...(snip excessive showmanship) :-) Ah Steven thats a real nice "snappy comeback" and some may get blinded by the "black magic" but basically all you are saying is that "version a" takes less overhead than "version b", compilation wise... but let's dig a little deeper shall we? First of all, i don't know about you but i don't set around all day hard coding string data into my programs so the nano second difference gained between auto-magic-string-concatination and "s1"+"s2"+"sN" really doesn't justify a feature(bug??) like this that breaks the Zen wide open. Sadly all it serves is to confuse new comers and contribute line noise to the tutorial -- of which there is too much already! Sure it's a nice parlor trick, but not much more... Q: Steven, how often do you actually use this feature, i mean *really* use it? -- http://mail.python.org/mailman/listinfo/python-list
Re: Bug or feature: double strings as one
On Fri, 07 Aug 2009 17:35:28 +, kj wrote:
> I fail to see why
>
> x = ("first part of a very long string "
> "second part of a very long string")
That's done by the compiler at compile time and is fast.
> is so much better than
>
> x = ("first part of a very long string " +
> "second part of a very long string")
That's done by the Python virtual machine at runtime and creates two
strings, then passes them to a method, which creates a third string, then
(usually) disposes of the first two strings.
Except for some versions of the CPython implementation, which has a
keyhole compiler which folds constants at runtime. But it's a simple
optimizer, easy to defeat:
>>> import dis
>>> dis.dis(compile("s = ''; s + 'a' + 'b'", '', 'exec'))
1 0 LOAD_CONST 0 ('')
3 STORE_NAME 0 (s)
6 LOAD_NAME0 (s)
9 LOAD_CONST 1 ('a')
12 BINARY_ADD
13 LOAD_CONST 2 ('b')
16 BINARY_ADD
17 POP_TOP
18 LOAD_CONST 3 (None)
21 RETURN_VALUE
>>>
>>> dis.dis(compile("s = ''; s + 'a' 'b'", '', 'exec'))
1 0 LOAD_CONST 0 ('')
3 STORE_NAME 0 (s)
6 LOAD_NAME0 (s)
9 LOAD_CONST 1 ('ab')
12 BINARY_ADD
13 POP_TOP
14 LOAD_CONST 2 (None)
17 RETURN_VALUE
--
Steven
--
http://mail.python.org/mailman/listinfo/python-list
Re: Bug or feature: double strings as one
It sure doesn't get any more obivous than...
"string1" + "string2"
Although i much prefer string formatting to concatenation for almost
all cases except the most simple. This auto-magic conacatenation of
strings is unintuitive and completely moronic if you ask my opinion. I
blow chunks when i see this type of code, and the result from it, and
so should my interpretor!
"string1" "string2" --> syntax error you moron!
If you are wanting to create shortcuts, do them where they make sense
and can serve a useful purpose...
t = ('1' "word" 33.3)
l = [1 2 3 (4 5)]
d = {keyname:value keyname:value etc...}
KISS people!
--
http://mail.python.org/mailman/listinfo/python-list
Re: Bug or feature: double strings as one
On Aug 7, 7:31 am, durumdara wrote: > Hi! > > I found an interesting thing in Python. > Today one of my "def"s got wrong result. ...(snip) I think it's a completely useless feature and i have never used it even once! This so-called "feature" seems a direct contridiction to the zen... """There should be one-- and preferably only one --obvious way to do it. """ -- http://mail.python.org/mailman/listinfo/python-list
Re: Bug or feature: double strings as one
On Aug 8, 3:43 am, alex23 wrote:
> kj wrote:
> > Feature, as others have pointed out, though I fail to see the need
> > for it, given that Python's general syntax for string (as opposed
> > to string literal) concatenation is already so convenient. I.e.,
> > I fail to see why
>
> > x = ("first part of a very long string "
> > "second part of a very long string")
>
> > is so much better than
>
> > x = ("first part of a very long string " +
> > "second part of a very long string")
>
> My impression is it's mostly for one of clarity. It's especially
> useful with regular expressions, as it allows for comments to document
> each element of the regex (following example shamelessly taken from
> the docs (albeit with personal preferences on formatting))):
>
> re.compile(
> "[A-Za-z_]" # letter or underscore
> "[A-Za-z0-9_]*" # letter, digit or underscore
> )
>
> Not having the plus sign present does assist (IMO) in the ease of
> parsing the regex.
> re.compile(
re.VERBOSE?
--
http://mail.python.org/mailman/listinfo/python-list
Re: Bug or feature: double strings as one
durumdara: > I wanna ask that is a bug or is it a feature? For me it's a bug-prone antifeature. Bye, bearophile -- http://mail.python.org/mailman/listinfo/python-list
Re: Bug or feature: double strings as one
Grant Edwards wrote: > Definitely. Not only does it have _all_ the features, it even > manages to simultaneously have several mutually-exclusive > features. Sounds a bit like Perl. -- http://mail.python.org/mailman/listinfo/python-list
Re: Bug or feature: double strings as one
kj wrote:
> Feature, as others have pointed out, though I fail to see the need
> for it, given that Python's general syntax for string (as opposed
> to string literal) concatenation is already so convenient. I.e.,
> I fail to see why
>
> x = ("first part of a very long string "
> "second part of a very long string")
>
> is so much better than
>
> x = ("first part of a very long string " +
> "second part of a very long string")
My impression is it's mostly for one of clarity. It's especially
useful with regular expressions, as it allows for comments to document
each element of the regex (following example shamelessly taken from
the docs (albeit with personal preferences on formatting))):
re.compile(
"[A-Za-z_]" # letter or underscore
"[A-Za-z0-9_]*" # letter, digit or underscore
)
Not having the plus sign present does assist (IMO) in the ease of
parsing the regex.
re.compile(
--
http://mail.python.org/mailman/listinfo/python-list
Re: Bug or feature: double strings as one
In Peter Otten <__pete...@web.de> writes:
>durumdara wrote:
>> I found an interesting thing in Python.
>> Today one of my "def"s got wrong result.
>>
>> When I checked the code I saw that I miss a "," from the list.
>>
>> l = ['ó' 'Ã']
>>
>> Interesting, that Python handle them as one string.
>>
>> print ['ó' 'Ã']
>> ['\xf3\xd3']
>>
>> I wanna ask that is a bug or is it a feature?
Feature, as others have pointed out, though I fail to see the need
for it, given that Python's general syntax for string (as opposed
to string literal) concatenation is already so convenient. I.e.,
I fail to see why
x = ("first part of a very long string "
"second part of a very long string")
is so much better than
x = ("first part of a very long string " +
"second part of a very long string")
FWIW, C has the same concatenation feature for string literals.
E.g., the following is valid C:
printf("first part of a very long string "
"second part of a very long string\n");
kynn
--
http://mail.python.org/mailman/listinfo/python-list
Re: Bug or feature: double strings as one
On 2009-08-07, Scott David Daniels wrote: > Grant Edwards wrote: >> On 2009-08-07, durumdara wrote: >>> In other languages, like Delphi (Pascal), Javascript, SQL, etc., I >>> must concatenate the strings with some sign, like "+" or "||". >> >> In other languages like Ruby, awk, C, C++, etc. adjacent string >> constants are concatenated. > > I must learn this "etc." language, I hear it mentioned all the time :-) Definitely. Not only does it have _all_ the features, it even manages to simultaneously have several mutually-exclusive features. -- Grant Edwards grante Yow! I'm meditating on at the FORMALDEHYDE and the visi.comASBESTOS leaking into my PERSONAL SPACE!! -- http://mail.python.org/mailman/listinfo/python-list
Re: Bug or feature: double strings as one
Grant Edwards wrote: On 2009-08-07, durumdara wrote: In other languages, like Delphi (Pascal), Javascript, SQL, etc., I must concatenate the strings with some sign, like "+" or "||". In other languages like Ruby, awk, C, C++, etc. adjacent string constants are concatenated. I must learn this "etc." language, I hear it mentioned all the time :-) --Scott David Daniels scott.dani...@acm.org -- http://mail.python.org/mailman/listinfo/python-list
Re: Bug or feature: double strings as one
On 2009-08-07, durumdara wrote: > Hi! > > I found an interesting thing in Python. > Today one of my "def"s got wrong result. > > When I checked the code I saw that I miss a "," from the list. > > l = ['?' '?'] > > Interesting, that Python handle them as one string. > > print ['?' '?'] > ['\xf3\xd3'] > > I wanna ask that is a bug or is it a feature? You "wanna"? > In other languages, like Delphi (Pascal), Javascript, SQL, etc., I > must concatenate the strings with some sign, like "+" or "||". In other languages like Ruby, awk, C, C++, etc. adjacent string constants are concatenated. -- Grant Edwards grante Yow! Is it clean in other at dimensions? visi.com -- http://mail.python.org/mailman/listinfo/python-list
Re: Bug or feature: double strings as one
durumdara wrote: > I found an interesting thing in Python. > Today one of my "def"s got wrong result. > > When I checked the code I saw that I miss a "," from the list. > > l = ['ó' 'Ó'] > > Interesting, that Python handle them as one string. > > print ['ó' 'Ó'] > ['\xf3\xd3'] > > I wanna ask that is a bug or is it a feature? Feature: http://docs.python.org/reference/lexical_analysis.html#string-literal-concatenation Peter -- http://mail.python.org/mailman/listinfo/python-list
Re: Bug or feature: double strings as one
durumdara schrieb:
Hi!
I found an interesting thing in Python.
Today one of my "def"s got wrong result.
When I checked the code I saw that I miss a "," from the list.
l = ['ó' 'Ó']
Interesting, that Python handle them as one string.
print ['ó' 'Ó']
['\xf3\xd3']
I wanna ask that is a bug or is it a feature?
In other languages, like Delphi (Pascal), Javascript, SQL, etc., I
must concatenate the strings with some sign, like "+" or "||".
This technic is avoid the mistyping, like today. But in python I can
miss the concat sign, and I got wrong result...
It's a feature. It is sometimes used in cases where you want to split a
longer text into several lines, but without introducing newlines.
like this (the parentheses are there for the parser not to puke):
foo = ("foobarbaz"
"padamm")
It has the potential to produce errors as you have seen them, though.
Diez
--
http://mail.python.org/mailman/listinfo/python-list
Bug or feature: double strings as one
Hi! I found an interesting thing in Python. Today one of my "def"s got wrong result. When I checked the code I saw that I miss a "," from the list. l = ['ó' 'Ó'] Interesting, that Python handle them as one string. print ['ó' 'Ó'] ['\xf3\xd3'] I wanna ask that is a bug or is it a feature? In other languages, like Delphi (Pascal), Javascript, SQL, etc., I must concatenate the strings with some sign, like "+" or "||". This technic is avoid the mistyping, like today. But in python I can miss the concat sign, and I got wrong result... Thanks for your help and for your answer: dd -- http://mail.python.org/mailman/listinfo/python-list
Re: defaultdict's bug or feature?
On Sat, May 23, 2009 at 2:03 AM, Rhodri James wrote: > I asked you not to top-post. Please put your replies *below* the > messages you're quoting, not above. It's much easier to understand > the conversation that we're having if you do that, and much more > aggravating if you don't. > I misunderstand you last email, thanks. > > On Fri, 22 May 2009 09:53:04 +0100, Red Forks wrote: > > Yes, you maybe right. When use defaultdict, should not rely get() method >> anymore, d[] is just enough. >> > > Almost. You should rely on get() to do what it says, not what you think > it should do. That's generally true, by the way; when the Fine Manual > says that a class, function or method will do one thing, expecting it to > do something else is unreasonable. > > Actually, I steal defaultdict to do other things: >> >> class OnloadDict(defaultdict): >>def __init__(self, onload): >>self.__onload = onload >> >>def __missing__(self, key): >>result = self.__onload(key) >>if not result: >>raise KeyError >> >>self[key] = result >>return result >> >>def get(self, key, default = None): >>''' defaultdict.get() won't call __missing__, so override ''' >>try: >>return self[key] >>except KeyError: >>return default >> >> OnloadDict, is like a cache. When the value is not in dict, using 'onload' >> function to load the value by the key. >> When no value correspond to a key, a KeyError will raised. So I need a >> *safer* version 'get()' method. >> > > Why are you so determined to (ab)use get() on your class? You should > only be calling OnloadDict.get() if you really mean "get me the value > associated with this key, or the default I'm telling you about *right* > *now* if there isn't one." The key point is: "what key/value pairs should in defaultdict". I think any key/default pair(they'll add to dict when you ask for it), maybe you think only manual added pairs. defaultdict break dict rules, that a query method (d[key]) should not modify dict, so another query method (the get() method) break default rule is not a big deal. Never mind, my "get()" method hack works OK. > > > Aside from that, this is neat. Strictly you should call > defaultdict.__init__(self) in your __init__() function just in case > defaultdict needs any setup that you aren't doing (which it does, but > you override __missing__() so it never notices that it doesn't have > a default_factory). You get away with it here, but it's not a good > habit to get into. > I'm new to python, adding 'defaultdict.__init__()' call would be nice. In other languages, base class's default constructor is automaticlly called. > > -- > Rhodri James *-* Wildebeeste Herder to the Masses > -- > http://mail.python.org/mailman/listinfo/python-list > -- http://mail.python.org/mailman/listinfo/python-list
Re: defaultdict's bug or feature?
I asked you not to top-post. Please put your replies *below* the messages you're quoting, not above. It's much easier to understand the conversation that we're having if you do that, and much more aggravating if you don't. On Fri, 22 May 2009 09:53:04 +0100, Red Forks wrote: Yes, you maybe right. When use defaultdict, should not rely get() method anymore, d[] is just enough. Almost. You should rely on get() to do what it says, not what you think it should do. That's generally true, by the way; when the Fine Manual says that a class, function or method will do one thing, expecting it to do something else is unreasonable. Actually, I steal defaultdict to do other things: class OnloadDict(defaultdict): def __init__(self, onload): self.__onload = onload def __missing__(self, key): result = self.__onload(key) if not result: raise KeyError self[key] = result return result def get(self, key, default = None): ''' defaultdict.get() won't call __missing__, so override ''' try: return self[key] except KeyError: return default OnloadDict, is like a cache. When the value is not in dict, using 'onload' function to load the value by the key. When no value correspond to a key, a KeyError will raised. So I need a *safer* version 'get()' method. Why are you so determined to (ab)use get() on your class? You should only be calling OnloadDict.get() if you really mean "get me the value associated with this key, or the default I'm telling you about *right* *now* if there isn't one." Aside from that, this is neat. Strictly you should call defaultdict.__init__(self) in your __init__() function just in case defaultdict needs any setup that you aren't doing (which it does, but you override __missing__() so it never notices that it doesn't have a default_factory). You get away with it here, but it's not a good habit to get into. -- Rhodri James *-* Wildebeeste Herder to the Masses -- http://mail.python.org/mailman/listinfo/python-list
Re: defaultdict's bug or feature?
Yes, you maybe right. When use defaultdict, should not rely get() method
anymore, d[] is just enough. When a function return a defaultdict, but
people don't know it, so:
d = load_map()
# if she call d['a'], everything is OK but
# when call d.get('a'), she is always get None.
# Why she call d.get('a'), not d['a'], because she don't want to provider
default value herself (she didn't know it is a defaultdict)
It is just wield, call d[''a'] Ok, not get('a').
Sorry my poor english. Maybe somebody don't catch my mind, or maybe a little
rude.
I'm using and learning python about 2 weeks ago, spent me three hrs to find
the problem, almost drive me mad.
Maybe other like me, find some inconvience on this.
--
Actually, I steal defaultdict to do other things:
class OnloadDict(defaultdict):
def __init__(self, onload):
self.__onload = onload
def __missing__(self, key):
result = self.__onload(key)
if not result:
raise KeyError
self[key] = result
return result
def get(self, key, default = None):
''' defaultdict.get() won't call __missing__, so override '''
try:
return self[key]
except KeyError:
return default
OnloadDict, is like a cache. When the value is not in dict, using 'onload'
function to load the value by the key.
When no value correspond to a key, a KeyError will raised. So I need a
*safer* version 'get()' method.
On Fri, May 22, 2009 at 12:35 PM, Rhodri James
wrote:
> Please don't top-post, it makes the thread of argument hard to follow.
>
> On Fri, 22 May 2009 01:44:37 +0100, Red Forks wrote:
>
> You mean 'get' method should not alter the dict, does 'dict[key]' should
>> not
>> alter the dict either?
>>
>> d = defaultdict(set)
>> assert len(d) == 0
>> print d[1]
>> assert len(d) == 1
>>
>> auto insert value to dict, when value is not in dict, is what defaultdict
>> try to do.
>>
>
> Behaviour you are deliberately avoiding by calling `get`, since that
> explicitly behaves the same way that it does for dicts. You're doing
> two different things through two different interfaces with two different
> specs. Why are you expecting them to have the same effect?
>
>
> --
> Rhodri James *-* Wildebeeste Herder to the Masses
> --
> http://mail.python.org/mailman/listinfo/python-list
>
--
http://mail.python.org/mailman/listinfo/python-list
Re: defaultdict's bug or feature?
Please don't top-post, it makes the thread of argument hard to follow. On Fri, 22 May 2009 01:44:37 +0100, Red Forks wrote: You mean 'get' method should not alter the dict, does 'dict[key]' should not alter the dict either? d = defaultdict(set) assert len(d) == 0 print d[1] assert len(d) == 1 auto insert value to dict, when value is not in dict, is what defaultdict try to do. Behaviour you are deliberately avoiding by calling `get`, since that explicitly behaves the same way that it does for dicts. You're doing two different things through two different interfaces with two different specs. Why are you expecting them to have the same effect? -- Rhodri James *-* Wildebeeste Herder to the Masses -- http://mail.python.org/mailman/listinfo/python-list
Re: defaultdict's bug or feature?
Red Forks wrote:
You mean 'get' method should not alter the dict, does 'dict[key]' should
not alter the dict either?
d = defaultdict(set)
assert len(d) == 0
print d[1]
assert len(d) == 1
auto insert value to dict, when value is not in dict, is what
defaultdict try to do.
That's the behaviour which makes defaultdict so useful. Compare using
defaultdict:
d = defaultdict(int)
and then:
d["foo"] += 1
to using dict:
d = {}
and then:
try:
d["foo"] += 1
except KeyError:
d["foo"] = 1
or:
d["foo"] = d.get("foo", 0) + 1
--
http://mail.python.org/mailman/listinfo/python-list
Re: defaultdict's bug or feature?
You mean 'get' method should not alter the dict, does 'dict[key]' should not
alter the dict either?
d = defaultdict(set)
assert len(d) == 0
print d[1]
assert len(d) == 1
auto insert value to dict, when value is not in dict, is what defaultdict
try to do.
On Fri, May 22, 2009 at 7:46 AM, Rhodri James
wrote:
> On Thu, 21 May 2009 13:07:50 +0100, Red Forks wrote:
>
> from collections import defaultdict
>>
>> d = defaultdict(set)
>> assert isinstance(d['a'], set)
>> assert isinstance(d.get('b'), set)
>>
>> d['a'] is ok, and a new set object is insert to d, but d.get('b') won't.
>>
>> It's a bug, or just a feature?
>>
>
> Feature. You're blaming 'get' for doing exactly what it said it would,
> both in returning None and not gratuitously altering the dictionary.
>
> --
> Rhodri James *-* Wildebeeste Herder to the Masses
>
> --
> http://mail.python.org/mailman/listinfo/python-list
>
--
http://mail.python.org/mailman/listinfo/python-list
Re: defaultdict's bug or feature?
On Thu, 21 May 2009 13:07:50 +0100, Red Forks wrote:
from collections import defaultdict
d = defaultdict(set)
assert isinstance(d['a'], set)
assert isinstance(d.get('b'), set)
d['a'] is ok, and a new set object is insert to d, but d.get('b') won't.
It's a bug, or just a feature?
Feature. You're blaming 'get' for doing exactly what it said it would,
both in returning None and not gratuitously altering the dictionary.
--
Rhodri James *-* Wildebeeste Herder to the Masses
--
http://mail.python.org/mailman/listinfo/python-list
Re: defaultdict's bug or feature?
Red Forks wrote:
from collections import defaultdict
d = defaultdict(set)
assert isinstance(d['a'], set)
assert isinstance(d.get('b'), set)
d['a'] is ok, and a new set object is insert to d, but d.get('b') won't.
It's a bug, or just a feature?
A feature.
I think dict.get() method is just a /safe/ version of dict[key], maybe
it should be:
def get(self, key, default = None):
try:
return self[key]
except KeyError:
return default
Isn't that what it does already?
With dict you have the choice of whether to raise an exception or return
a default value if the key is missing.
With defaultdict you have the choice of whether to add the value or
return a default value if the key is missing.
Both classes have their uses.
--
http://mail.python.org/mailman/listinfo/python-list
defaultdict's bug or feature?
from collections import defaultdict
d = defaultdict(set)
assert isinstance(d['a'], set)
assert isinstance(d.get('b'), set)
d['a'] is ok, and a new set object is insert to d, but d.get('b') won't.
It's a bug, or just a feature?
I think dict.get() method is just a *safe* version of dict[key], maybe it
should be:
def get(self, key, default = None):
try:
return self[key]
except KeyError:
return default
--
http://mail.python.org/mailman/listinfo/python-list
Re: print - bug or feature - concatenated format strings in a print statement
On Tue, 17 Mar 2009 22:41:26 -0700, John Machin wrote:
> On Mar 18, 4:19 pm, Matt Nordhoff wrote:
>> The implicit string concatenation is actually done by the compiler; it
>> isn't an operator at all. Look:
>>
>> >>> import dis
>> >>> def f():
>>
>> ... return "foo" "bar"
>> ...>>> dis.dis(f)
>>
>> 2 0 LOAD_CONST 1 ('foobar')
>> 3 RETURN_VALUE
>> --
>
> I think you need better evidence than that obtained by proctologising
> about with dis.dis:
>
> Python 2.5.4 (r254:67916, Dec 23 2008, 15:10:54) [MSC v.1310 32 bit
> (Intel)] onwin32
> Type "help", "copyright", "credits" or "license" for more information.
import dis
def f():
> ...return ('foo') + ('bar')
> ...
dis.dis(f)
> 2 0 LOAD_CONST 3 ('foobar')
> 3 RETURN_VALUE
That's the keyhole optimizer in action. It replaces operations on two
literals at compile-time whenever possible. By memory, that was
introduced by Python 2.4, and implicit string concatenation was
introduced way back in the mists of time. In Python 2.1 we have this:
>>> dis.dis(compile("'ab' 'cd'", '', 'single'))
0 SET_LINENO 0
3 SET_LINENO 1
6 LOAD_CONST 0 ('abcd')
9 PRINT_EXPR
10 LOAD_CONST 1 (None)
13 RETURN_VALUE
>>>
>>> dis.dis(compile("1+1", '', 'single'))
0 SET_LINENO 0
3 SET_LINENO 1
6 LOAD_CONST 0 (1)
9 LOAD_CONST 0 (1)
12 BINARY_ADD
13 PRINT_EXPR
14 LOAD_CONST 1 (None)
17 RETURN_VALUE
I suppose, technically, implicit string concatenation could happen inside
the lexer, or the parser, or some other process, but I think most people
are happy to simplify all of those as "the compiler". Whenever it
happens, the important thing is that it is *not* at runtime.
--
Steven
--
http://mail.python.org/mailman/listinfo/python-list
Re: print - bug or feature - concatenated format strings in a print statement
On Mar 18, 4:19 pm, Matt Nordhoff wrote:
> bdb112 wrote:
> > Thanks for all the replies:
> > I think I see now - % is a binary operator whose precedence rules are
> > shared with the modulo operator regardless of the nature of its
> > arguments, for language consistency.
> > I understand the arguments behind the format method, but hope that the
> > slightly idiosyncratic print( ..% ..) remains, as the vaguely
> > pictorial "printf" format string is clearer for a long line with
> > several arguments.
> > I will use the "implicit string concatenation" to solve my problem but
> > it is a little odd that an "invisible" operator is stronger than a
> > visible one. (+).
>
> The implicit string concatenation is actually done by the compiler; it
> isn't an operator at all. Look:
>
> >>> import dis
> >>> def f():
>
> ... return "foo" "bar"
> ...>>> dis.dis(f)
>
> 2 0 LOAD_CONST 1 ('foobar')
> 3 RETURN_VALUE
> --
I think you need better evidence than that obtained by proctologising
about with dis.dis:
Python 2.5.4 (r254:67916, Dec 23 2008, 15:10:54) [MSC v.1310 32 bit
(Intel)] onwin32
Type "help", "copyright", "credits" or "license" for more information.
>>> import dis
>>> def f():
...return ('foo') + ('bar')
...
>>> dis.dis(f)
2 0 LOAD_CONST 3 ('foobar')
3 RETURN_VALUE
>>>
Cheers,
John
--
http://mail.python.org/mailman/listinfo/python-list
Re: print - bug or feature - concatenated format strings in a print statement
bdb112 wrote:
> Thanks for all the replies:
> I think I see now - % is a binary operator whose precedence rules are
> shared with the modulo operator regardless of the nature of its
> arguments, for language consistency.
> I understand the arguments behind the format method, but hope that the
> slightly idiosyncratic print( ..% ..) remains, as the vaguely
> pictorial "printf" format string is clearer for a long line with
> several arguments.
> I will use the "implicit string concatenation" to solve my problem but
> it is a little odd that an "invisible" operator is stronger than a
> visible one. (+).
The implicit string concatenation is actually done by the compiler; it
isn't an operator at all. Look:
>>> import dis
>>> def f():
... return "foo" "bar"
...
>>> dis.dis(f)
2 0 LOAD_CONST 1 ('foobar')
3 RETURN_VALUE
--
--
http://mail.python.org/mailman/listinfo/python-list
Re: print - bug or feature - concatenated format strings in a print statement
Thanks for all the replies:
I think I see now - % is a binary operator whose precedence rules are
shared with the modulo operator regardless of the nature of its
arguments, for language consistency.
I understand the arguments behind the format method, but hope that the
slightly idiosyncratic print( ..% ..) remains, as the vaguely
pictorial "printf" format string is clearer for a long line with
several arguments.
I will use the "implicit string concatenation" to solve my problem but
it is a little odd that an "invisible" operator is stronger than a
visible one. (+).
On Mar 16, 5:00 pm, bdb112 wrote:
> # is the difference between
> print(" %d, %d, buckle my shoe" % (1,2))
> # and
> print(" %d, " + " %d, buckle my shoe" % (1,2))
> # a bug or a feature?
>
> First output
> ... print(" %d " + " %d, buckle my shoe" % (1,2))
>
> Second output
> TypeError: not all arguments converted during string formatting
>
> Version Info:
> Python 2.5.1 (r251:54863, Oct 30 2007, 13:54:11)
> [GCC 4.1.2 20070925 (Red Hat 4.1.2-33)] on linux2
>
> also
>
> Python 2.5.2 (r252:60911, Feb 21 2008, 13:11:45) [MSC v.1310 32 bit
> (Intel)] on win32
--
http://mail.python.org/mailman/listinfo/python-list
Re: print - bug or feature - concatenated format strings in a print statement
bdb112 wrote:
... the difference between ...
print(" %d, %d, buckle my shoe" % (1,2))
... and ...
print(" %d, " + " %d, buckle my shoe" % (1,2))
# a bug or a feature?
A feature. a + b % c is a + (b % c)
But do note that string constant concatentation is higher priority
than the other operators.
> print(" %d, " " %d, buckle my shoe" % (1,2))
--Scott David Daniels
scott.dani...@acm.org
--
http://mail.python.org/mailman/listinfo/python-list
Re: print - bug or feature - concatenated format strings in a print statement
> On Mar 16, 5:00 pm, bdb112 wrote:
> > # is the difference between
> > print(" %d, %d, buckle my shoe" % (1,2))
> > # and
> > print(" %d, " + " %d, buckle my shoe" % (1,2))
> > # a bug or a feature?
It is correct behavior. On the other hand, it is one of the, well,
bugs, that is avoided by the 'format' method in 3.x.
--
R. David Murray http://www.bitdance.com
--
http://mail.python.org/mailman/listinfo/python-list
Re: print - bug or feature - concatenated format strings in a print statement
> > print(10 + 20 % 7) > a bug or a feature? It is a feature print ((10+20) % 7) -Alex Goretoy http://www.goretoy.com -- http://mail.python.org/mailman/listinfo/python-list
Re: print - bug or feature - concatenated format strings in a print statement
On Mar 16, 7:00 pm, bdb112 wrote:
> # is the difference between
> print(" %d, %d, buckle my shoe" % (1,2))
> # and
> print(" %d, " + " %d, buckle my shoe" % (1,2))
> # a bug or a feature?
Here's a question for you:
Is the difference between
print(30 % 7)
and
print(10 + 20 % 7)
a bug or a feature?
Cheers,
John
--
http://mail.python.org/mailman/listinfo/python-list
Re: print - bug or feature - concatenated format strings in a print statement
#whoops, the first output is actually
1, 2, buckle my shoe
# in case it wasn't obvious
On Mar 16, 5:00 pm, bdb112 wrote:
> # is the difference between
> print(" %d, %d, buckle my shoe" % (1,2))
> # and
> print(" %d, " + " %d, buckle my shoe" % (1,2))
> # a bug or a feature?
>
> First output
> ... print(" %d " + " %d, buckle my shoe" % (1,2))
>
> Second output
> TypeError: not all arguments converted during string formatting
>
> Version Info:
> Python 2.5.1 (r251:54863, Oct 30 2007, 13:54:11)
> [GCC 4.1.2 20070925 (Red Hat 4.1.2-33)] on linux2
>
> also
>
> Python 2.5.2 (r252:60911, Feb 21 2008, 13:11:45) [MSC v.1310 32 bit
> (Intel)] on win32
--
http://mail.python.org/mailman/listinfo/python-list
print - bug or feature - concatenated format strings in a print statement
# is the difference between
print(" %d, %d, buckle my shoe" % (1,2))
# and
print(" %d, " + " %d, buckle my shoe" % (1,2))
# a bug or a feature?
First output
... print(" %d " + " %d, buckle my shoe" % (1,2))
Second output
TypeError: not all arguments converted during string formatting
Version Info:
Python 2.5.1 (r251:54863, Oct 30 2007, 13:54:11)
[GCC 4.1.2 20070925 (Red Hat 4.1.2-33)] on linux2
also
Python 2.5.2 (r252:60911, Feb 21 2008, 13:11:45) [MSC v.1310 32 bit
(Intel)] on win32
--
http://mail.python.org/mailman/listinfo/python-list
Re: __contains__() and overload of in : Bug or Feature ???
[EMAIL PROTECTED] wrote:
> Thanks for your quick response.
>
>>> I need to overload the operator in and let him
>>> return an object ... It seems it is not a
>>> behavior Python expect :
>>>
>> class A:
>>> ...def __contains__(self,a):
>>> ...return 'yop'
>>> ...
>> a=A()
>> print 'toto' in a
>>> True
>> print a.__contains__('toto')
>>> yop
>
>> Not sure what you're trying to achieve,
>
> Using Python as an algebraic parser for
> symbolic mathematical equation and I need
> that the 'in' operator returns an object based
> on its two arguments.
>
>> but the semantics of the "in" operator
>> make it return a boolean value.
>
> That is why I need to overload it.
>
>> The string "yop" evaluates to the boolean
>> value True, as it is not empty.
>
> Does it means that when overloading an operator, python just
> wrap the call to the method and keep control of the returned
> values ??? Is there a way to bypass this wrapping ???
>
Can you not achieve what you wish to do with a conditional
expression?
"yop" if a in b else "nop"
Colin W.
--
http://mail.python.org/mailman/listinfo/python-list
Re: __contains__() and overload of in : Bug or Feature ???
On Fri, 2007-09-21 at 13:57 +, [EMAIL PROTECTED] wrote: > Does it means that when overloading an operator, python just > wrap the call to the method and keep control of the returned > values ??? Is there a way to bypass this wrapping ??? The answers are "No in general, but yes in this case" and "No, not easily." Your problem is that the "in" operator is a comparison operator, which by definition returns either True or False. Python is not meant to be used as a Domain-Specific Language, so if you try to use it as one, you'll run into limitations. The fact that comparison operators always have boolean semantics is one of those limitations. (And yes, I imagine this is a feature, so that callers of comparison operators don't have to worry about checking whether the call really returned a boolean value, they can just rely on the fact that it did.) To bypass this behavior, I suppose you could try to change this by modifying Python's source code directly, but who knows what you might break in the process if you break the contract that "in" always returns True or False. In other words, try to find a different solution. -- Carsten Haese http://informixdb.sourceforge.net -- http://mail.python.org/mailman/listinfo/python-list
Re: __contains__() and overload of in : Bug or Feature ???
[EMAIL PROTECTED] wrote:
> Thanks for your quick response.
>
>>> I need to overload the operator in and let him
>>> return an object ... It seems it is not a
>>> behavior Python expect :
>>>
>> class A:
>>> ...def __contains__(self,a):
>>> ...return 'yop'
>>> ...
>> a=A()
>> print 'toto' in a
>>> True
>> print a.__contains__('toto')
>>> yop
>
>> Not sure what you're trying to achieve,
>
> Using Python as an algebraic parser for
> symbolic mathematical equation and I need
> that the 'in' operator returns an object based
> on its two arguments.
>
>> but the semantics of the "in" operator
>> make it return a boolean value.
>
> That is why I need to overload it.
>
>> The string "yop" evaluates to the boolean
>> value True, as it is not empty.
>
> Does it means that when overloading an operator, python just
> wrap the call to the method and keep control of the returned
> values ??? Is there a way to bypass this wrapping ???
>
Certain aspects of the interpreter's behavior have ot be hard-wired in
order for it to accomplish anything. This is one of the hard-wried
aspects, so unless you want to change the interpreter's implementation
I'm afraid you can't change it.
regards
Steve
--
Steve Holden+1 571 484 6266 +1 800 494 3119
Holden Web LLC/Ltd http://www.holdenweb.com
Skype: holdenweb http://del.icio.us/steve.holden
Sorry, the dog ate my .sigline
--
http://mail.python.org/mailman/listinfo/python-list
Re: __contains__() and overload of in : Bug or Feature ???
"[EMAIL PROTECTED]" <[EMAIL PROTECTED]> writes: >> The string "yop" evaluates to the boolean value True, as it is not >> empty. > > Does it means that when overloading an operator, python just > wrap the call to the method and keep control of the returned > values ??? In case of 'in' operator, it does. -- http://mail.python.org/mailman/listinfo/python-list
__contains__() and overload of in : Bug or Feature ???
Thanks for your quick response.
> > I need to overload the operator in and let him
> > return an object ... It seems it is not a
> > behavior Python expect :
> >
> class A:
> > ...def __contains__(self,a):
> > ...return 'yop'
> > ...
> a=A()
> print 'toto' in a
> > True
> print a.__contains__('toto')
> > yop
>
> Not sure what you're trying to achieve,
Using Python as an algebraic parser for
symbolic mathematical equation and I need
that the 'in' operator returns an object based
on its two arguments.
> but the semantics of the "in" operator
> make it return a boolean value.
That is why I need to overload it.
> The string "yop" evaluates to the boolean
> value True, as it is not empty.
Does it means that when overloading an operator, python just
wrap the call to the method and keep control of the returned
values ??? Is there a way to bypass this wrapping ???
--
http://mail.python.org/mailman/listinfo/python-list
Re: __contains__() : Bug or Feature ???
"[EMAIL PROTECTED]" <[EMAIL PROTECTED]> writes: > I need to overload the operator in and let him return an object > ... It seems it is not a behavior Python expect : Python expects it all right, but it intentionally converts the value to a boolean. The 'in' operator calls PySequence_Contains, which returns a boolean value at the C level. User-supplied __contains__ is implemented as an adaptor in typeobject.c (slot_sq_contains). It takes the value returned by your __contains__ implementation and converts it to 0 or 1. I don't think you can overload 'in' as you want without pervasive changes to CPython source code. -- http://mail.python.org/mailman/listinfo/python-list
Re: __contains__() : Bug or Feature ???
On Fri, 2007-09-21 at 13:08 +, [EMAIL PROTECTED] wrote: > Hi everybody, > > I need to overload the operator in and let him > return an object Why do you think you need to do that? What's the underlying problem you're trying to solve? -- Carsten Haese http://informixdb.sourceforge.net -- http://mail.python.org/mailman/listinfo/python-list
Re: __contains__() : Bug or Feature ???
[EMAIL PROTECTED] wrote: > I need to overload the operator in and let him > return an object ... It seems it is not a > behavior Python expect : > class A: > ...def __contains__(self,a): > ...return 'yop' > ... a=A() print 'toto' in a > True Not sure what you're trying to achieve, but the semantics of the "in" operator make it return a boolean value. The string "yop" evaluates to the boolean value True, as it is not empty. Stefan -- http://mail.python.org/mailman/listinfo/python-list
__contains__() : Bug or Feature ???
Hi everybody,
I need to overload the operator in and let him
return an object ... It seems it is not a
behavior Python expect :
>>> class A:
...def __contains__(self,a):
...return 'yop'
...
>>> a=A()
>>> print 'toto' in a
True
>>> print a.__contains__('toto')
yop
I don't know if it's a bug or a feature but i
really need this overloading and don't know
how to do it ... Furthermore I can't use
a trick of the kind : a |in| b ... because
my overloaded operator must be called by : a in b ...
Is someone could help me ?
--
http://mail.python.org/mailman/listinfo/python-list
Re: is it bug or feature in xml.dom.minidom?
Maksim Kasimov wrote:
> Hi, i'm faced with such a problem when i use xml.dom.minidom:
>
> to append all child nodes from "doc" in "_requ" to "doc" in "_resp", i do the
> following:
>
> _requ =
> minidom.parseString("OneTwo")
> _resp = minidom.parseString("")
Note that these are different documents - this is important later on.
> iSourseTag = _requ.getElementsByTagName('doc')[0]
> iTargetTag = _resp.getElementsByTagName('doc')[0]
>
>
> # it prints me that there are two child nodes
> for iChild in iSourseTag.childNodes:
> print iChild.toxml()
Seems alright.
> # when i walk elements, only first iteration was made
> # and iSourseTag.childNodes now have only one element instead of two
> for iChild in iSourseTag.childNodes:
> iTargetTag.appendChild(iChild)
But since you're taking a node from one document to add it to another,
you should instead use importNode to make that node importable into
the target document:
for iChild in iSourseTag.childNodes:
# 1 or True should cause a deep copy
iNewChild = _resp.importNode(iChild, 1)
iTargetTag.appendChild(iNewChild)
> # it prints me that there is only one child node
> for iChild in iSourseTag.childNodes:
> print iChild.toxml()
That's probably because you've "stolen" the node from its document in
order to add it to the target document - something which is possibly
an artifact of the minidom implementation.
> i'm not sure, whether i append child nodes in properly way, but IMHO it looks
> like a bug.
That minidom does not refuse to let you "move" nodes in this way could
be debated as being a bug or not, but the correct way of copying nodes
is to use importNode.
> My question is how to avoid the "iSourseTag" changes while iterate its nodes?
>
> And, of course, how to append all child nodes to "iTargetTag"?
These questions are hopefully answered above.
Paul
--
http://mail.python.org/mailman/listinfo/python-list
is it bug or feature in xml.dom.minidom?
Hi, i'm faced with such a problem when i use xml.dom.minidom:
to append all child nodes from "doc" in "_requ" to "doc" in "_resp", i do the
following:
_requ =
minidom.parseString("OneTwo")
_resp = minidom.parseString("")
iSourseTag = _requ.getElementsByTagName('doc')[0]
iTargetTag = _resp.getElementsByTagName('doc')[0]
# it prints me that there are two child nodes
for iChild in iSourseTag.childNodes:
print iChild.toxml()
# when i walk elements, only first iteration was made
# and iSourseTag.childNodes now have only one element instead of two
for iChild in iSourseTag.childNodes:
iTargetTag.appendChild(iChild)
# it prints me that there is only one child node
for iChild in iSourseTag.childNodes:
print iChild.toxml()
i'm not sure, whether i append child nodes in properly way, but IMHO it looks
like a bug.
My question is how to avoid the "iSourseTag" changes while iterate its nodes?
And, of course, how to append all child nodes to "iTargetTag"?
Thank for any help.
--
Maksim Kasimov
--
http://mail.python.org/mailman/listinfo/python-list
Re: New os.path.exists() behavior - bug or feature?
FWIW, your code works correctly for me in all respects with Python 2.5
on Windows XP Pro.
I no longer have Python 2.4.x installed, so can't easily do a
comparison.
Perhaps the problem has something to do with Python 2.5 with Windows
2K.
-Martin
On Dec 17 2006, 4:29 pm, "klappnase" <[EMAIL PROTECTED]> wrote:
> Hi all,
> yesterday I installed Python-2.5 and python-2.4.4 on my windows2k box.
> When trying to use os.path.exists() to detect which drives are present
> on the system I noticed that
> these behave differently:
>
> Python 2.4.4 (#71, Oct 18 2006, 08:34:43) [MSC v.1310 32 bit (Intel)]
> on win32
> Type "copyright", "credits" or "license()" for more information.
>
> >>> import os
> >>> for char in 'ABCDEFGHIJKLMNOPQRSTUVWXYZ':if
> >>> os.path.exists('%s:\\' % char):
> print '%s:\\' % char
>
> A:\
> C:\
> D:\
> E:\
>
> ###
>
> Python 2.5 (r25:51908, Sep 19 2006, 09:52:17) [MSC v.1310 32 bit
> (Intel)] on win32
> Type "copyright", "credits" or "license()" for more information.
>
> >>> import os
> >>> for char in 'ABCDEFGHIJKLMNOPQRSTUVWXYZ':if
> >>> os.path.exists('%s:\\' % char):
> print '%s:\\' % char
>
> C:\
>
> When I insert a floppy into A: os.path.exists('A:\\') will return True
> on Python-2.5, too.
> Does anyone know, is this inconsistent behavior a bug or a new feature?
>
> I also noticed that theTixbinaries are no longer present in 2.5, does
> anyone know if it is
> planned to remove them pemanently?
>
> Thanks in advance
>
> Michael
--
http://mail.python.org/mailman/listinfo/python-list
Re: New os.path.exists() behavior - bug or feature?
Martin v. Löwis schrieb: > > Neither, nor. In both cases, the operating system is asked, and gives > this answer. However, in the Windows API, there is no "exists" function > (nor is there on Unix); instead, exists is implemented by calling > several underlying functions. The precise set of functions used did > change between 2.4 and 2.5. > > It is quite difficult to investigate the precise nature of the change > that leads to this change in observable behavior. If you think this is > a bug, it would be best if you could also investigate a patch. > I don't know if it is a bug; at least it is backwards incompatible, which I think is never a good thing. Unfortunately, I am afraid writing a patch is beyond my expertise :( Regards Michael -- http://mail.python.org/mailman/listinfo/python-list
Re: New os.path.exists() behavior - bug or feature?
klappnase schrieb:
> When I insert a floppy into A: os.path.exists('A:\\') will return True
> on Python-2.5, too.
> Does anyone know, is this inconsistent behavior a bug or a new feature?
Neither, nor. In both cases, the operating system is asked, and gives
this answer. However, in the Windows API, there is no "exists" function
(nor is there on Unix); instead, exists is implemented by calling
several underlying functions. The precise set of functions used did
change between 2.4 and 2.5.
It is quite difficult to investigate the precise nature of the change
that leads to this change in observable behavior. If you think this is
a bug, it would be best if you could also investigate a patch.
> I also noticed that the Tix binaries are no longer present in 2.5, does
> anyone know if it is
> planned to remove them pemanently?
That was a mistake, I'll add it back in 2.5.1.
Regards,
Martin
--
http://mail.python.org/mailman/listinfo/python-list
New os.path.exists() behavior - bug or feature?
Hi all,
yesterday I installed Python-2.5 and python-2.4.4 on my windows2k box.
When trying to use os.path.exists() to detect which drives are present
on the system I noticed that
these behave differently:
Python 2.4.4 (#71, Oct 18 2006, 08:34:43) [MSC v.1310 32 bit (Intel)]
on win32
Type "copyright", "credits" or "license()" for more information.
>>> import os
>>> for char in 'ABCDEFGHIJKLMNOPQRSTUVWXYZ':
if os.path.exists('%s:\\' % char):
print '%s:\\' % char
A:\
C:\
D:\
E:\
>>>
###
Python 2.5 (r25:51908, Sep 19 2006, 09:52:17) [MSC v.1310 32 bit
(Intel)] on win32
Type "copyright", "credits" or "license()" for more information.
>>> import os
>>> for char in 'ABCDEFGHIJKLMNOPQRSTUVWXYZ':
if os.path.exists('%s:\\' % char):
print '%s:\\' % char
C:\
>>>
When I insert a floppy into A: os.path.exists('A:\\') will return True
on Python-2.5, too.
Does anyone know, is this inconsistent behavior a bug or a new feature?
I also noticed that the Tix binaries are no longer present in 2.5, does
anyone know if it is
planned to remove them pemanently?
Thanks in advance
Michael
--
http://mail.python.org/mailman/listinfo/python-list
Re: textwrap.dedent() drops tabs - bug or feature?
Steven Bethard wrote: > Thanks for double-checking this for me. I looked at expand_tabs, and > it's part of the definition of the TextWrapper class, which is not > actually used by textwrap.dedent(). So I think the textwrap.dedent() > expanding-of-tabs behavior is still basically undocumented. Ah, good point. I saw dedent() in there with the wrap() and fill() convenience functions which use a TextWrapper internally, but you're quite right that dedent() is different, and in fact merely uses the expandtabs() functionality of the standard string class, so this has nothing to do with the expand_tabs attribute I pointed out. -Peter -- http://mail.python.org/mailman/listinfo/python-list
Re: textwrap.dedent() drops tabs - bug or feature?
Peter Hansen wrote:
> Steven Bethard wrote:
>
>> Note that even though the tabs are internal, they are still removed by
>> textwrap.dedent(). The documentation[1] says:
>
> ...
>
>> So it looks to me like even if this is a "feature" it is undocumented.
>> I'm planning on filing a bug report, but I wanted to check here first
>> in case I'm just smoking something.
>
> While I wouldn't say it's obvious, I believe it is (indirectly?)
> documented and deliberate.
>
> Search for this in the docs:
> """
> expand_tabs
> (default: True) If true, then all tab characters in text will be
> expanded to spaces using the expandtabs() method of text.
> """
Thanks for double-checking this for me. I looked at expand_tabs, and
it's part of the definition of the TextWrapper class, which is not
actually used by textwrap.dedent(). So I think the textwrap.dedent()
expanding-of-tabs behavior is still basically undocumented.
I looked at the source code, and the culprit is the first line of the
function definition:
lines = text.expandtabs().split('\n')
I filed a bug_ report, but left the Category unassigned so that someone
else can decide whether it's a doc bug or a code bug.
STeVe
.. _bug: http://python.org/sf/1361643
--
http://mail.python.org/mailman/listinfo/python-list
Re: textwrap.dedent() drops tabs - bug or feature?
Steven Bethard wrote: > Note that even though the tabs are internal, they are still removed by > textwrap.dedent(). The documentation[1] says: ... > So it looks to me like even if this is a "feature" it is undocumented. > I'm planning on filing a bug report, but I wanted to check here first in > case I'm just smoking something. While I wouldn't say it's obvious, I believe it is (indirectly?) documented and deliberate. Search for this in the docs: """ expand_tabs (default: True) If true, then all tab characters in text will be expanded to spaces using the expandtabs() method of text. """ (This is not to say a specific rewording of the docs to lessen any confusion in this area wouldn't be welcomed.) -Peter -- http://mail.python.org/mailman/listinfo/python-list
textwrap.dedent() drops tabs - bug or feature?
So I've recently been making pretty frequent use of textwrap.dedent() to
allow me to use triple-quoted strings at indented levels of code without
getting the extra spaces prefixed to each line. I discovered today that
not only does textwrap.dedent() strip any leading spaces, but it also
substitutes any internal tabs with spaces. For example::
py> def test():
... x = ('abcd efgh\n'
... 'ijkl mnop\n')
... y = textwrap.dedent('''\
... abcdefgh
... ijklmnop
... ''')
... return x, y
...
py> test()
('abcd\tefgh\nijkl\tmnop\n', 'abcdefgh\nijklmnop\n')
Note that even though the tabs are internal, they are still removed by
textwrap.dedent(). The documentation[1] says:
"""
dedent(text)
Remove any whitespace that can be uniformly removed from the left
of every line in text.
This is typically used to make triple-quoted strings line up with
the left edge of screen/whatever, while still presenting it in the
source code in indented form.
"""
So it looks to me like even if this is a "feature" it is undocumented.
I'm planning on filing a bug report, but I wanted to check here first in
case I'm just smoking something.
STeVe
[1] http://docs.python.org/lib/module-textwrap.html
--
http://mail.python.org/mailman/listinfo/python-list
Re: bug or feature?
Steven D'Aprano wrote: > I suppose someone might be able to come up with code that deliberately > uses this feature for good use argument binding is commonly used for optimization, and to give simple functions persistent storage (e.g. memoization caches). more importantly, it's the standard pydiom for passing object *values* (of any kind) into an inner scope: x = something def myfunc(arg, x=x): # myfunc needs the current value, not whatever x # happens to be when the function is called here's a typical gotcha: for i in range(10): def cb(): print "slot", i, "fired" register_callback(slot=i, callback=cb) to make this work as expected, you have to do for i in range(10): def cb(i=i): print "slot", i, "fired" register_callback(slot=i, callback=cb) -- http://mail.python.org/mailman/listinfo/python-list
Re: bug or feature?
Ben Sizer wrote: > Fredrik Lundh wrote: > > >>it's also mentioned in chapter 4 of the tutorial: >> >>http://docs.python.org/tut/node6.html#SECTION00671 >> >> "*Important warning*: The default value is evaluated only once. This >>makes a difference when the default is a mutable object such as a list, >>dictionary, or instances of most classes. " > > > Perhaps it would be a good idea if Python actually raised a warning > (SyntaxWarning?) if you use an unnamed list or dict as a default > argument. This would doubtless help quite a few beginners. And for > people who really do want that behaviour, working around the warning > should involve minimal extra code, with extra clarity thrown in for > free. > This would have to be extended to any mutable object. How does the compiler know which objects are mutable? This would not be a good change. regards Steve -- Steve Holden +44 150 684 7255 +1 800 494 3119 Holden Web LLC www.holdenweb.com PyCon TX 2006 www.python.org/pycon/ -- http://mail.python.org/mailman/listinfo/python-list
Re: bug or feature?
beza1e1:
> Coming back from a bug hunt, i am not sure what to think of this python
> behaviour. Here is a demo program:
>
> class A:
>def __init__(self, lst=[]):
> self.lst = lst
>
> a = A()
> b = A()
> b.lst.append("hallo")
> print a.lst # output: ["hallo"]
>
> The point seems to be, that lst=[] creates a class attribute (correct
> name?), which is shared by all instances of A. So a.lst ist the same
> object as b.lst, despite the fact, that object a is different to object
> b.
>
Fredrik Lundh wrote:
> Steve Holden wrote:
>
>
>>Interestingly I couldn't find this in the FAQ, though it *is* a
>>frequently-asked question [note: my not finding it doesn't guarantee
>>it's not there].
>
>
> it's there:
>
>
> http://www.python.org/doc/faq/general.html#why-are-default-values-shared-between-objects
>
> (maybe "default values" should be changed to "default argument values")
>
I couldn't believe it wasn't, but you're right: it should be easier to
find, and a change of wording may do that.
regards
Steve
--
Steve Holden +44 150 684 7255 +1 800 494 3119
Holden Web LLC www.holdenweb.com
PyCon TX 2006 www.python.org/pycon/
--
http://mail.python.org/mailman/listinfo/python-list
Re: bug or feature?
Fredrik Lundh wrote: > it's also mentioned in chapter 4 of the tutorial: > > http://docs.python.org/tut/node6.html#SECTION00671 > > "*Important warning*: The default value is evaluated only once. This > makes a difference when the default is a mutable object such as a list, > dictionary, or instances of most classes. " Perhaps it would be a good idea if Python actually raised a warning (SyntaxWarning?) if you use an unnamed list or dict as a default argument. This would doubtless help quite a few beginners. And for people who really do want that behaviour, working around the warning should involve minimal extra code, with extra clarity thrown in for free. -- Ben Sizer -- http://mail.python.org/mailman/listinfo/python-list
Re: bug or feature?
On Wed, 05 Oct 2005 03:39:30 -0700, beza1e1 wrote: > Coming back from a bug hunt, i am not sure what to think of this python > behaviour. [snip code] > The point seems to be, that lst=[] creates a class attribute (correct > name?), which is shared by all instances of A. So a.lst ist the same > object as b.lst, despite the fact, that object a is different to object > b. Not a bug, but not really a feature as such, it is a side-effect of the way Python works. I guess that makes it a gotcha. Argument defaults are set at compile time. You set the argument default to a mutable object, an empty list. Every time you call the function, you are appending to the same list. This is not a problem if your argument default is a string, or a number, or None, since these are all immutable objects that can't be changed. I suppose someone might be able to come up with code that deliberately uses this feature for good use, but in general it is something you want to avoid. Instead of: def spam(obj, L=[]): L.append(obj) do this: def spam(obj, L=None): if L is None: L = [] L.append(obj) -- Steven. -- http://mail.python.org/mailman/listinfo/python-list
Re: bug or feature?
Thanks for you answer! This copy trick is the most elegant solution i think. -- http://mail.python.org/mailman/listinfo/python-list
Re: bug or feature?
Steve Holden wrote: > Interestingly I couldn't find this in the FAQ, though it *is* a > frequently-asked question [note: my not finding it doesn't guarantee > it's not there]. it's there: http://www.python.org/doc/faq/general.html#why-are-default-values-shared-between-objects (maybe "default values" should be changed to "default argument values") it's also mentioned in chapter 4 of the tutorial: http://docs.python.org/tut/node6.html#SECTION00671 "*Important warning*: The default value is evaluated only once. This makes a difference when the default is a mutable object such as a list, dictionary, or instances of most classes. " (the text then illustrates this with examples, and shows how to do things instead) and in the description of "def" in the language reference: http://docs.python.org/ref/function.html "*Default parameter values are evaluated when the function definition is executed*. This means that the expression is evaluated once, when the function is defined, and that that same "pre-computed" value is used for each call. This is especially important to understand when a default para- meter is a mutable object, such as a list or a dictionary: if the function modifies the object (e.g. by appending an item to a list), the default value is in effect modified." (the text then shows how to do things instead) -- http://mail.python.org/mailman/listinfo/python-list
Re: bug or feature?
beza1e1 wrote:
> Coming back from a bug hunt, i am not sure what to think of this python
> behaviour. Here is a demo program:
>
> class A:
>def __init__(self, lst=[]):
> self.lst = lst
>
> a = A()
> b = A()
> b.lst.append("hallo")
> print a.lst # output: ["hallo"]
>
> The point seems to be, that lst=[] creates a class attribute (correct
> name?), which is shared by all instances of A. So a.lst ist the same
> object as b.lst, despite the fact, that object a is different to object
> b.
>
Interestingly I couldn't find this in the FAQ, though it *is* a
frequently-asked question [note: my not finding it doesn't guarantee
it's not there]. The nearest I could get was in
http://www.python.org/doc/faq/programming.html#my-program-is-too-slow-how-do-i-speed-it-up
which says:
"""Default arguments can be used to determine values once, at compile
time instead of at run time."""
The point is that the value of the keyword argument is determined when
the def statement is executed (which is to say when the function body is
being bound to its name).
If the default argument is (a reference to) a mutable object (such as a
list instance) then if one call to the function modifies that mutable
object, subsequent calls see the mutated instance as the default value.
regards
Steve
--
Steve Holden +44 150 684 7255 +1 800 494 3119
Holden Web LLC www.holdenweb.com
PyCon TX 2006 www.python.org/pycon/
--
http://mail.python.org/mailman/listinfo/python-list
Re: bug or feature?
Python.org General FAQ 1.4.21: Why are default values shared between objects? (http://www.python.org/doc/faq/general.html#why-are-default-values-shared-between-objects) -- http://mail.python.org/mailman/listinfo/python-list
Re: bug or feature?
beza1e1 wrote:
> Coming back from a bug hunt, i am not sure what to think of this python
> behaviour. Here is a demo program:
>
> class A:
>def __init__(self, lst=[]):
> self.lst = lst
>
> a = A()
> b = A()
> b.lst.append("hallo")
> print a.lst # output: ["hallo"]
>
> The point seems to be, that lst=[] creates a class attribute (correct
> name?), which is shared by all instances of A. So a.lst ist the same
> object as b.lst, despite the fact, that object a is different to object
> b.
>
It is an *instance attribute* by nature, since it does not reside in the
class object, but only in its instances. The truth is, that a.lst and
b.lst point to the same memory object, so it seems to behave much like
the class attribute :)
It is no more different from the simple fact, that two variables
(attributes) may point to the same memory object, like you see below:
a = b = []
a.append("hallo")
print b #output: ["hallo"]
In fact, it is usually a bad practice to assign instance attributes a
reference to the compound variable, existing in an external scope. Example:
aList = []
class A:
def __init__(self, lst): #no default attribute!
self.lst = lst
a = A(aList)
aList.append("hallo")
print a.lst #output: ["hallo"]
and your default value (, lst=[]) IS such an variable! The bad thing is,
that the value of the instance attribute 'lst' (example above) depends
on the external variable, which may be independently modified, thus
modifying unexpectedly the instance attribute. The safer approach, of
course is to write:
class A:
def __init__(self, lst): #no default attribute!
self.lst = lst[:] #take a copy
Summing up, is it an error, or a feature? I would say - a feature.
Everyone should be aware, that the argument default values are evaluated
once, and the same value (memory object) is reused at each instance
creation.
Best regards,
Tomasz Lisowski
--
http://mail.python.org/mailman/listinfo/python-list
Re: bug or feature?
beza1e1> class A: beza1e1>def __init__(self, lst=[]): beza1e1> self.lst = lst Lists are mutable and default args are only evaluated once, at function definition. If you want independent default args use: class A: def __init__(self, lst=None): if lst is None: lst = [] self.lst = lst The same scheme would work for other mutable types (dicts, sets, etc). This same question gets asked once a month or so. I'm sure this is in the Python FAQ (check the website), but it was faster to reply than to look it up... Skip -- http://mail.python.org/mailman/listinfo/python-list
bug or feature?
Coming back from a bug hunt, i am not sure what to think of this python
behaviour. Here is a demo program:
class A:
def __init__(self, lst=[]):
self.lst = lst
a = A()
b = A()
b.lst.append("hallo")
print a.lst # output: ["hallo"]
The point seems to be, that lst=[] creates a class attribute (correct
name?), which is shared by all instances of A. So a.lst ist the same
object as b.lst, despite the fact, that object a is different to object
b.
--
http://mail.python.org/mailman/listinfo/python-list
