Re: newb question about @property

[Chris Angelico]

On Mon, Oct 2, 2017 at 5:34 PM, Marko Rauhamaa  wrote:
> Chris Angelico :
>
>> Yes, that's correct. The *descriptor* protocol is what allows
>> "foo.bar" to cause a function to be executed
>
> That mechanism allows you to expose data fields in the API. If the
> implementation later changes, you can emulate the data fields.
>
> I must say, though, I have yet to run into a need for descriptors.

The beauty of Python (over, say, C++) is that you can transparently
convert something from being a simple data attribute to being a
descriptor. The mere fact that they *exist* benefits your code;
they're like a safety net that lets you do what makes sense without
worrying that someday, maybe, one of these things might have to become
a function. In C++, if something might ever need to be a function, it
has to be a function *now*, so Best Practice is to write getters and
setters for everything, just in case. In Python, you can convert it to
use @property if you ever actually need to, which means you do nothing
now.

>> the *decorator* protocol is what lets you "tag" a function:
>
> i have yet to need that, either. I have *seen* a semi-useful decorator
> in code once (@contextlib.contextmanager) but still would prefer
> explicit dunder methods.

There are plenty of programs that don't need decorators, but in some
contexts, they are just beautiful. Building a web app in Flask or
Django involves functions that get decorated to say what endpoints
they handle, for instance. I've periodically used a simple decorator
plus some info in the function's docstring to do more magic. I'm not
sure where dunder methods come into this, though, as they're
completely unrelated.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: on a very slow function

[Peter Otten]

Daniel Bastos wrote:

> def make_sequence_non_recursive(N, x0 = 2, c = -1):
>   "What's wrong with this function?  It's very slow."
>   last = x0
>   def sequence():
> nonlocal last
> next = last
> last = last**2 + c
> return next % N
>   return sequence
> 
> It crawls pretty soon.  Please advise?  Thank you.

Let's change your code a bit to get a feel for the size of the numbers you 
are dealing with:

>>> def make_sequence_non_recursive(N, x0 = 2, c = -1):
...   "What's wrong with this function?  It's very slow."
...   last = x0
...   def sequence():
... nonlocal last
... next = last
... last = last**2 + c
... return next % N
...   def get_last(): return last
...   return sequence, get_last
... 
>>> f, get_last = make_sequence_non_recursive(1032)
>>> for i in range(100): print(i, f())
... 
0 2
1 3
2 8
3 63
4 872
5 831
6 152
7 399
8 272
9 711
10 872
11 831
12 152
13 399
14 272
15 711
16 872
17 831
18 152
19 399
20 272
21 711
22 872
23 831
^CTraceback (most recent call last):
  File "", line 1, in 
  File "", line 7, in sequence
KeyboardInterrupt
>>> x = get_last()

I'd rather not show the actual number, but

>>> x.bit_length()
12534884

So at this point it alreay would take 1.5 MB to store the number in binary. 
The actual format requires even a bit more memory:

>>> import sys
>>> sys.getsizeof(x)
1671344

So for every operation you have to touch a lot of memory -- and that takes 
time. 

Now let's apply Ben's modification:

>>> f, get_last = make_sequence_non_recursive(1032)
>>> for i in range(24): f()
... 
2
8
872
152
272
872
152
272
872
152
272
872
152
272
872
152
272
872
152
272
872
152
272
872
>>> get_last().bit_length()
8

OK. I dare to have that one printed:

>>> get_last()
152

I did not time it, but in general less memory touched will translate into 
faster execution. Expect a huge speed-up...

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: newb question about @property

