[Tutor] Problem with code

[Frank Lawrence]

Hello, I have a code here that I’m having a problem with. It’s supposed to be a 
pizza ordering simulator, as you can tell by the title, but I keep trying to 
add music to it and whenever I try to play the music with the program running, 
it always freezes up and crashes. Can someone help me with this? It’s really 
been bugging me. Thanks!



Sent from Mail for Windows 10

___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] iterators

[Alan Gauld via Tutor]

On 05/07/16 01:42, Steven D'Aprano wrote:
> On Tue, Jul 05, 2016 at 12:47:27AM +0100, Alan Gauld via Tutor wrote:
> 
>>> I then tried using
>>>
>>> elif keycode == 27:
>>>
>>> but this statement didn't work. 
>>
>> I'm not sure why that didn't work.
>> What exactly happened? Did you get a different error message?
>> If so what?
> 
> I expect that the keycode is always a tuple, usually with two items but 
> sometimes with one. So keycode == 27 compares the tuple (27,) with the 
> int 27 and finds them to be different.

but then the 'in' tests would fail.

>>> (27,) in (27,36)
False

the fact that the 'in' tests work suggests that keycode
is an int. But in that case the == test should work...

Although I just realized that the OP didn't actually say
the 'in' tests worked, just that they pass the compiler...

-- 
Alan G
Author of the Learn to Program web site
http://www.alan-g.me.uk/
http://www.amazon.com/author/alan_gauld
Follow my photo-blog on Flickr at:
http://www.flickr.com/photos/alangauldphotos


___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] Problem with code

[Alan Gauld via Tutor]

On 05/07/16 04:36, Frank Lawrence wrote:
> Hello, I have a code here that I’m having a problem with. 

Unfortunately we can't see it.

Now, I could see it among a bunch of HTML when I checked it in the
moderator queue, so I'm guessing you sent it as some kind of
attachment and the server has stripped it off.

Please resend the code pasted into the body of the email.

> I keep trying to add music to it and whenever I try to play 
> the music with the program running, it always freezes up
> and crashes.

I don't know about the crash, but the freezing may be
because it needs to run in a separate thread. Anything
that takes a long time to process in a GUI should be
done in a background thread. (I don't know if you are
familiar with threads yet, but they are a kind of
lightweight background subprocess that allows your
program to do two things at once.)

But without seeing the code that is just a guess!

-- 
Alan G
Author of the Learn to Program web site
http://www.alan-g.me.uk/
http://www.amazon.com/author/alan_gauld
Follow my photo-blog on Flickr at:
http://www.flickr.com/photos/alangauldphotos


___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor

[Tutor] Writing decorators?

[Alex Hall]

Hi list,
I've read three or four articles on creating decorators. I don't know why,
but the use of decorators makes sense, yet the creation of them isn't
clicking. I get the idea, but when it comes to precisely how to write
one--what goes where and gets returned/called when--it's just not making
complete sense.

To simplify things, what might be an example of a decorator that, say,
prints "decorated" before whatever string the decorated function prints?
That is:

@prependDecorated()
def printSomething(str):
print str

printSomething("Hello world.")
#result should be:
decoratedHello world.

My attempt would be:

def prependDecorated(f):
  def prepend():
return "decorated"+f()
  #something should go at this level too?

As I said, I've already read several sources on this. Are there any that
people find especially clear and helpful? Thanks for any links and/or
explanations.

-- 
Alex Hall
Automatic Distributors, IT department
ah...@autodist.com
___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] Writing decorators?

[Alan Gauld via Tutor]

On 05/07/16 14:22, Alex Hall wrote:

> To simplify things, what might be an example of a decorator that, say,
> prints "decorated" before whatever string the decorated function prints?

> My attempt would be:
> 
> def prependDecorated(f):
>   def prepend():
> return "decorated"+f()
>   #something should go at this level too?

Recall that a decorator is:

a function
that takes a function as its argument
and returns a function

Your code fails on the third item.

Lets take a trivial example first, a decorator that
does nothing. Define a function that takes a function
and returns the same function untouched:

>>> def donothing(f): return f

Now apply it to a square() function:

>>> @donothing
def square(x): return x*x

>>> square

>>> square(4)
16

We could do the same without the @ shorthand by using

square2 = donothing(square)

But the @ syntax makes it more readable.

Now lets look at your task
We need a function that takes a function and
returns a function that prepends a string:

def prepend(f):
def add_string(*args, **kwargs):  # in case f takes arguments
return "decorated "+ str(f(*args,**kwargs))
return add_string

Now we can apply that to a function

@prepend
def cube(n): return n*n*n

cube(3)

I'm biased because I was the tech editor but the book
Professional Python has a nice chapter on decorators.

HTH

-- 
Alan G
Author of the Learn to Program web site
http://www.alan-g.me.uk/
http://www.amazon.com/author/alan_gauld
Follow my photo-blog on Flickr at:
http://www.flickr.com/photos/alangauldphotos


___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] Writing decorators?

[Steven D'Aprano]

On Tue, Jul 05, 2016 at 09:22:52AM -0400, Alex Hall wrote:
> Hi list,
> I've read three or four articles on creating decorators. I don't know why,
> but the use of decorators makes sense, yet the creation of them isn't
> clicking. I get the idea, but when it comes to precisely how to write
> one--what goes where and gets returned/called when--it's just not making
> complete sense.

*Technically* a decorator can return anything at all, but the most 
common use for them is to return a function. In this case, the decorator 
is a function that:

(1) Takes as input a single function;
(2) Processes or wraps that function in some way; and
(3) Returns the original function, or the wrapped function, as output.

Back before Python had the "@decorator" syntax, we used to use 
decorators like this:

def func(arg):
...

func = decorator(func)


which has the disadvantage that we have to write the function name three 
times, and that the call to the decorator is kinda lost there at the end 
instead of near the function declaration, but it does have one 
advantage: it makes it clear that "func" gets set to whatever 
decorator() returns.

Which may be None if you're not careful.


> To simplify things, what might be an example of a decorator that, say,
> prints "decorated" before whatever string the decorated function prints?


import functools

def prependDecorated(function):
"""Wrap function so that it prints "decorated" before running."""
# Here we define a new function that prints "decorated",
# then calls the original function.
#
# We use functools.wraps as a bit of magic to make sure our new
# function looks like the original (same name, docstring, etc).
#
@functools.wraps(function)
def inner(*args, **kwargs):
print("Decorated!")
return function(*args, **kwargs)
#
# Now that we have our new "inner" function that calls the old
# one, we have to return that inner function.
return inner


@prependDecorated  # NO PARENTHESES!!!
def lunch():
print("What's for lunch?")
print("How about some wonderful SPAM!!!")




That's what the great bulk of decorators look like:

(1) declare a function that takes one function as argument;

(2) define an inner function (usually called "inner");

(3) it will often take arbitrary *args, **kwargs parameters, since you 
don't normally know what arguments the WRAPPED (decorated) function will 
take;

(3) use functools.wraps to disguise the inner function as the original 
function (this is important so that it keeps the docstring, the name, 
any other attached attributes etc. that the original had);

(4) inside the "inner" function, do your pre-processing, then call the 
original function, do any post-processing, and then return the result;

(5) finally return the "inner" function.


Here's a decorator that makes sure the decorated function returns a 
string:

def stringify(func):
@functools.wraps(func)
def inner(*args, **kwargs):
result = func(*args, **kwargs)
return "stringified result: " + str(result)
return inner


@stringify
def add(a, b):
"""Return the stringified result of adding a and b."""
return a+b


Here's a decorator that makes sure the first argument is greater than 
zero:

def verify_arg0(func):
@functools.wraps(func)
def inner(x, *args, **kwargs):
if x <= 0:
raise ValueError('x must be greater than zero')
return func(x, *args, **kwargs)
return inner

Here's a neat trick: here's a decorator that doesn't actually modify the 
function, but registers its name somewhere!


THE_REGISTER = []

def register(func):
THE_REGISTER.append(func.__name__)
return func

@register
def plus(a, b): return a + b

@register
def minus(a, b): return a - b



> That is:
> 
> @prependDecorated()
> def printSomething(str):
> print str
> 
> printSomething("Hello world.")
> #result should be:
> decoratedHello world.


This one is trickier than you think, because it requires knowledge of 
what the original function will do. It *requires* that the original 
function MUST call print at least once, otherwise you'll have started to 
print something, but not completed the line. That may mess up your 
python prompt (in the interactive interpreter) or any other output you 
print. But here we go:


def prepend_actual_print(func):
@functools.wraps(func)
def inner(*args, **kwargs):
## print("decorated", end='')  # Python 3 syntax
sys.stdout.write("decorated")  # Python 2
return func(*args, **kwargs)
return inner


Hope this helps!


-- 
Steve
___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] Writing decorators?

