I noticed something really strange while working with functions. It looks like the variable name 'str' is already defined as a global variable. Take a look:
def Example(x):
str = input()
return str
print (Example(str))
#When typing 'Hello!' Output --> Hello!
The variable str is defined in the function Example. So why is there no NameError: name 'str' is not defined?
When I call the variable x or something else ( In this case 'bar'):
def Example(x):
bar = input()
return bar
print (Example(bar))
#Output: NameError: name 'bar'is not defined
Why does a variable with the name 'str' act as a global variable?
In python, str() is the string constructor. It is used to cast an object to a string.
You can use it locally, but it will override the access to the function. You will not be able to use str() anymore.
for reference:
https://docs.python.org/2/library/functions.html#str
class str(object='')
Return a string containing a nicely printable representation of an
object. For strings, this returns the string itself. The difference
with repr(object) is that str(object) does not always attempt to
return a string that is acceptable to eval(); its goal is to return a
printable string. If no argument is given, returns the empty string,
''.
For general knowledge purpose, you can get back you constructor if you delete your variable. For example:
test = 1
str(test)
>>>'1'
str = 2
str(test)
>>>TypeError: 'int' object is not callable
del str
str(test)
>>>'1'
The reason this fails:
def Example(x):
bar = input()
return bar
print (Example(bar))
#Output: NameError: name 'bar'is not defined
Is because you're attempting to pass the variable bar to the Example() method, but bar was never defined anywhere prior to the call.
I'm not really sure what it is you want to accomplish with this method anyhow, since you pass a variable but don't use it at all.
Comment Response:
str is not a built-in function (albeit listed on the page), but rather it is the constructor for the built-in type str. To show that you are simply reassigning the method associated with the keyword (not necessarily reserved, but it is a keyword nonetheless), consider the following:
>>> str
<class 'str'>
>>> abs
<built-in function abs>
>>> str = abs
>>> str
<built-in function abs>
Thus you've essentially overwritten the assignment to the str class constructor. I used abs in this example, but the same applies (with a twist) for input:
>>> str
<class 'str'>
>>> input
<built-in function input>
>>> str = input
>>> str
<built-in function input>
>>> str = input()
hello world
>>> str
'hello world'
Difference here is you assign a string (of type str) to the keyword str. So you can never use str(10) to get '10' because that would now be like calling hello world(10) which fails.
If you want to use a keyword as a variable name, by convention a single trailing underscore is used to avoid conflicts with Python keywords, like so:
single_trailing_underscore_
Cf. PEP 8 -- Style Guide for Python Codes
Related
For instance os.listdir('.') returns list of strings whereas os.listdir(b'.') returns list of bytes objects. This is only one example, but the question is for all functions returning string/bytes.
I haven't seen on official docs mentioning of the returned type. Is there some convention or generic doc for that?
From the docs:
path may be a path-like object. If path is of type bytes (directly or indirectly through the PathLike interface), the filenames returned will also be of type bytes; in all other circumstances, they will be of type str.
Not sure about all the other functions you are referring to
to check the type of a variable you can use the builtin python function type(). For example:
# a function that return the parameter that you give
f = lambda x: x
# here is how type() works
print(type(f('hey this is a string!'))) # returns <class 'str'>
print(type(f(b'hey these are bytes!'))) # returns <class 'bytes'>
print(type(f(['this','is','a','list']))) # returns <class 'list'>
print(type(f(3.1415))) # returns <class 'int'>
so to check if a variable contains a string or bytes...
def check(x):
if type(x) is str:
return 'this is a string!'
elif type(x) is bytes:
return 'i like bytes!'
else:
return 'ooops... unknown type :('
myStr = 'string!'
myBytes = b'bytes!'
print(check(myStr))
print(check(myBytes))
what you should do is simply to get the path and to check its type ;)
However the os.listdir() function should return bytes if the parameter you entered were bytes, else a string.
to learn more about type() read this!
hope this helped :)
as you know , python is a strongly typed language that does not allow concatenation of type int with str.
As you can see below; As I stated above python does not allow for such operations(concatenation of str with int due to the language's features).
a = 10
b = '20'
print(a + b)
#throws the error **TypeError: unsupported operand type(s) for +: 'int' and 'str'**
But Look into this too:
a = 1
b = '2'
print(f"{a} and {b}")
print("{} and {}".format(a, b))#or this for example
Here I did not converted variable a which has an int type assigned to ; into string, but I can include it in the formatted string
My question is ... what happens under the curtains when python interpreter encounters with this expression print(f"{a} and {b}")
what happens under the curtains when python interpreter encounters with this expression print(f"{a} and {b}")
What happens is that before a and b are built into the string, str(a) and str(b) are called. You can see this yourself when you build 2 classes like this:
class Test1(object):
pass
class Test2(object):
def __str__(self):
return "surprise"
which do the same (nothing) but Test2 returns "surprise" when str(Test2()) is called.
When you want to convince yourself try this:
t1 = Test1()
t2 = Test2()
print(t1)
print(t2)
print(f"{t1}")
print(f"{t2}")
print("{}".format(t1))
print("{}".format(t2))
Each time the same two lines are printed.
This is documented in chapter 2 of Python's documentation:
If a conversion is specified, the result of evaluating the expression is converted before formatting. Conversion '!s' calls str() on the result, '!r' calls repr(), and '!a' calls ascii().
If no conversion is specified, it immediately continues to the following step:
The result is then formatted using the format() protocol. The format specifier is passed to the __format__() method of the expression or conversion result. An empty string is passed when the format specifier is omitted. The formatted result is then included in the final value of the whole string.
The __format__() method then follows the format specifier mini-language syntax to determine the resulting string representation.
In your case the result is the same as calling str() on the variables, but this does not apply to all variables. Based on #Marv's answer, here is a little demonstration to show the difference:
class Test:
def __str__(self):
return "surprise"
def __format__(self, format_spec):
return "test"
t1 = Test()
print(t1)
print(str(t1))
print(f"{t1}")
print("{}".format(t1))
>>> surprise
>>> surprise
>>> test
>>> test
Why do the following lines give me the same result?
str.upper('hello')
and
'hello'.upper()
I tried to do the same with list.append but got a TypeError.
list.append([1])
Is the str type in Python overloaded? How can this be achieved by writing a class/function? I would appreciate an example.
list.append takes two arguments - the list to modify and the element to append. So you need to do it like this:
ls = [1]
list.append(ls, 2)
which is equivalent to the much more popular:
ls.append(2)
str.upper and list.append are both functions.
str.upper takes one argument.
>>> str.upper('test')
'TEST'
list.append takes two arguments.
>>> my_list = []
>>> list.append(my_list, 1)
>>> my_list
[1]
str.upper and list.append (like other functions) are also non-data-descriptors with a __get__ method which in this context has two implications:
When you access the function through the class via the dot notation (str.upper, list.append) the function's __get__ method (i.e. string.upper.__get__ and list.append.__get__) is called but it returns just the function itself.
When you access the function through an instance (my_string.upper, my_list.append) the function's __get__ method is called and it will return a new callable acting like the original function, but with whatever was "in front of the dot" automatically passed as the first argument. .
That's why you need to pass 1 - 1 = 0 arguments when calling my_string.upper() and 2 - 1 = 1 argument when calling my_list.append(1).
>>> 'my_string'.upper()
'MY_STRING'
>>>
>>> my_list = []
>>> my_list.append(1)
>>> my_list
[1]
You could even get these modified callables (methods) by explicitly calling __get__ and passing the argument to be bound (what has been before the dot) as its argument.
>>> my_string = 'my_string'
>>> upper_maker = str.upper.__get__(my_string)
>>> upper_maker()
'MY_STRING'
>>>
>>> my_list = []
>>> appender = list.append.__get__(my_list)
>>> appender(1)
>>> my_list
[1]
Finally, here's a short example demonstrating how descriptor instances can detect whether they are being accessed via their owner-class or via an instance.
class Descriptor:
def __get__(self, instance, owner_class):
if instance is None:
print('accessed through class')
# list.append.__get__ would return list.append here
else:
print('accessed through instance')
# list.append.__get__ would build a new callable here
# that takes one argument x and that internally calls
# list.append(instance, x)
class Class:
attribute = Descriptor()
Class.attribute # prints 'accessed through class'
instance = Class()
instance.attribute # prints 'accessed through instance'
Quoting Dave Kirbys answer from Relationship between string module and str:
There is some overlap between the string module and the str type,
mainly for historical reasons. In early versions of Python str objects
did not have methods, so all string manipulation was done with
functions from the string module. When methods were added to the str
type (in Python 1.5?) the functions were left in the string module for
compatibility, but now just forward to the equivalent str method.
However the string module also contains constants and functions that
are not methods on str, such as formatting, character translation etc.
There is nothing at all magical going on with str (except that we have a nice syntactic shortcut to creating one using ""). You can write a class that behaves like str and list to see more clearly what is happening here.
class MyClass():
def __init__(self, arg):
self.val=str(arg)
def do_thing(self):
self.val = "asdf"
def do_thing_with_arg(self, arg):
self.val = "asdf " + str(arg)
def __repr__(self):
return self.val
my_thing = MyClass("qwerty")
# this is like 'hello'.upper()
my_thing.do_thing()
print(my_thing)
# it prints 'asdf'
my_thing = MyClass("qwerty")
# this is like str.upper('hello')
MyClass.do_thing(my_thing)
print(my_thing)
# it prints 'asdf'
my_thing = MyClass("qwerty")
# this is like my_list.append('qwerty')
my_thing.do_thing_with_arg('zxcv')
print(my_thing)
# it prints 'asdf zxcv'
my_thing = MyClass("qwerty")
# this is like list.append(my_list, 'qwerty')
MyClass.do_thing_with_arg(my_thing, 'zxcv')
print(my_thing)
# it prints 'asdf zxcv'
The short version is, you're invoking what looks like an "instance method" on a class, but you are supplying the instance ('self') yourself as the first argument to the function call.
I'm working on a python program and the author has written a function that looks like this
def blah():
str = "asdf asdf asdf"
doStuff(str)
This seems to work, even though str is a built in function and shouldn't be used as a variable.
What is actually happening here? My guess is str will no longer be usable as a function, but only in the scope of the blah() function he's written. Is that correct? This won't redefine str globally, right?
Internally, the function's local variable table will contain an entry for str, which will be local to that function. You can still access the builtin class within the function by doing builtins.str in Py3 and __builtin__.str in Py2. Any code outside the function will not see any of the function's local variables, so the builtin class will be safe to use elsewhere.
There is another caveat/corner case here, which is described in this question. The local table entry is created at compile-time, not at runtime, so you could not use the global definition of str in the function even before you assign "asdf asdf asdf" to it:
def blah():
x = str(12)
str = "asdf asdf asdf"
doStuff(str)
will fail with an UnboundLocalError.
This seems to work, even though str is a built in function and shouldn't be used as a variable.
Yes, that is true. Python doesn't stop you from shooting yourself in the foot. It's up to you as the developer to make sure your not overwriting builtin names.
What is actually happening here? My guess is str will no longer be usable as a function, but only in the scope of the blah() function he's written. Is that correct? This won't redefine str globally, right?
Your are partially correct here as well. If the value of str is overwritten local, then only the current scope is affected. The global value of str remains unchanged. However, if str is over written in the global scope, then it affects all sub-scopes. The reason behind this is how the Python interpreter compiles values at run-time. This behavior can be observed using a simple example:
>>> def foo():
... str = 0
... return str
...
>>> foo()
0
>>> str(0)
'0'
>>>
The first example works because str is only overwritten in the scope of foo(). This second example fails however because str is overwritten globally:
>>> str = 0
>>> def foo():
... return str(0)
...
>>> foo()
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "<stdin>", line 2, in foo
TypeError: 'int' object is not callable
>>>
You can always import builtins(__builtins__ in Python 2) though, and reset the value of str to its original meaning:
>>> str = 0
>>> str
0
>>> import __builtins__
>>> str = __builtins__.str
>>> str
<type 'str'>
>>> str(0)
'0'
>>>
Also, as #Brad Solomon stated, you can simply use del str to recover the builtin str value:
>>> str = 0
>>> str
0
>>> del str
>>> str
<class 'str'>
>>>
In your case, str is just a variable and nothing prevents you from the usual use of str() outside that function:
>>> str = 'Hello world!'
>>> print str
Hello world!
str(str)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: 'str' object is not callable
EDIT:
Here is a simple demo:
def salut():
str = 'Hello world!'
return str
if __name__ == '__main__':
s = salut()
print str(s) #nothing prevents you from using 'str' outside 'salut()'
What's the difference between these 2 string format statements in Python:
'{0}'.format(a)
'{0!s}'.format(a)
Both have the same output if a is an integer, list or dictionary. Is the first one {0} doing an implicit str() call?
Source
PS: keywords: exclamation / bang "!s" formatting
It is mentioned in the documentation:
The conversion field causes a type coercion before formatting.
Normally, the job of formatting a value is done by the __format__()
method of the value itself. However, in some cases it is desirable to
force a type to be formatted as a string, overriding its own
definition of formatting. By converting the value to a string before
calling __format__(), the normal formatting logic is bypassed.
Two conversion flags are currently supported: '!s' which calls
str() on the value, and '!r' which calls repr().
An example can be taken (again from the documentation) to show the difference:
>>> "repr() shows quotes: {!r}; str() doesn't: {!s}".format('test1', 'test2')
"repr() shows quotes: 'test1'; str() doesn't: test2"
Simply said:
'{0}'.format(a) will use the result of a.__format__() to display the value
'{0!s}'.format(a) will use the result of a.__str__() to display the value
'{0!r}'.format(a) will use the result of a.__repr__() to display the value
>>> class C:
... def __str__(self): return "str"
... def __repr__(self): return "repr"
... def __format__(self, format_spec): return "format as " + str(type(format_spec))
...
>>> c = C()
>>> print "{0}".format(c)
format as <type 'str'>
>>> print u"{0}".format(c)
format as <type 'unicode'>
>>> print "{0!s}".format(c)
str
>>> print "{0!r}".format(c)
repr
Concerning the second argument of __format__, to quote PEP 3101 "Controlling Formatting on a Per-Type Basis":
The 'format_spec' argument will be either
a string object or a unicode object, depending on the type of the
original format string. The __format__ method should test the type
of the specifiers parameter to determine whether to return a string or
unicode object. It is the responsibility of the __format__ method
to return an object of the proper type.
Thanks to the comment & answer from #hjpotter92 for explanation:
Here's an example that shows the difference (it's when you override the __format__ method)
class MyClass:
i = 12345
def __format__(self, i):
return 'I Override'
>>> obj = MyClass()
>>> '{0}'.format(obj)
'I Override'
>>> '{0!s}'.format(obj)
'<__main__.MyClass instance at 0x021AA6C0>'