[Steve D'Aprano]

On Mon, 2 Oct 2017 05:34 pm, Marko Rauhamaa wrote:

> I must say, though, I have yet to run into a need for descriptors.

You've never called a method?



-- 
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: newb question about @property

[Marko Rauhamaa]

Chris Angelico :

> On Mon, Oct 2, 2017 at 5:34 PM, Marko Rauhamaa  wrote:
>> I have *seen* a semi-useful decorator in code once
>> (@contextlib.contextmanager) but still would prefer explicit dunder
>> methods.
>
> [...] I'm not sure where dunder methods come into this, though, as
> they're completely unrelated.

A context manager must implement __enter__() and __exit__().
@contextlib.contextmanager implements them for you.

   https://docs.python.org/3/library/contextlib.html#contextlib.cont
   extmanager>


Marko
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: newb question about @property

[Thomas Jollans]

On 2017-10-02 10:51, Marko Rauhamaa wrote:
> Chris Angelico :
> 
>> On Mon, Oct 2, 2017 at 5:34 PM, Marko Rauhamaa  wrote:
>>> I have *seen* a semi-useful decorator in code once
>>> (@contextlib.contextmanager) but still would prefer explicit dunder
>>> methods.
>>
>> [...] I'm not sure where dunder methods come into this, though, as
>> they're completely unrelated.
> 
> A context manager must implement __enter__() and __exit__().
> @contextlib.contextmanager implements them for you.

Let's revisit the bit of Chris' mail you didn't quote:

On 2017-10-02 09:02, Chris Angelico wrote:
>
> There are plenty of programs that don't need decorators, but in some
> contexts, they are just beautiful. Building a web app in Flask or
> Django involves functions that get decorated to say what endpoints
> they handle, for instance.

The point is that there are plenty of useful decorators that have
nothing to do with dunder methods.


-- 
Thomas Jollans
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: on a very slow function

[Steve D'Aprano]

On Mon, 2 Oct 2017 06:41 pm, Peter Otten wrote:

 x = get_last()
> 
> I'd rather not show the actual number, but
> 
 x.bit_length()
> 12534884


Which is approximately 3773408 decimal digits.

Using the American system of large numbers, that's approximately a
duotrigintillion-duotrigintillion-duotrigintillion-duotrigintillion-
duotrigintillion-duotrigintillion-duotrigintillion-duotrigintillion-
duotrigintillion-duotrigintillion-duotrigintillion-duotrigintillion-
duotrigintillion-duotrigintillion-...-duotrigintillion or so, where the dots
represent thirty-eight thousand one hundred more duotrigintillions. 

A trifling number, much smaller than a googolplex.




-- 
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: newb question about @property

[Steve D'Aprano]

On Mon, 2 Oct 2017 07:51 pm, Marko Rauhamaa wrote:

> Chris Angelico :
> 
>> On Mon, Oct 2, 2017 at 5:34 PM, Marko Rauhamaa  wrote:
>>> I have *seen* a semi-useful decorator in code once
>>> (@contextlib.contextmanager) but still would prefer explicit dunder
>>> methods.
>>
>> [...] I'm not sure where dunder methods come into this, though, as
>> they're completely unrelated.
> 
> A context manager must implement __enter__() and __exit__().
> @contextlib.contextmanager implements them for you.

Nobody is holding a gun to your head and forcing you to use @contextmanager. Its
a convenience, nothing more. You can still write your own __enter__ and
__exit__ methods if you prefer.



-- 
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: on a very slow function

[Ben Bacarisse]

Steve D'Aprano  writes:

> On Mon, 2 Oct 2017 12:00 pm, Ben Bacarisse wrote:
>
>
>>> Better:
>>>
>>> last = (pow(last, 2, N) + (2 % N)) % N
>> 
>> You meant c rather than 2, I think.
>
> Oops, yes, that was a typo.
>
>
>> And I'm not convinced all the %Ns 
>> are worth while.
>
> They are all necessary.


I meant for the program.  It makes no difference to the result if last is
left entirely un-reduced (that was the original problem) so there is no
need (as far as the program is concerned) to ensure that last is fully
reduced.

Another naive timing tests suggests that 

  last = (pow(last, 2, N) + (c % N)) % N

is measurably slower than

  last = (pow(last, 2, N) + c) % N

and

  last = pow(last, 2, N) + c

is a little faster still.  None of these allow last to grow
uncontrollably.  Obviously we need to know more about the
potential range of N and c to do any realistic measurements. 

>>> will almost certainly be faster for large values of last.
>> 
>> Do you mean for large values of N?  If the calculations are mod N, it
>> seems like N will the number that matters.
>
> No, I meant "last". Although on testing, I think you might need so really big
> values before you'll see a difference. Like hundreds of digits or
> more.

Ah, again I meant for the program.  Any large value of last will exist
for one call only.  Obviously there will be /some/ point at which a
single call to the the three arg version of pow is better than ** and %,
but for that to sustained (in the program), N must be huge too.

Another simple test suggests that last * last is faster than last**2 so
the best so far (for the N and c originally posted) is the simpler:

last = (last * last + c) % N

Again I mean in the program as posted, not as a line on its own with
arbitrary values of 'last'.

-- 
Ben.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: on a very slow function

[bartc]

On 02/10/2017 08:41, Peter Otten wrote:

Daniel Bastos wrote:


def make_sequence_non_recursive(N, x0 = 2, c = -1):
   "What's wrong with this function?  It's very slow."
   last = x0
   def sequence():
 nonlocal last
 next = last
 last = last**2 + c
 return next % N
   return sequence



x.bit_length()

12534884

So at this point it alreay would take 1.5 MB to store the number in binary.
The actual format requires even a bit more memory:


import sys
sys.getsizeof(x)

1671344

So for every operation you have to touch a lot of memory -- and that takes
time.


If it recalculates 'last' once for each of those couple of dozen printed 
lines, that I doubt accessing a few MB of memory is the issue. More 
doing such a big calculation.


--
bartc
--
https://mail.python.org/mailman/listinfo/python-list

Re: on a very slow function

[Chris Angelico]

On Mon, Oct 2, 2017 at 10:24 PM, bartc  wrote:
> On 02/10/2017 08:41, Peter Otten wrote:
>>
>> Daniel Bastos wrote:
>>
>>> def make_sequence_non_recursive(N, x0 = 2, c = -1):
>>>"What's wrong with this function?  It's very slow."
>>>last = x0
>>>def sequence():
>>>  nonlocal last
>>>  next = last
>>>  last = last**2 + c
>>>  return next % N
>>>return sequence
>
>
> x.bit_length()
>>
>> 12534884
>>
>> So at this point it alreay would take 1.5 MB to store the number in
>> binary.
>> The actual format requires even a bit more memory:
>>
> import sys
> sys.getsizeof(x)
>>
>> 1671344
>>
>> So for every operation you have to touch a lot of memory -- and that takes
>> time.
>
>
> If it recalculates 'last' once for each of those couple of dozen printed
> lines, that I doubt accessing a few MB of memory is the issue. More doing
> such a big calculation.

Yes, but when you're working with a number with that many limbs, it's
bound to take some time. Squaring arbitrary numbers is a big job -
it's more efficient than O(n²) but still a lot worse than linear time,
so on huge numbers it's going to take hugely huge time.

*handwave furiously*

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Distributing multiple packages with on setup.py

[Jimmy Thrasibule]

> I do this with my stuff, but instead of keeping a common setup.py I have an
> elaborate and clumsy system that rolls a package or module distro on the
> fly, writing a setup.py file in the process.
>
> So each package/module I publish has a dict names "DISTINFO" in the top
> level file, looking like this:
>
>  DISTINFO = {
>  'keywords': ["python2", "python3"],
>  'classifiers': [
>  "Programming Language :: Python",
>  "Programming Language :: Python :: 2",
>  "Programming Language :: Python :: 3",
>  ],
>  'install_requires': [
>  'cs.app.flag',
>  'cs.env',
>  'cs.logutils',
>  'cs.pfx',
>  'cs.psutils',
>  ],
>  'entry_points': {
>  'console_scripts': [
>  'svcd = cs.app.svcd:main'
>  ],
>  },
>  }

I think I will head this direction. And with `setup.cfg
`_,
it is quite easy to keep the package's metadata in a standard way and
feed this to setup().

Regards,
Jimmy
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: on a very slow function

[Peter Otten]

bartc wrote:

> On 02/10/2017 08:41, Peter Otten wrote:
>> Daniel Bastos wrote:
>> 
>>> def make_sequence_non_recursive(N, x0 = 2, c = -1):
>>>"What's wrong with this function?  It's very slow."
>>>last = x0
>>>def sequence():
>>>  nonlocal last
>>>  next = last
>>>  last = last**2 + c
>>>  return next % N
>>>return sequence
> 
> x.bit_length()
>> 12534884
>> 
>> So at this point it alreay would take 1.5 MB to store the number in
>> binary. The actual format requires even a bit more memory:
>> 
> import sys
> sys.getsizeof(x)
>> 1671344
>> 
>> So for every operation you have to touch a lot of memory -- and that
>> takes time.
> 
> If it recalculates 'last' once for each of those couple of dozen printed
> lines, that I doubt accessing a few MB of memory is the issue. More
> doing such a big calculation.

You are probably right that the calculation requires a significant amount of 
the total time here, but it's not just "a few MB". If you look at

>>>  last = last**2 + c

the required memory doubles on every iteration. You will soon run into the 
problem even under the (overly optimistic) assumption that the calculation 
requires time proportional to memory. 


-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Distributing multiple packages with on setup.py

[Jimmy Thrasibule]

I think I will head this direction. And with `setup.cfg
`_,
it is quite easy to keep the package's metadata in a standard way and
feed this to setup().

Regards,
Jimmy
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: on a very slow function

[bartc]

On 02/10/2017 14:54, Peter Otten wrote:

bartc wrote:


On 02/10/2017 08:41, Peter Otten wrote:

Daniel Bastos wrote:


def make_sequence_non_recursive(N, x0 = 2, c = -1):
"What's wrong with this function?  It's very slow."
last = x0
def sequence():
  nonlocal last
  next = last
  last = last**2 + c
  return next % N
return sequence



x.bit_length()

12534884

So at this point it alreay would take 1.5 MB to store the number in
binary. The actual format requires even a bit more memory:


import sys
sys.getsizeof(x)

1671344

So for every operation you have to touch a lot of memory -- and that
takes time.


If it recalculates 'last' once for each of those couple of dozen printed
lines, that I doubt accessing a few MB of memory is the issue. More
doing such a big calculation.


You are probably right that the calculation requires a significant amount of
the total time here, but it's not just "a few MB". If you look at


  last = last**2 + c


the required memory doubles on every iteration. You will soon run into the
problem even under the (overly optimistic) assumption that the calculation
requires time proportional to memory.


On my machine, the iterations whizzed up the screen until I noticed it 
pausing on the 21st iteration, when the memory size of last was 0.5MB.


When I started last as "A", and multiplied by 2 at each step, it started 
to pause at the 27th iteration when the size of last was 268MB.


I would estimate then another 9 steps of the original (30th iteration) 
before memory usage has the same effect. Although it would probably 
already have ground to a halt long before then.


--
bartc
--
https://mail.python.org/mailman/listinfo/python-list

Re: style: single and multiple lines

[Marko Rauhamaa]

r...@zedat.fu-berlin.de (Stefan Ram):

> def f(x): return 2*x
>
>   . So this single-line style should not be that bad.

I very rarely allow myself to write single-line complex statements. It
is usually when defining exceptions:

   class SyntaxError(Exception): pass

if even then.

> def f(x):
> return 2*x

Despite PEP 8, I always separate binary operators from operands with
spaces:

def f(x):
return 2 * x

I have made myself abide by PEP 8 wrt named arguments (no space around
'='):

def f(x=7):
return 2 * x

y = f(x=3)


>   ? And is
>
> def f(x):
> y = x*2
> return y
>
>   better than
>
> def f(x):
> y = x*2; return y

Yes. Semicolons can be defended only in single-line shell command
trickery.

>   PS: The most difficult part for me is to write
>
> f(x)
>
>   instead of
>
> f( x )

For whatever reason, I find it clearest to put separate braces and
brackets with spaces:

vip = [ employee in faculty
for employee.pay_grade >= BOSS.pay_grade ]

return { "name" : "length", "value" : 17 }


Marko
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: style: single and multiple lines

[Steve D'Aprano]

On Tue, 3 Oct 2017 03:00 am, Stefan Ram wrote:

>   My copy of pep 8 (from 2016) says:

Why don't you look at the current version, which is conveniently available to
anyone on the internet, for free?

https://www.python.org/dev/peps/pep-0008/‎


(Last commit to the PEP was Jul 12, 2017.)


 
> Yes:
> 
> def f(x): return 2*x
> 
>   . So this single-line style should not be that bad.

That is specifically contrasted with using a lambda:

f = lambda x: 2*x

It shouldn't be read as a general approval to try to fit functions all in one
line.



>   So, is this better:
> 
> def f(x):
> return 2*x

Yes.


>   ? And is
> 
> def f(x):
> y = x*2
> return y
> 
>   better than
> 
> def f(x):
> y = x*2; return y

Hell yes! A thousand times YES.


One statement per line, except under the most unusual circumstances. Semi-colon
separated statements are a convenience of use at the command line and REPL.



-- 
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: on a very slow function

[Ian Kelly]

On Sun, Oct 1, 2017 at 8:14 PM, Steve D'Aprano
 wrote:
>
> On Mon, 2 Oct 2017 12:00 pm, Ben Bacarisse wrote:
>
>
> >> Better:
> >>
> >> last = (pow(last, 2, N) + (2 % N)) % N
> >
> > You meant c rather than 2, I think.
>
> Oops, yes, that was a typo.
>
>
> > And I'm not convinced all the %Ns
> > are worth while.
>
> They are all necessary.
>
>
> py> (2**75 + 7) % 12  # Expected value.
> 3
> py> ((2**75) % 12 + (7 % 12)) % 12  # Correct.
> 3
> py> (2**75) % 12 + (7 % 12)  # Incorrect.
> 15

No, only the final one is necessary. Modding the result of the
exponentiation might be useful for performance, but if c is expected
to be small then it may be pointless to mod that as well.

py> ((2**75) % 12 + 7) % 12  # Still correct.
3
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: on a very slow function

[Daniel Bastos]

r...@zedat.fu-berlin.de (Stefan Ram) writes:

> Daniel Bastos  writes:
>> That function produces a function which yields the values of the
>> sequence x^2 - 1 mod N
>
>   Thats a term with two free variables.
>   I am not sure what the sequence is.
>
>   And if that's
>
> ( x^2 - 1 )mod N

That's correct.

>   there might be a way to calculate it without
>   calculating the intermediate value of »x^2 - 1«.

I'd be amazed to see how.

Thanks!
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: on a very slow function

[Daniel Bastos]

Chris Angelico  writes:


[...]

> Maybe "linear_congruential" would be a good name for the function? I
> don't know.

Sounds good to me --- in absence of a smaller name.

> Anyhow, the basic memoization technique should help you some.

It did!  Thanks so much to you and to everyone who contributed to this
thread.  I really appreciated!
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: on a very slow function

[Daniel Bastos]

Ben Bacarisse  writes:

> Daniel Bastos  writes:
>
>> def make_sequence_non_recursive(N, x0 = 2, c = -1):
>>   "What's wrong with this function?  It's very slow."
>>   last = x0
>>   def sequence():
>> nonlocal last
>> next = last
>> last = last**2 + c
>> return next % N
>>   return sequence
>>
>> It crawls pretty soon.  Please advise?
>
> A mathematical rather than Python answer... change it to
>
>   last = (last**2 + c) % N
>   return next

Amazing!  That was an accident.  Thanks for pointing that out!
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: style: single and multiple lines

[Rhodri James]

On 02/10/17 17:00, Stefan Ram wrote:

   My copy of pep 8 (from 2016) says:

Yes:

def f(x): return 2*x

   . So this single-line style should not be that bad.

   However, I remember someone saying that the multiline
   style is more phytonic?

   So, is this better:

def f(x):
 return 2*x


Most of the time, yes.  The whitespace on the left-hand side is a good 
visual cue that something content-like is happening, in this case the 
body of a function.  The fact that it has shape makes it easier to 
comprehend at a glance.



   ? And is

def f(x):
 y = x*2
 return y

   better than

def f(x):
 y = x*2; return y


Hell yes.  One thought per line, please.

Something I keep repeating to clients is that whitespace is not the 
enemy.  Not even in C.  Judicious use of spacing can make code *much* 
easier to comprehend.  Densely-written code makes you work hard to break 
it down into manageable chunks; something as simple as the odd blank 
line to "paragraph" your code can make that a lot easier.


Experience also suggests a correlation between code that's hard to read 
and code that's rather crap.


--
Rhodri James *-* Kynesim Ltd
--
https://mail.python.org/mailman/listinfo/python-list

Re: newb question about @property

[Larry Hudson via Python-list]

On 10/01/2017 03:52 PM, Bill wrote:

Steve D'Aprano wrote:

The definitive explanation of descriptors is here:
https://docs.python.org/3/howto/descriptor.html


Thank you!  It is next on my list.   Then I'll try that Circle problem you mentioned as an 
exercise last night!  I don't expect run into any difficulties.  : )




Except perhaps for your sense of time...  "I'll try" implies the future, "last night" is the 
past.:-)   :-)


(Couldn't resist...)

--
 -=- Larry -=-
--
https://mail.python.org/mailman/listinfo/python-list

Re: newb question about @property

[Chris Angelico]

On Tue, Oct 3, 2017 at 6:23 AM, Larry Hudson via Python-list
 wrote:
> On 10/01/2017 03:52 PM, Bill wrote:
>>
>> Steve D'Aprano wrote:
>>>
>>> The definitive explanation of descriptors is here:
>>> https://docs.python.org/3/howto/descriptor.html
>>
>>
>> Thank you!  It is next on my list.   Then I'll try that Circle problem you
>> mentioned as an exercise last night!  I don't expect run into any
>> difficulties.  : )
>>
>
> Except perhaps for your sense of time...  "I'll try" implies the future,
> "last night" is the past.:-)   :-)
>
> (Couldn't resist...)

Yes, but "you mentioned" implies the past. I think you have an
operator precedence issue. Kappa

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: newb question about @property

[Bill]

Steve D'Aprano wrote:
Circle didn't use any setters, but I could have let you set the 
diameter, which in

turn would set the radius:

circle.radius = 2
assert circle.diameter == 4
circle.diameter == 2  # requires a setter
assert circle.radius == 1

Getting that to work is left as an exercise :-)