[Alan G via Tutor]

   Sorry for top posting, but yes excepting you don't need the parens after
   log in the @log line.

   Sent from my Fonepad

   Alex Hall  wrote:

   Okay, I think I follow. So a decorator to log that a function ran might
   be:

   import utils

   @log()
   def run():
   ** #do things

   #utils.py

   logger = #set up logging

   def log(f):
   ** def logThatFRan(*args, **kwargs):
   ** [1]logger.info("running %s" %(f.__name__)
   ** return f(*args, **kwargs)
   ** return logThatFRan

   That will log that F ran, then run f with any arguments. I know I'd have
   to decorate the inner function with functools.wraps for __name__ to work
   correctly, but that's the general idea, right?
   On Tue, Jul 5, 2016 at 10:40 AM, Alan Gauld via Tutor
   <[2]tutor@python.org> wrote:

 On 05/07/16 14:22, Alex Hall wrote:

 > To simplify things, what might be an example of a decorator that, say,
 > prints "decorated" before whatever string the decorated function
 prints?

 > My attempt would be:
 >
 > def prependDecorated(f):
 >** **def prepend():
 >** ** **return "decorated"+f()
 >** **#something should go at this level too?

 Recall that a decorator is:

 a function
 that takes a function as its argument
 and returns a function

 Your code fails on the third item.

 Lets take a trivial example first, a decorator that
 does nothing. Define a function that takes a function
 and returns the same function untouched:

 >>> def donothing(f): return f

 Now apply it to a square() function:

 >>> @donothing
 def square(x): return x*x

 >>> square
 
 >>> square(4)
 16

 We could do the same without the @ shorthand by using

 square2 = donothing(square)

 But the @ syntax makes it more readable.

 Now lets look at your task
 We need a function that takes a function and
 returns a function that prepends a string:

 def prepend(f):
 ** ** def add_string(*args, **kwargs):** # in case f takes arguments
 ** ** ** ** return "decorated "+ str(f(*args,**kwargs))
 ** ** return add_string

 Now we can apply that to a function

 @prepend
 def cube(n): return n*n*n

 cube(3)

 I'm biased because I was the tech editor but the book
 Professional Python has a nice chapter on decorators.

 HTH

 --
 Alan G
 Author of the Learn to Program web site
 [3]http://www.alan-g.me.uk/
 [4]http://www.amazon.com/author/alan_gauld
 Follow my photo-blog on Flickr at:
 [5]http://www.flickr.com/photos/alangauldphotos

 ___
 Tutor maillist** -** [6]Tutor@python.org
 To unsubscribe or change subscription options:
 [7]https://mail.python.org/mailman/listinfo/tutor

   --
   Alex Hall
   Automatic Distributors, IT department
   [8]ah...@autodist.com

References

   Visible links
   1. http://logger.info/
   2. mailto:tutor@python.org
   3. http://www.alan-g.me.uk/
   4. http://www.amazon.com/author/alan_gauld
   5. http://www.flickr.com/photos/alangauldphotos
   6. mailto:Tutor@python.org
   7. https://mail.python.org/mailman/listinfo/tutor
   8. mailto:ah...@autodist.com
___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] Writing decorators?

