Re: newb question about @property

On 05/10/2017 14:13, Steve D'Aprano wrote: On Thu, 5 Oct 2017 10:51 pm, bartc wrote: Am I allowed to say that it all seems a bit of a mess? You may or may not be pleased to learn that there's a push to create a "record like" or "struct like" datatype for Python 3.7 or 3.8, tentatively

Re: newb question about @property

On Thu, 5 Oct 2017 10:51 pm, bartc wrote: > Am I allowed to say that it all seems a bit of a mess? You may or may not be pleased to learn that there's a push to create a "record like" or "struct like" datatype for Python 3.7 or 3.8, tentatively called a "Data Class" for now. The proposed

Re: newb question about @property

On 05/10/2017 12:29, Gregory Ewing wrote: bartc wrote: Result? You can't just look at my 'any' class and see what fields it uses. You can't even just look at the static source code. You have to run the program to find out. And it might be different each time. You can usually get a pretty

Re: newb question about @property

bartc wrote: Result? You can't just look at my 'any' class and see what fields it uses. You can't even just look at the static source code. You have to run the program to find out. And it might be different each time. You can usually get a pretty good idea of what attributes a class has by

Re: newb question about @property

On Wed, 4 Oct 2017 11:46 pm, Rhodri James wrote: > On 04/10/17 12:07, bartc wrote: >> I've seen that example brought up before. It still doesn't cut any ice. >> >> You might as well be condescending of someone who finds Joyce or Proust >> unreadable, and prefers McBain, Simenon or Chandler.

Re: Constants [was Re: newb question about @property]

On Thu, 5 Oct 2017 04:00 am, Paul Moore wrote: > I wonder - would the people who want "real constants" find the > following confusing: > from demo import foo foo = 14 foo > 14 > > It's fundamental to the way the import function works, and how names > in Python behave, but I can

Re: newb question about @property

On Thu, 5 Oct 2017 09:08 am, bartc wrote: [...] > And when I tried, it didn't really work in Python 2 (extra attributes > could still be created, and .__slots__ wasn't readonly); only Py3. Not quite, but I don't blame you for the mistake. Its an easy one to make. __slots__ only works in "new

Re: newb question about @property

On 04/10/2017 17:02, Rhodri James wrote: On 04/10/17 16:33, Paul Moore wrote: It's not an advantage or a disadvantage, just an approach. Many people like it, you may not. Specifically, yes you can't "just declare a lightweight struct or record with exactly two fields". Actually you can:

Re: newb question about @property

On Wed, Oct 4, 2017 14:03 PM, bartc wrote > "A property, in some object-oriented programming languages, is a special >sort of class member, intermediate in functionality between a field (or >data member) and a method." > >But Python has some problems just in using fields. If

Re: Constants [was Re: newb question about @property]

On 4 October 2017 at 17:15, Ian Kelly wrote: > On Wed, Oct 4, 2017 at 9:08 AM, Steve D'Aprano > wrote: >> But in large projects, especially those where you cannot trust every module >> in >> the project to obey the naming convention, I can see

Re: newb question about @property

On 4 October 2017 at 17:02, Rhodri James wrote: > Actually you can: > class Point: > ... __slots__ = ("x", "y") > ... def __init__(self, x, y): > ... self.x = x > ... self.y = y > ... def __str__(self): > ... return "({0},{1})".format(self.x, self.y) >

Re: Constants [was Re: newb question about @property]

On Wed, Oct 4, 2017 at 9:08 AM, Steve D'Aprano wrote: > But in large projects, especially those where you cannot trust every module in > the project to obey the naming convention, I can see that this lack might > contribute to the perception, if not the fact, of Python

Re: newb question about @property

On 04/10/17 16:33, Paul Moore wrote: On 4 October 2017 at 16:03, bartc wrote: No error. Some would perceive all this as an advantage, but it means you can't just declare a lightweight struct or record 'Point' with exactly two fields x and y. You have to use other solutions

Re: newb question about @property

On 4 October 2017 at 16:03, bartc wrote: > No error. Some would perceive all this as an advantage, but it means you > can't just declare a lightweight struct or record 'Point' with exactly two > fields x and y. You have to use other solutions ('namedtuples' or whatever, > which

Constants [was Re: newb question about @property]

On Thu, 5 Oct 2017 12:41 am, Ian Kelly wrote: > Python has the simplest named constants of all: > > C = 12345 > > As long as you don't subsequently change it, it's a constant. And it's > very simple because it works just like any other variable. I do feel that the lack of constants[1] is a

Re: newb question about @property

On 04/10/2017 14:41, Ian Kelly wrote: On Wed, Oct 4, 2017 at 5:07 AM, bartc wrote: For that matter, I don't think Python has such a feature either. So that you write for example: const C = 123345 and then whenever C appears within the code, it's implemented as:

Re: newb question about @property