It WAS a good exercise!!  I was concerned about "infinite recursion" 
between my two property setters..  Thanks!   Next?  :)


Bill


import math


class Circle(object):
""" Define a circle class with radius and diameter""" def __init__(self, 
radius):
self.radius = radius
self.diameter =2*radius

@property def radius(self):
return self._radius

@radius.setter def radius(self, value):
self._radius = value
self._diameter=2*value

@property def diameter(self):
return self._diameter

@diameter.setter def diameter(self, value):
self._diameter = value
self._radius = value /2 @property def area(self):
return math.pi *self.radius **2 @property def circumference(self):
return 2 * math.pi *self.radius

## Start here ## circle = Circle(1 / math.pi)
print("Area = {:.2f}".format(circle.area))
print("Circumference = {:.2f}".format(circle.circumference))

circle.radius =2 assert circle.diameter ==4 print("Area = 
{:.2f}".format(circle.area))
print("Circumference = {:.2f}".format(circle.circumference))

circle.diameter =2 # requires a setter assert circle.radius ==1 print("Area = 
{:.2f}".format(circle.area))
print("Circumference = {:.2f}".format(circle.circumference))



--
https://mail.python.org/mailman/listinfo/python-list

Re: newb question about @property

[Bill]

Chris Angelico wrote:

On Tue, Oct 3, 2017 at 6:23 AM, Larry Hudson via Python-list
 wrote:

On 10/01/2017 03:52 PM, Bill wrote:

Steve D'Aprano wrote:

The definitive explanation of descriptors is here:
https://docs.python.org/3/howto/descriptor.html


Thank you!  It is next on my list.   Then I'll try that Circle problem you
mentioned as an exercise last night!  I don't expect run into any
difficulties.  : )