[Alex Hall]

On Tue, Jul 5, 2016 at 1:26 PM, Alan G  wrote:

> Sorry for top posting, but yes excepting you don't need the parens after
> log in the @log line.
>

For decorators, do you never include parentheses except for passing
arguments? It seems a bit odd to drop them if they'd be empty, given that
anywhere else doing so would return the function object rather than call
it. Yet, if arguments are passed, you include them like you would anywhere
else. Or am I misunderstanding it?

>
> Sent from my Fonepad
>
> Alex Hall  wrote:
>
> Okay, I think I follow. So a decorator to log that a function ran might be:
>
> import utils
>
> @log()
> def run():
>   #do things
>
> #utils.py
>
> logger = #set up logging
>
> def log(f):
>   def logThatFRan(*args, **kwargs):
> logger.info("running %s" %(f.__name__)
> return f(*args, **kwargs)
>   return logThatFRan
>
> That will log that F ran, then run f with any arguments. I know I'd have
> to decorate the inner function with functools.wraps for __name__ to work
> correctly, but that's the general idea, right?
>
>
> On Tue, Jul 5, 2016 at 10:40 AM, Alan Gauld via Tutor 
> wrote:
>
>> On 05/07/16 14:22, Alex Hall wrote:
>>
>> > To simplify things, what might be an example of a decorator that, say,
>> > prints "decorated" before whatever string the decorated function prints?
>>
>> > My attempt would be:
>> >
>> > def prependDecorated(f):
>> >   def prepend():
>> > return "decorated"+f()
>> >   #something should go at this level too?
>>
>> Recall that a decorator is:
>>
>> a function
>>
>> that takes a function as its argument
>> and returns a function
>>
>> Your code fails on the third item.
>>
>> Lets take a trivial example first, a decorator that
>> does nothing. Define a function that takes a function
>> and returns the same function untouched:
>>
>> >>> def donothing(f): return f
>>
>> Now apply it to a square() function:
>>
>> >>> @donothing
>> def square(x): return x*x
>>
>> >>> square
>> 
>> >>> square(4)
>> 16
>>
>> We could do the same without the @ shorthand by using
>>
>> square2 = donothing(square)
>>
>> But the @ syntax makes it more readable.
>>
>> Now lets look at your task
>> We need a function that takes a function and
>> returns a function that prepends a string:
>>
>> def prepend(f):
>> def add_string(*args, **kwargs):  # in case f takes arguments
>> return "decorated "+ str(f(*args,**kwargs))
>> return add_string
>>
>> Now we can apply that to a function
>>
>> @prepend
>> def cube(n): return n*n*n
>>
>> cube(3)
>>
>> I'm biased because I was the tech editor but the book
>> Professional Python has a nice chapter on decorators.
>>
>> HTH
>>
>> --
>> Alan G
>> Author of the Learn to Program web site
>> http://www.alan-g.me.uk/
>> http://www.amazon.com/author/alan_gauld
>> Follow my photo-blog on Flickr at:
>> http://www.flickr.com/photos/alangauldphotos
>>
>>
>> ___
>> Tutor maillist  -  Tutor@python.org
>> To unsubscribe or change subscription options:
>> https://mail.python.org/mailman/listinfo/tutor
>>
>
>
>
> --
> Alex Hall
> Automatic Distributors, IT department
> ah...@autodist.com
>



-- 
Alex Hall
Automatic Distributors, IT department
ah...@autodist.com
___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] dont understand part of a code

[Michael Selik]

On Sat, Jul 2, 2016 at 8:29 AM Alan Gauld via Tutor 
wrote:

> There are arguably easier ways of doing this
>

I think you'll find that for-loops are preferable to while-loops. Here's an
alternative implementation.

https://gist.github.com/selik/d8e0a7622ceff0fe8984a7d19d44bfca

import random
import string

