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 :-)
Op 2017-09-30, Marko Rauhamaa schreef :
> Robert L. is only trolling. He uses fake technical comments to spread
> white supremacy in his signatures.
My apologies.
Stephan
--
https://mail.python.org/mailman/listinfo/python-list
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
On Saturday, September 30, 2017 at 9:03:32 PM UTC+1, Stephan Houben wrote:
> Op 2017-09-27, Robert L. schreef :
> > (sequence-fold + 0 #(2 3 4))
> > ===>
> > 9
> >
> > In Python?
>
> >>> sum([2, 3, 4])
> 9
Dow you have to keep replying to this out and out racist, as none of his posts
have any re
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 I am forced to ask the ques
Chris Angelico writes:
> USA:
> Alabama:
> Abbeville
> Addison
> ...
> and then, as Paul suggested, write a simple parser to read it.
That looks like YAML, which there's already a library for. I'm not
crazy about it but it might be an ok choice for this.
--
https://m
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 desired,
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 __del__()
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 wi
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 cou
Not in response to any particular note, but to the thread as a whole.
Regarding how beginners make tweaks and changes at random,
hoping that the bug will disappear, where experts tend to be a bit
more methodical in their bug-fixing.
Here at academia I have taught a little bit of partial correctne
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 could easily provide them with "idea
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" custom
On 30Sep2017 00:52, Jimmy Thrasibule wrote:
I've reorganized my Python project to be under a same name umbrella.
My project can now be seen as multiple subsystems than can depend on
each other. That means that every sub-package can now be distributed
alone so that only required dependencies can
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
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
--
Stephan Houben :
> Op 2017-09-27, Robert L. schreef :
>> (sequence-fold + 0 #(2 3 4))
>> ===>
>> 9
>>
>> In Python?
>
sum([2, 3, 4])
> 9
Robert L. is only trolling. He uses fake technical comments to spread
white supremacy in his signatures.
Marko
--
https://mail.python.org/mailman/listin
Op 2017-09-27, Robert L. schreef :
>> > (defun myloop (initial final increment)
>> > (loop for i = initial then (+ i increment)
>> > while (< i final)
>> > do (print i)
>> > finally (let ((i final)) (print i
>> >
> In Python?
myloop = lambda *args: print("{}{}".forma
Op 2017-09-27, Robert L. schreef :
> (sequence-fold + 0 #(2 3 4))
> ===>
> 9
>
> In Python?
>>> sum([2, 3, 4])
9
--
https://mail.python.org/mailman/listinfo/python-list
On 30/09/2017 19:12, Stefan Ram wrote:
I would like to write source code similar to:
country( 'USA' )
state( 'Alabama' )
town( 'Abbeville' )
town( 'Addison' )
state( 'Arizona' )
town( 'Apache Junction' )
town( 'Avondale )
town( 'Benson' )
using "semantic ind
On Sun, Oct 1, 2017 at 5:12 AM, Stefan Ram wrote:
> I would like to write source code similar to:
>
> country( 'USA' )
> state( 'Alabama' )
> town( 'Abbeville' )
> town( 'Addison' )
> state( 'Arizona' )
> town( 'Apache Junction' )
> town( 'Avondale )
> town( 'Benson' )
>
r...@zedat.fu-berlin.de (Stefan Ram) writes:
> I would like to write source code similar to:
> country( 'USA' )
> state( 'Alabama' )
Aside from the workaround that I mentioned, this looks more like data
than code. Maybe you really want to create a nested structure
(dictionaries, JSON, XML or
r...@zedat.fu-berlin.de (Stefan Ram) writes:
> I would like to write source code similar to:
> country( 'USA' )
> state( 'Alabama' ) ...
> It seems I can't do this with Python. Is there any workaround?
_= country( 'USA' )
_= state( 'Alabama' )
_= town( 'Abbeville' )
_= town
On 30 September 2017 at 21:12, Stefan Ram wrote:
> I would like to write source code similar to:
>
> country( 'USA' )
> state( 'Alabama' )
> town( 'Abbeville' )
> town( 'Addison' )
> state( 'Arizona' )
> town( 'Apache Junction' )
> town( 'Avondale )
> town( 'Benson' )
>
We are happy to announce a new format our Media Workgroup is
experimenting with:
The EuroPython Podcast
--
The podcast intends to be a view on the European Python community. We
will comment and talk about the latest news from the EuroPython
Society last news, interview guests
On 29/09/2017 18:15, Vincent Vande Vyvre wrote:
Is it a reason why my messages appears always a long time (today 9
hours) on the list after I send it ?
Vincent,
Your address is being caught in our moderation traps for some reason. At
the moment I'm away and on-line less than usual. Perhaps t
Some of my messages take about an hour. From looking at the headers in
these cases, it looks like the delay is always before the message is
received (i.e., accepted) by mail.python.org. This looks like greylisting.
Yes, greylisting is one of the anti-spam arrows in the wider on
mail.python.org. H
On 29/09/17 19:15, Vincent Vande Vyvre wrote:
> Is it a reason why my messages appears always a long time (today 9
> hours) on the list after I send it ?
>
> Send at 19:14 UTC+2
>
>
> Vincent
>
Some of my messages take about an hour. From looking at the headers in
these cases, it looks like the de
On 9/29/17, Rob Gaddi wrote:
> On 09/29/2017 10:54 AM, Stefan Ram wrote:
>>In some languages, printing »'\n'«, the Unicode code point 10,
>>will have the effect of printing a line terminator, which might
>>mean that the output device actually receives »\r\n«.
>>
>>The line terminat
29 matches
Mail list logo