Except perhaps for your sense of time...  "I'll try" implies the future,
"last night" is the past.:-)   :-)

(Couldn't resist...)

Yes, but "you mentioned" implies the past. I think you have an
operator precedence issue. Kappa

ChrisA



Reading the "definitive explanation of descriptors" took me longer than 
expected..  I am as overly optimistic as any programming person..   ;)


Can you inspire me with a good decorator problem (standard homework 
exercise-level will be fine)?  Otherwise  I will go create one which 
will prints a row of asterisks before and after the call to the original 
function (which I think I should do). But maybe you have something more 
interesting? Or maybe you can refer me to a good source of Python 
problems, so I can bug you less?


Bill
--
https://mail.python.org/mailman/listinfo/python-list

Re: newb question about @property

[Chris Angelico]

On Tue, Oct 3, 2017 at 6:51 AM, Bill  wrote:
> Can you inspire me with a good decorator problem (standard homework
> exercise-level will be fine)?  Otherwise  I will go create one which will
> prints a row of asterisks before and after the call to the original function
> (which I think I should do). But maybe you have something more interesting?
> Or maybe you can refer me to a good source of Python problems, so I can bug
> you less?
>

Start with the row of asterisks. Then change your function to make the
"ending" line also say how long the function took to complete. That's
a handy tool (albeit a simplistic implementation of it).