drawings = (
r"""
--|
|
|
|
|
--
""",
r"""
--|
| 0
|
|
|
--
""",
r"""
--|
| 0
|-+-
|
|
--
""",
r"""
--|
| 0
|   /-+-
|
|
--
""",
r"""
--|
| 0
|   /-+-\
|
|
--
""",
r"""
--|
| 0
|   /-+-\
| |
|
--
""",
r"""
--|
| 0
|   /-+-\
| |
||
--
""",
r"""
--|
| 0
|   /-+-\
| |
|| |
--
"""
)

print('Welcome to Hangman.')
print('Good luck!')

words = 'python ruby php java unix linux perl'.split()
target = list(random.choice(words))
known = ['_'] * len(target)
used = []

for drawing in drawings:
print('-'.join(c if c not in used else ' ' for c in
string.ascii_lowercase))
print(drawing, '\n\t', ' '.join(known))
guess = input('\nEnter your guess: ').lower()

while guess in used:
print("You've already guessed that letter")
guess = input('Please enter a new guess: ').lower()

used.append(guess)
if guess in target:
print('Yes, {!r} is in the word!'.format(guess))
for i, letter in enumerate(target):
if guess == letter:
known[i] = letter
else:
print('Sorry, {!r} is not in the word.'.format(guess))

if known == target:
print('\nYou guessed the word correctly!')
break
else:
print('\nYou have been hanged!')

print('The word was {!r}'.format(''.join(target)))
___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor

[Tutor] isinstance versus 'is'?

[Alex Hall]

Hi all,
Thanks for all the help regarding decorators. It makes more sense now.

I was double checking that I remembered the isinstance order of arguments
correctly by using the command line interpreter, and found something very
odd.

>>> a = 5
>>> isinstance(a, int)
True
>>> a is int
False

What happened there? Don't these do the same thing? I thought I could use
them interchangeably?

-- 
Alex Hall
Automatic Distributors, IT department
ah...@autodist.com
___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] isinstance versus 'is'?

[Joel Goldstick]

On Tue, Jul 5, 2016 at 3:05 PM, Alex Hall  wrote:
> Hi all,
> Thanks for all the help regarding decorators. It makes more sense now.
>
> I was double checking that I remembered the isinstance order of arguments
> correctly by using the command line interpreter, and found something very
> odd.
>
 a = 5
 isinstance(a, int)
> True
 a is int
> False
>
> What happened there? Don't these do the same thing? I thought I could use
> them interchangeably?
>
> --
> Alex Hall
> Automatic Distributors, IT department
> ah...@autodist.com
> ___
> Tutor maillist  -  Tutor@python.org
> To unsubscribe or change subscription options:
> https://mail.python.org/mailman/listinfo/tutor

is denotes identity.  5 is not the type int.  It is an int, but it is
not the same -- if it was 5('16') would be 16.

-- 
Joel Goldstick
http://joelgoldstick.com/blog
http://cc-baseballstats.info/stats/birthdays
___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] Writing decorators?

[Alan Gauld via Tutor]

On 05/07/16 18:31, Alex Hall wrote:

> For decorators, do you never include parentheses except for passing
> arguments? It seems a bit odd to drop them if they'd be empty, given that
> anywhere else doing so would return the function object rather than call
> it. 

Remember what the @ sign is doing.

@decorator
def func():...

is effectively suyntactic sugar for

func = decorator(func)

If you write @decorator()

That translates to

@decorator()(func)

which is not at all the same thing.

Of course you could get into brain melting mode and
write a meta-decorator that returns a decorator!

>>> def meta():
def decorator(f):
def logit(*args,**kwargs):
print("called function with ", args, kwargs)
return f(*args,**kwargs)
return logit
return decorator

>>> @meta()#with parens and potentially args
def square(x): return x*x

>>> square(3)
called function with  (3,) {}
9
>>>

yikes! It all starts to get too complicated for my tiny
brain at this point and I usually find another more
explicit way to do what I need...


-- 
Alan G
Author of the Learn to Program web site
http://www.alan-g.me.uk/
http://www.amazon.com/author/alan_gauld
Follow my photo-blog on Flickr at:
http://www.flickr.com/photos/alangauldphotos