On Wed, Oct 4, 2017 at 5:07 AM, bartc wrote: > It is just being elitist. I have a preference for keeping things simple and > avoiding unnecessary complexity. But with programming languages many do have > a penchant for the latter. > > As an example, a recent discussion on

Re: newb question about @property

On 04/10/17 12:07, bartc wrote: I've seen that example brought up before. It still doesn't cut any ice. You might as well be condescending of someone who finds Joyce or Proust unreadable, and prefers McBain, Simenon or Chandler. (Sorry, can't think of any modern pulp novelists). I don't

Re: newb question about @property

On 04/10/2017 06:32, Steve D'Aprano wrote: On Wed, 4 Oct 2017 02:00 am, bartc wrote: Does all this advanced stuff (which I don't understand and which doesn't look very appealing either; hopefully I will never come across such code) still count as programming? I could not have hoped to see a

Re: newb question about @property

On Wed, 4 Oct 2017 02:00 am, bartc wrote: > Does all this advanced stuff (which I don't understand and which doesn't > look very appealing either; hopefully I will never come across such > code) still count as programming? I could not have hoped to see a more perfect example of the Blub effect

Re: newb question about @property

On Tue, Oct 3, 2017 at 9:16 AM, Jorge Gimeno wrote: > No, I see this as teaching the skills involved to drive a car. Practicing a > turn, scanning gauges, and checking blind spots are all a part of driving. > When one is learning, it's easier to learn these in isolation so

Re: newb question about @property

Steve D'Aprano wrote: On Tue, 3 Oct 2017 06:51 am, Bill wrote: Can you inspire me with a good decorator problem (standard homework exercise-level will be fine)? Here is a nice even dozen problems for you. Please ask for clarification if any are unclear. Thank you for sharing the problems

Re: newb question about @property

No, I see this as teaching the skills involved to drive a car. Practicing a turn, scanning gauges, and checking blind spots are all a part of driving. When one is learning, it's easier to learn these in isolation so when the problem must be solved in real time, you know what to do. This is no

Re: newb question about @property

On 03/10/2017 15:39, Ian Kelly wrote: On Tue, Oct 3, 2017 at 4:41 AM, Steve D'Aprano wrote: On Tue, 3 Oct 2017 06:51 am, Bill wrote: Can you inspire me with a good decorator problem (standard homework exercise-level will be fine)? Here is a nice even dozen

Re: newb question about @property

On Tue, Oct 3, 2017 at 4:41 AM, Steve D'Aprano wrote: > On Tue, 3 Oct 2017 06:51 am, Bill wrote: > >> Can you inspire me with a good decorator problem (standard homework >> exercise-level will be fine)? > > > Here is a nice even dozen problems for you. Please ask for

Re: newb question about @property

On Tue, 3 Oct 2017 10:01 pm, Lele Gaifax wrote: > Steve D'Aprano writes: > >> (9) [ADVANCED] Modify the decorator from (8) to take an argument specifying >> the path to a file, and use the logging module to log the details to that >> file instead of printing them. >

Re: newb question about @property

Steve D'Aprano writes: > (9) [ADVANCED] Modify the decorator from (8) to take an argument specifying > the > path to a file, and use the logging module to log the details to that file > instead of printing them. This may suffer of excessive creativity, as usually

Re: newb question about @property

On Tue, 3 Oct 2017 06:51 am, Bill wrote: > Can you inspire me with a good decorator problem (standard homework > exercise-level will be fine)? Here is a nice even dozen problems for you. Please ask for clarification if any are unclear. (1) Write a decorator which simply prints a descriptive

Re: newb question about @property

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

Re: newb question about @property

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

Re: newb question about @property

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.

Re: newb question about @property

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

Re: newb question about @property

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

Re: newb question about @property

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

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 >

Re: newb question about @property

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

Re: newb question about @property

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 :-)

Re: newb question about @property

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

Re: newb question about @property

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

Re: newb question about @property

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 >>>

Re: newb question about @property

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.

Re: newb question about @property

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

Re: newb question about @property

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. --

Re: newb question about @property

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 >

Re: newb question about @property

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,

Re: newb question about @property

On Sunday, October 1, 2017 at 6:47:34 PM UTC+1, MRAB wrote: > On 2017-10-01 02:52, Stefan Ram wrote: > > MRAB writes: > >>raise ValueError("Temperature below -273 is not possible") > > > >-273.15 > > > I think you've trimmed a little too much. In my reply I was only copying > what someone

Re: newb question about @property

On Mon, Oct 2, 2017 at 9:47 AM, Bill wrote: > Stephan Houben wrote: >> >> Op 2017-10-01, Bill schreef : >>> >>> I watched an example on YouTube where someone wrote a simple descriptor >>> ("@Time_it) to output the amount of time that it took

Re: newb question about @property

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. : ) --

Re: newb question about @property