You may find codewars.com useful, though I don't know how many
Python-specific puzzles they have. Or just search the web for
"programming puzzles" and see what you find.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: newb question about @property

[Ian Kelly]

On Mon, Oct 2, 2017 at 1:32 PM, Bill  wrote:
> @property def circumference(self):
> return 2 * math.pi *self.radius

Of course the *proper* formula here is just math.tau * self.radius.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: newb question about @property

[Steve D'Aprano]

On Tue, 3 Oct 2017 06:32 am, Bill wrote:

> Steve D'Aprano wrote:
>> Circle didn't use any setters, but I could have let you set the
>> diameter, which in
>> turn would set the radius:
>>
>> circle.radius = 2
>> assert circle.diameter == 4
>> circle.diameter == 2  # requires a setter
>> assert circle.radius == 1
>>
>> Getting that to work is left as an exercise :-)
>>
> It WAS a good exercise!!  I was concerned about "infinite recursion"
> between my two property setters..  Thanks!   Next?  :)
> 
> Bill
> 
> 
> import math
> 
> 
> class Circle(object):
>  """ Define a circle class with radius and diameter"""
>  def __init__(self, radius):
>  self.radius = radius
>  self.diameter =2*radius

There's no need to set the radius and the diameter, as one is completely derived
from the other and the transformation is cheap enough to perform on the fly as
needed.

