On Wednesday, March 21, 2018 at 5:37:48 AM UTC+5:30, Paul Rubin wrote:
> Ben Finney writes:
> > Any program which needs to interact with systems outside itself – which
> > is to say, any program which performs useful work, ultimately – must
> > have side effects. So it's absurd to advocate removin
Steven D'Aprano writes:
> What they came up with is that its really hard to do useful work for
> large applications with 100% pure functional programming styles. As you
> add functional techniques to your code, you find your code quality
> increasing. Things like pure functions with no hidden
Neil Cerutti writes:
> The Introduction to Computer Science class I'm taking divided program
> design into two categories: Top Down Design, and Object Oriented
> Design. It's good, because it reminded me of the wisdom of dividing
> memory into Random Access and Read Only.
>
> My automotive course
On Tuesday, March 20, 2018 at 1:10:19 PM UTC-4, Irv Kalb wrote:
> I am aware of all the issues involved. My example code was an attempt to
> demonstrate the clearest, simplest case possible. My question is not about
> this small case. In classes designed for full games, I often have a "reset"
On 2018-03-20, Tom Evans via Python-list wrote:
> On Tue, Mar 20, 2018 at 5:25 PM, Grant Edwards
> wrote:
>> On 2018-03-20, Neil Cerutti wrote:
>>
>>> My automotive course will probaly divide cars into Automatic
>>> Transmission, and Front Wheel Drive.
>>
>> I get your point: the two characterist
On Tue, Mar 20, 2018 at 5:25 PM, Grant Edwards
wrote:
> On 2018-03-20, Neil Cerutti wrote:
>
>> My automotive course will probaly divide cars into Automatic
>> Transmission, and Front Wheel Drive.
>
> I get your point: the two characteristics are, in theory, orthogonal.
> But, in the US, the two
On Wed, Mar 21, 2018 at 4:18 AM, Neil Cerutti wrote:
> The Introduction to Computer Science class I'm taking divided
> program design into two categories: Top Down Design, and Object
> Oriented Design. It's good, because it reminded me of the wisdom
> of dividing memory into Random Access and Read
On 2018-03-20, Neil Cerutti wrote:
> My automotive course will probaly divide cars into Automatic
> Transmission, and Front Wheel Drive.
I get your point: the two characteristics are, in theory, orthogonal.
But, in the US, the two appear to be correlated. ISTM that cars with
manual transmission
On 2018-03-20, Rick Johnson wrote:
> On Tuesday, March 20, 2018 at 6:14:34 AM UTC-5, Alister wrote:
>> On Tue, 20 Mar 2018 08:52:29 +, Steven D'Aprano wrote:
>> > On Tue, 20 Mar 2018 02:43:13 -0400, Terry Reedy wrote:
>> >
>> > > I think a claim that in all programs all attributes
>> > > shou
> On Mar 19, 2018, at 10:27 AM, Ned Batchelder wrote:
>
> On 3/19/18 1:04 PM, Irv Kalb wrote:
>> I am building some classes for use in future curriculum. I am using PyCharm
>> for my development. On the right hand edge of the PyCharm editor window,
>> you get some little bars indicating warn
On Wed, Mar 21, 2018 at 2:15 AM, Steven D'Aprano
wrote:
> On Tue, 20 Mar 2018 11:14:13 +, Alister via Python-list wrote:
>
>> but why would a functional programmer be programming an OOP class?
>
> I read a really good blog post a while back, which I sadly can no longer
> find (I had it bookmar
On Tue, 20 Mar 2018 11:14:13 +, Alister via Python-list wrote:
> but why would a functional programmer be programming an OOP class?
I read a really good blog post a while back, which I sadly can no longer
find (I had it bookmarked until Firefox ate my bookmarks) that discussed
exactly that
On Tuesday, March 20, 2018 at 1:43:39 AM UTC-5, Terry Reedy wrote:
[...]
> > class Card():
> >
> > BACK_OF_CARD_IMAGE = pygame.image.load('images/backOfCard.png')
> >
> > def __init__(self, window, name, suit, value):
> > self.window = window
> > self.suit = suit
> >
On Tuesday, March 20, 2018 at 6:14:34 AM UTC-5, Alister wrote:
> On Tue, 20 Mar 2018 08:52:29 +, Steven D'Aprano wrote:
> > On Tue, 20 Mar 2018 02:43:13 -0400, Terry Reedy wrote:
> >
> > > I think a claim that in all programs all attributes
> > > should be set *in* __init__, as opposed to *dur
On 2018-03-20, Alister via Python-list wrote:
> but why would a functional programmer be programming an OOP class?
Part of a 12-step recovery plan?
;)
--
Grant Edwards grant.b.edwardsYow! Hello. I know
at the divorce rate
On Tue, 20 Mar 2018 08:52:29 +, Steven D'Aprano wrote:
> On Tue, 20 Mar 2018 02:43:13 -0400, Terry Reedy wrote:
>
>> I think a claim that in all programs all attributes should be set *in*
>> __init__, as opposed to *during* initialization, is wrong. All
>> attribute setting is side-effect fr
On Tue, 20 Mar 2018 02:43:13 -0400, Terry Reedy wrote:
> I think a claim that in all programs all attributes should be set *in*
> __init__, as opposed to *during* initialization, is wrong. All
> attribute setting is side-effect from a functional view (and usually
> 'bad' to a functionalist). The
On 3/19/2018 1:04 PM, Irv Kalb wrote:
However, there is one warning that I am seeing often, an > I'm not sure about
how to handle it. The warning I see is:
"Instance attribute defined outside of __init__ ..."
Style checkers are notorious for sometimes giving bad advice and being
overly opi
On Mon, 19 Mar 2018 10:04:53 -0700, Irv Kalb wrote:
> Some people say
> that this type of thing is fine and these warnings should just be
> ignored. While others say that all instance variables should be defined
> in the __init__ method.
Whenever anyone says "you should do this", the question to
Irv Kalb writes:
> In this class, I get warnings on the single lines of the conceal and
> reveal methods.
This is good! It prompts the question: Why are those methods defined as
they are?
If those methods are only ever intended to set the value of an
attribute: Why not just set that attribute d
On Tue, Mar 20, 2018 at 4:25 AM, Ethan Furman wrote:
> Define them in __init__; otherwise, you get an error if reveal() is called
> before conceal() is. Also, a card is either revealed or concealed, it can't
> be both and it can't be neither -- so set it in __init__.
__init__ calls conceal.
Chr
On 03/19/2018 10:04 AM, Irv Kalb wrote:
I am building some classes for use in future curriculum. I am using PyCharm
for my development. On the right hand edge of the PyCharm editor window, you
get some little bars indicating warnings or errors in your code. I like this
feature and try to c
On 3/19/18 1:04 PM, Irv Kalb wrote:
I am building some classes for use in future curriculum. I am using PyCharm
for my development. On the right hand edge of the PyCharm editor window, you
get some little bars indicating warnings or errors in your code. I like this
feature and try to clean
I am building some classes for use in future curriculum. I am using PyCharm
for my development. On the right hand edge of the PyCharm editor window, you
get some little bars indicating warnings or errors in your code. I like this
feature and try to clean up as many of those as I can. However
24 matches
Mail list logo