Stephan Houben wrote: Op 2017-10-01, Bill schreef : I watched an example on YouTube where someone wrote a simple descriptor ("@Time_it) to output the amount of time that it took ordinary functions to complete.To be honest, I AM interested in descriptors. Are you

Re: newb question about @property

Steve D'Aprano wrote: On Sun, 1 Oct 2017 05:46 pm, Bill wrote: If you were going to show non-Python users, say science undergraduates and faculty, that Python is an interesting tool (in 45 minutes), would one delve into descriptors? Hell no :-) Oops, I see I used the word "descriptor", where

Re: newb question about @property

Op 2017-10-01, Bill schreef : > Steve D'Aprano wrote: >> >> [1] Technically, the interpreter knows nothing about properties. What >> it cares about is *descriptors*. Properties are just one kind of >> descriptor, as are methods. But I'm intentionally not talking about >>

Re: newb question about @property

Op 2017-10-01, Bill schreef : > I watched an example on YouTube where someone wrote a simple descriptor > ("@Time_it) to output the amount of time that it took ordinary functions > to complete.To be honest, I AM interested in descriptors. Are you sure you are not

Re: newb question about @property

On 2017-10-01 02:52, Stefan Ram wrote: MRAB writes: raise ValueError("Temperature below -273 is not possible") -273.15 I think you've trimmed a little too much. In my reply I was only copying what someone else had written. --

Re: newb question about @property

On 01/10/17 03:52, Stefan Ram wrote: > MRAB writes: >> raise ValueError("Temperature below -273 is not possible") > -273.15 > Either way, that depends. https://en.wikipedia.org/wiki/Negative_temperature#Examples --

Re: newb question about @property

On Sun, 1 Oct 2017 05:46 pm, Bill wrote: > If you were going to show non-Python users, say science undergraduates > and faculty, that Python is an interesting tool (in 45 minutes), would > one delve into descriptors? Hell no :-) I think there's a hierarchy of

Re: newb question about @property

Steve D'Aprano wrote: [1] Technically, the interpreter knows nothing about properties. What it cares about is *descriptors*. Properties are just one kind of descriptor, as are methods. But I'm intentionally not talking about the gory details of descriptors. Feel free to ask if you care, but

Re: newb question about @property

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 :-)

Re: newb question about @property

On Sun, 1 Oct 2017 11:07 am, Bill wrote: > You and Ned are both right. Up until a few minutes ago, I wasn't > thinking about a class having more than 1 attribute that I wanted to > change. And now I realize that __get__ doesn't really make sense in > that context (in the back of my mind was the

Re: newb question about @property

On 30Sep2017 20:07, Bill wrote: think all of this would have made a bit more sense (to me), if instead of just "@property", the syntax was "@property.getter". Perhaps, but nobody wants to type this. Also many properties are ready only, so that is the default. Now

Re: newb question about @property

On 2017-10-01 01:07, Bill wrote: Steve D'Aprano wrote: On Sun, 1 Oct 2017 08:47 am, Bill wrote: I spent a few hours experimenting with @property. To my mind it seems like it would be preferable to just define (override) instance methods __get__(), __set__(), and possibly __del__(), as

Re: newb question about @property

Ned Batchelder wrote: On 9/30/17 7:18 PM, Bill wrote: Ned Batchelder wrote: On 9/30/17 5:47 PM, Bill wrote: I spent a few hours experimenting with @property. To my mind it seems like it would be preferable to just define (override) instance methods __get__(), __set__(), and possibly

Re: newb question about @property

Steve D'Aprano wrote: On Sun, 1 Oct 2017 08:47 am, Bill wrote: I spent a few hours experimenting with @property. To my mind it seems like it would be preferable to just define (override) instance methods __get__(), __set__(), and possibly __del__(), as desired, as I could easily provide them

Re: newb question about @property

On 9/30/17 7:18 PM, Bill wrote: Ned Batchelder wrote: On 9/30/17 5:47 PM, Bill wrote: I spent a few hours experimenting with @property. To my mind it seems like it would be preferable to just define (override) instance methods __get__(), __set__(), and possibly __del__(), as desired, as I

Re: newb question about @property

On Sun, 1 Oct 2017 08:47 am, Bill wrote: > I spent a few hours experimenting with @property. To my mind it seems > like it would be preferable to just define (override) instance methods > __get__(), __set__(), and possibly __del__(), as desired, as I could > easily provide them with "ideal"

Re: newb question about @property

On 9/30/17 5:47 PM, Bill wrote: I spent a few hours experimenting with @property. To my mind it seems like it would be preferable to just define (override) instance methods __get__(), __set__(), and possibly __del__(), as desired, as I could easily provide them with "ideal" customization. Am I

newb question about @property

I spent a few hours experimenting with @property. To my mind it seems like it would be preferable to just define (override) instance methods __get__(), __set__(), and possibly __del__(), as desired, as I could easily provide them with "ideal" customization. Am I overlooking something? Bill --