Consider what happens if, due to a bug or an accident, you end up with a Circle
instance that says the radius is 5 and the diameter is 20. They can't *both* be
right, and you will get inconsistent results depending on whether your other
methods happen to use the diameter or the radius.

Instead, we should steal the Single Source Of Truth principle from informations
systems theory:

https://en.wikipedia.org/wiki/Single_source_of_truth

https://en.wikipedia.org/wiki/Single_version_of_the_truth

There are valid cases for violating this principle in object design, e.g. caches
are technically a violation of SSOT but an acceptable one.

With that in mind, your class simplifies to:

class Circle(object):
""" Define a circle class with radius and diameter"""
def __init__(self, radius):
self.radius = radius

@property
def radius(self):
return self._radius

@radius.setter
def radius(self, value):
self._radius = value

@property
def diameter(self):
return 2*self._radius

@diameter.setter
def diameter(self, value):
self._radius = value/2

@property
def area(self):
return math.pi*self.radius**2

@property
def circumference(self):
return math.pi*self.diameter



-- 
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: newb question about @property

[Bill]

Steve D'Aprano wrote:

There's no need to set the radius and the diameter, as one is completely derived

from the other


Good point; I'm glad I submitted my code for grading.  Sort of a "trick 
question" to ask me to add diameter and then take off points because I 
used it!  ; )