___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] isinstance versus 'is'?

[Alan Gauld via Tutor]

On 05/07/16 20:05, Alex Hall wrote:

> I was double checking that I remembered the isinstance order of arguments
> correctly by using the command line interpreter, and found something very
> odd.
> 
 a = 5
 isinstance(a, int)
> True
 a is int
> False
> 
> What happened there? Don't these do the same thing? 

Evidently not!
Think about it. isinstance() is asking if a is an
instance of int. int is a type. 5 is an instance of
that type but it's not the type itself.

a is int

is asking if a and int are the same things
(are they actually the same object).
Clearly 5 is not the type int. We can check
this in the interpreter:

>>> isinstance(5,int)
True
>>> int

>>> 5
5

What you may be getting confused with is:

>>> type(5) is int
True
>>>

But even then this is not identical to isinstance,
because the latter checks for subclass relationships
too:

>>> class C: pass
...
>>> class D(C): pass
...
>>> c = C()
>>> d = D()
>>> isinstance(c, C)
True
>>> isinstance(c, D)
False
>>> isinstance(d, C)
True
>>> isinstance(d, D)
True
>>> type(c) is C
True
>>> type(d) is type(C)
False

And to further complicate matters the above works
differently in v2 from v3(above)

The bottom line is that isinstance() is usually
the best choice.


-- 
Alan G
Author of the Learn to Program web site
http://www.alan-g.me.uk/
http://www.amazon.com/author/alan_gauld
Follow my photo-blog on Flickr at:
http://www.flickr.com/photos/alangauldphotos


___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] Writing decorators?

[Alan Gauld via Tutor]

On 06/07/16 00:06, Alan Gauld via Tutor wrote:

> func = decorator(func)
> 
> If you write @decorator()
> 
> That translates to
> 
> @decorator()(func)

Ooops, I meant to say

func = decorator()(func)

Sorry.
-- 
Alan G
Author of the Learn to Program web site
http://www.alan-g.me.uk/
http://www.amazon.com/author/alan_gauld
Follow my photo-blog on Flickr at:
http://www.flickr.com/photos/alangauldphotos


___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] isinstance versus 'is'?

[Danny Yoo]

On Tue, Jul 5, 2016 at 12:05 PM, Alex Hall  wrote:

 a = 5
 isinstance(a, int)
> True
 a is int
> False
>
> What happened there? Don't these do the same thing? I thought I could use
> them interchangeably?


'isinstance' is something else from 'is'.

isinstance will tell us if something is considered to be an "instance"
of something: it knows how to categorize.

This might be important if, when we're running our program, we have
some data and want to do some case analysis based on what
classification that data falls into.

For example, True and False can be identified as instances of the booleans.

###
>>> isinstance(True, bool)
True
>>> isinstance(False, bool)
True
###

If we're object oriented programming based on different classes of
data, then 'isinstance' can be used to distinguish things based on
their class.  For example:

#
class C1(object): pass
class C2(object): pass

barry = C1()
white = C2()

print(isinstance(barry, C1))
print(isinstance(barry, C2))
##

if we have two classes, we can create instances of them, and use
'isinstance' to find out if they match a particular class-ification.

I rarely use this operator in practice because usually, *how* a value
operates and behaves is much more important than *what* strata that
value belongs to.

I suppose that's an ideal of meritocracy.  :)



In contrast, 'is' is a more low-level notion having to do with
*equality*, not classification.  These are both operations that
compare two things, but their conceptual types are not the same:

  * 'isinstance' deals with a thing and a category.

  * 'is' works on two things that, presumably, might be the same type
of thing.  (Why?  Because if we knew in advance that the the two
things were of different types, then we already know that 'is' will
return False, so we know our answer in advance.)
___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor

[Tutor] help with exercise 15 of zed shaw's LPTHW

[lohecn]

hey everyone. this is my first time trying this -- actually, I've been 
studying python only for some days now, and I'm afraid my questions are going 
to be rally simple, but I can't seem to understand this piece of code and 
thus can't move on.