Bill




and the transformation is cheap enough to perform on the fly as
needed.

Consider what happens if, due to a bug or an accident, you end up with a Circle
instance that says the radius is 5 and the diameter is 20. They can't *both* be
right, and


--
https://mail.python.org/mailman/listinfo/python-list

Re: INSTRUCTOR SOLUTIONS MANUAL Linear Systems And Signals 2nd ED by B P Lathi

[mosama221122]

i need instructor of second edition of linear system and signals by lathi
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: newb question about @property

[Bill]

Chris Angelico wrote:

Decorators are fairly straight-forward if you understand higher-order
functions.  

ChrisA



I was just minding my own business, and thought to write my first 
decorator for a simple *recursive* function f.  The decorator WORKS if f 
does not make a call to itself.Otherwise, f seems to have 
"difficulty" calling itself (I get a typerror, f(n) has value 
"NoneType").   What is the explanation for this?  Does f have a new name 
because it has a decorator on it now?


Note: I am not using functools.wraps since I don't yet understand the 
reason I might do that yet (first things first... ).


Thanks!

Bill
--
https://mail.python.org/mailman/listinfo/python-list

Re: newb question about @property

[Chris Angelico]

On Tue, Oct 3, 2017 at 2:39 PM, Bill  wrote:
> Chris Angelico wrote:
>>
>> Decorators are fairly straight-forward if you understand higher-order
>> functions.  
>>
>> ChrisA
>
>
>
> I was just minding my own business, and thought to write my first decorator
> for a simple *recursive* function f.  The decorator WORKS if f does not make
> a call to itself.Otherwise, f seems to have "difficulty" calling itself
> (I get a typerror, f(n) has value "NoneType").   What is the explanation for
> this?  Does f have a new name because it has a decorator on it now?
>
> Note: I am not using functools.wraps since I don't yet understand the reason
> I might do that yet (first things first... ).

I would recommend posting your code, possibly in a new thread.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: INSTRUCTOR SOLUTIONS MANUAL Linear Systems And Signals 2nd ED by B P Lathi

[Steve D'Aprano]

On Tue, 3 Oct 2017 12:54 pm, mosama221...@gmail.com wrote:

> i need instructor of second edition of linear system and signals by lathi

Don't reply to spammers and don't reply to them. They are the scum of the earth.

They are literally criminals, they use computer viruses and malware to hijack
people's computers to send their spam, and you want to trust them and buy from
them?


-- 
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: newb question about @property

[Bill]

Bill wrote:

Chris Angelico wrote:

Decorators are fairly straight-forward if you understand higher-order
functions.  

ChrisA



I was just minding my own business, and thought to write my first 
decorator for a simple *recursive* function f.  The decorator WORKS if 
f does not make a call to itself 
(it really wasn't). 


Using the (PyCharm) debugger, I determined that my inner function that 
was calling my wrapped (Fibonacci sequence) function but wasn't 
returning anything to the invoking environment. I fixed it for the sake 
of a good, if costly, lesson.  Not much of a wrapper, but it "works".  A 
version which merely prints a tab before the function call, instead of a 
row of asterisks produces output which is more interesting to look at.


def wrap(func):
def inner(*args, **kwargs):
print('*'*20)
a= func(*args, **kwargs)
print(a)
print('*'*20)
return a
return inner


Bill

--
https://mail.python.org/mailman/listinfo/python-list

Solution Manuals and Testbanks 2017-2018

[ranasaad935]

Do u have testbanks for ???

THE LAW OF WORK: INDUSTRIAL RELATIONS AND COLLECTIVE BARGAINING

Author(s): David J. Doorey
 
ISBN: 978-1-77255-166-2
 
Publisher:Emond Publishing
-- 
https://mail.python.org/mailman/listinfo/python-list