you probably know the book, so you know that zed always makes us write code 
so that then we can understand how it works, and it's great, but in this 
exercise there are just too many new functions and without explanation they 
are a bit hard to understand... so I'm having trouble with most of the lines 
here.

it's not that I want the full explanation to that code, but since I'm 
unfamiliar with some of its concepts, I'm just going to tell you all the 
things that I don't understand (sorry for it being a lot):
1. the need to put script into an estipulation for argv (line 3)
2. the what is txt and why it has to be used there (line 4)
3. txt.read() -- which are all new functions(? I dont even know what they 
are)  (line 7)
4. file_again (line 10)
5. txt_again (line 12)
and line 14.

as you can see, it's pretty much everything. sorry about that.
I'd really appreciate any help at all!
thanks a lot,

heloisa
___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] isinstance versus 'is'?

[Alan Gauld via Tutor]

On 06/07/16 00:22, Alan Gauld via Tutor wrote:

 type(c) is C
> True
 type(d) is type(C)
> False

The last one should of course be

>>> type(d) is C
False

Apologies.

-- 
Alan G
Author of the Learn to Program web site
http://www.alan-g.me.uk/
http://www.amazon.com/author/alan_gauld
Follow my photo-blog on Flickr at:
http://www.flickr.com/photos/alangauldphotos


___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] help with exercise 15 of zed shaw's LPTHW

[boB Stepp]

Welcome!

On 07/05/2016 06:56 PM, loh...@tuta.io wrote:

hey everyone. this is my first time trying this -- actually, I've been
studying python only for some days now, and I'm afraid my questions are going
to be rally simple, but I can't seem to understand this piece of code and
thus can't move on.

you probably know the book, so you know that zed always makes us write code
so that then we can understand how it works, and it's great, but in this
exercise there are just too many new functions and without explanation they
are a bit hard to understand... so I'm having trouble with most of the lines
here.


While this book is fairly well known, not everyone has a copy at hand. 
I would suggest that you resend your email with the full exercise typed 
into its body (This list does not accept attachments BTW.), and then 
pose your questions.  This way you provide the necessary context *in* 
your email body, so that everyone can follow along.


Cheers!
boB
___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] isinstance versus 'is'?

[Steven D'Aprano]

On Tue, Jul 05, 2016 at 03:05:45PM -0400, Alex Hall wrote:

> >>> a = 5
> >>> isinstance(a, int)
> True
> >>> a is int
> False
> 
> What happened there? Don't these do the same thing? I thought I could use
> them interchangeably?

You're probably thinking of "is a", as in, "5 is an int", "'Hello 
World' is a str", "[1, 2, 3] is a list", etc.

Python doesn't have an operator for testing "is a" relationships, it 
uses isinstance(obj, type). There's also issubclass(), for testing 
whether one class is a subclass of another.

"x is y" checks whether the two operands x and y are the same object. 
That's *not* the same as checking whether they are equal. You should 
hardly ever use "is" in Python, with the exception of testing for None: 
"if obj is None: ..." sort of thing.


-- 
Steve
___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] help with exercise 15 of zed shaw's LPTHW

[Steven D'Aprano]

Hi Heloisa, and welcome.

Do you have a link to the code? Or better still, if it is short (say 
under fifty lines) can you copy it into an email and send it?

On Wed, Jul 06, 2016 at 12:56:19AM +0100, loh...@tuta.io wrote:

[...]
> 1. the need to put script into an estipulation for argv (line 3)

I'm sorry, I don't know what that word "estipulation" means. Do you mean 
"stipulation", as in:

That which is stipulated, or agreed upon; that which is
definitely arranged or contracted; an agreement


> 2. the what is txt and why it has to be used there (line 4)
> 3. txt.read() -- which are all new functions(? I dont even know what they 
> are)  (line 7)
> 4. file_again (line 10)
> 5. txt_again (line 12)
> and line 14.

The only thing I can guess without seeing the code is that MAYBE txt is 
an open file, and txt.read() reads the content of the file.



-- 
Steve
___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor