Neil Cerutti writes:
> On 2011-08-29, Chris Angelico wrote:
> > Chorus? Does that imply that you sing? Neat :)
>
> Wait... not all Python programmers sing?
All Python programmers sing. Some of them should not.
--
\ “To be is to do” —Plato |
`\
On Tue, Aug 30, 2011 at 4:40 AM, Neil Cerutti wrote:
> Wait... not all Python programmers sing?
I do, and there seems to be more than coincidental overlap between
musos and coders.
> The problem with that scenario is that, in real life, there's
> more than one Cerutti.Neil, and they like to move
On 2011-08-29, Chris Angelico wrote:
>> In my house, I'm dad. In my chorus, I'm Neil. In town I'm Neil
>> Cerutti, and in the global scope I have to use a meaningless
>> unique identifier. Hopefully no Python namespace ever gets that
>> big.
>
> Chorus? Does that imply that you sing? Neat :)
Wait
On Tue, Aug 30, 2011 at 12:52 AM, Neil Cerutti wrote:
>> I would split the function only when both halves (caller and
>> callee) can be given short and useful names - if you can't
>> explain what a block of code does in a few words, it's probably
>> a poor choice for splitting out into a function.
On 2011-08-26, Chris Angelico wrote:
> On Sat, Aug 27, 2011 at 1:48 AM, Tobiah
> wrote:
>> While I understand and agree with that basic tenet, I think
>> that the capitalized 'ONLY' is too strong. ?I do split out
>> code into function for readability, even when the function
>> will only be called
smith jack wrote:
i have heard that function invocation in python is expensive, but make
lots of functions are a good design habit in many other languages, so
is there any principle when writing python function?
for example, how many lines should form a function?
Once Abraham Lincoln was asked
On 8/27/11 3:21 PM, Emile van Sebille wrote:
> On 8/27/2011 2:57 PM Ben Finney said...
>> Emile van Sebille writes:
>>
>>> Code is first and foremost written to be executed.
>>
>
>
>> “Programs must be written for people to read, and only
>> incidentally for
>> machines to execute.”
>>
In article ,
Emile van Sebille wrote:
> code that doesn't execute will need to be read to be understood, and
> to be fixed so that it does run.
That is certainly true, but it's not the whole story. Even code that
works perfectly today will need to be modified in the future. Business
requir
On Aug 27, 5:21 pm, Emile van Sebille wrote:
> On 8/27/2011 2:57 PM Ben Finney said...
>
> > Emile van Sebille writes:
>
> >> Code is first and foremost written to be executed.
>
> > “Programs must be written for people to read, and only incidentally for
> > machines to execute.”
> >
On 8/27/2011 2:57 PM Ben Finney said...
Emile van Sebille writes:
Code is first and foremost written to be executed.
“Programs must be written for people to read, and only incidentally for
machines to execute.”
—Abelson& Sussman, _Structure and Interpretation of Computer
Emile van Sebille writes:
> Code is first and foremost written to be executed.
−1 QotW. I disagree, and have a counter-aphorism:
“Programs must be written for people to read, and only incidentally for
machines to execute.”
—Abelson & Sussman, _Structure and Interpretation of Compute
In article <4e595334$0$3$c3e8da3$54964...@news.astraweb.com>,
Steven D'Aprano wrote:
> and then there are languages with few, or no, design principles to speak of
Oh, like PHP?
--
http://mail.python.org/mailman/listinfo/python-list
On Sun, Aug 28, 2011 at 6:27 AM, Steven D'Aprano
wrote:
> You've never noticed the masses of code written in text books, blogs, web
> pages, discussion forums like this one, etc.?
>
> Real world code for production is usually messy and complicated and filled
> with data validation and error checki
Chris Angelico wrote:
> On Sun, Aug 28, 2011 at 3:27 AM, Emile van Sebille wrote:
>> Code is first and foremost written to be executed.
>>
>
> +1 QOTW. Yes, it'll be read, and most likely read several times, by
> humans, but ultimately its purpose is to be executed.
You've never noticed the mas
On Sun, Aug 28, 2011 at 3:27 AM, Emile van Sebille wrote:
> Code is first and foremost written to be executed.
>
+1 QOTW. Yes, it'll be read, and most likely read several times, by
humans, but ultimately its purpose is to be executed.
And in the case of some code, the programmer needs the same t
On 8/27/2011 9:41 AM Roy Smith said...
Chris Angelico wrote:
the important
considerations are not "will it take two extra nanoseconds to execute"
but "can my successor understand what the code's doing" and "will he,
if he edits my code, have a reasonable expectation that he's not
breaking stuf
On Sun, Aug 28, 2011 at 2:41 AM, Roy Smith wrote:
> Forget about your successor. Will *you* be able to figure out what you
> did 6 months from now? I can't tell you how many times I've looked at
> some piece of code, muttered, "Who wrote this crap?" and called up the
> checkin history only to di
Chris Angelico wrote:
> the important
> considerations are not "will it take two extra nanoseconds to execute"
> but "can my successor understand what the code's doing" and "will he,
> if he edits my code, have a reasonable expectation that he's not
> breaking stuff". These are always important.
On Sat, Aug 27, 2011 at 11:26 AM, Steven D'Aprano
wrote:
> I say "might be" because I mean it: these arguments have to be weighed up
> against the argument against breaking code out of functions. It's easy to
> imagine an extreme case where there are a billion *tiny* functions, each of
> which doe
Chris Angelico wrote:
> On Sat, Aug 27, 2011 at 4:16 AM, Steven D'Aprano
> wrote:
>> I can think of at least five reasons apart from re-use why it might be
>> appropriate to pull out code into its own function or method even if it
>> is used in one place only:
>
> I'm glad you say "might be", be
On Aug 26, 1:16 pm, Steven D'Aprano wrote:
> (3) Fault isolation. If you have a 100 line function that fails on line 73,
> that failure may have been introduced way back in line 16. By splitting the
> function up into smaller functions, you can more easily isolate where the
> failure comes from,
On Aug 26, 4:45 pm, Chris Angelico wrote:
> On Sat, Aug 27, 2011 at 4:05 AM, rantingrick wrote:
> > Now take a look at MY simple ONE module solution. It has JUST enough
> > methods and NOT a single more!
>
> I disagree - create_widgets() is completely unnecessary in the
> presence of show(),
Wel
On Sat, Aug 27, 2011 at 4:05 AM, rantingrick wrote:
> Now take a look at MY simple ONE module solution. It has JUST enough
> methods and NOT a single more!
I disagree - create_widgets() is completely unnecessary in the
presence of show(), unless it's possible to show the dialog, hide it,
and then
On Aug 26, 10:40 am, John Gordon wrote:
> In <7b47ca17-d3f1-4d91-91d1-98421e870...@ea4g2000vbb.googlegroups.com>
> rantingrick writes:
>
> > Furthermore: If you are moving code out of one function to ONLY be
> > called by that ONE function then you are a bad programmer and should
> > have your e
Tobiah wrote:
>
>> Furthermore: If you are moving code out of one function to ONLY be
>> called by that ONE function then you are a bad programmer and should
>> have your editor taken away for six months. You should ONLY create
>> more func/methods if those func/methods will be called from two or
On Sat, Aug 27, 2011 at 1:48 AM, Tobiah wrote:
> While I understand and agree with that basic tenet, I think
> that the capitalized 'ONLY' is too strong. I do split out
> code into function for readability, even when the function
> will only be called from the place from which I split it out.
>
Furthermore: If you are moving code out of one function to ONLY be
called by that ONE function then you are a bad programmer and should
have your editor taken away for six months. You should ONLY create
more func/methods if those func/methods will be called from two or
more places in the code. T
In <7b47ca17-d3f1-4d91-91d1-98421e870...@ea4g2000vbb.googlegroups.com>
rantingrick writes:
> Furthermore: If you are moving code out of one function to ONLY be
> called by that ONE function then you are a bad programmer and should
> have your editor taken away for six months. You should ONLY cre
On Aug 26, 6:15 am, Roy Smith wrote:
> Maybe. In general, it's certainly true that a bunch of smallish
> functions, each of which performs exactly one job, is easier to work
> with than a huge ball of spaghetti code.
Obviously you need to google the definition of "spaghetti code". When
you mo
In article
,
t...@thsu.org wrote:
> On Aug 23, 7:59 am, smith jack wrote:
> > i have heard that function invocation in python is expensive, but make
> > lots of functions are a good design habit in many other languages, so
> > is there any principle when writing pyt
On Aug 23, 7:59 am, smith jack wrote:
> i have heard that function invocation in python is expensive, but make
> lots of functions are a good design habit in many other languages, so
> is there any principle when writing python function?
> for example, how many lines should form a f
> "We must constantly strive to remove multiplicity from our systems;
> lest it consumes us!"
>
> s/multiplicity/rantingrick/ and I'm in full agreement.
QFT
--
http://mail.python.org/mailman/listinfo/python-list
rantingrick wrote:
> https://sites.google.com/site/thefutureofpython/
"Very soon I will be hashing out a specification for python 4000."
AHAHAHAHAhahahahahahahAHAHAHAHahahahahaaa. So rich. Anyone willing
to bet serious money we won't see this before 4000AD?
"Heck even our leader seems as a
rantingrick wrote:
> Everyone here who is suggesting that function bodies should be
> confined to ANY length is an idiot.
Or, more likely, is the sort of coder who has worked with other coders
in the past and understands the value of readable code.
> Don't worry if it too small or too big. It's
Terry Reedy wrote:
> On 8/23/2011 11:22 AM, Steven D'Aprano wrote:
>
>> Even 7±2 is probably excessive: I find that I'm most comfortable with
>> functions that perform 4±1 chunks of work. An example from one of my
>> classes:
>>
>> def find(self, prefix):
>> """Find the item that ma
On Aug 23, 1:29 pm, Terry Reedy wrote:
> In terms of different functions performed (see my previous post), I see
> attribute lookup
> assignment
> enumerate
> sequence unpacking
> for-looping
> if-conditioning
> lower
> startswith
> return
> That is 9, which is enough.
On 8/23/2011 11:22 AM, Steven D'Aprano wrote:
Even 7±2 is probably excessive: I find that I'm most comfortable with
functions that perform 4±1 chunks of work. An example from one of my
classes:
def find(self, prefix):
"""Find the item that matches prefix."""
prefix = pref
Python, with the exceptions noted above of avoiding trivial
one-use functions when there is an alternative.
is there any principle when writing python function?
Same as usual. Functions define new words and create new abstractions
than encapsulate a unit of computation.
for example, how
On Aug 23, 6:59 am, smith jack wrote:
> i have heard that function invocation in python is expensive, but make
> lots of functions are a good design habit in many other languages, so
> is there any principle when writing python function?
> for example, how many lines should for
On 2011-08-23, smith jack wrote:
> i have heard that function invocation in python is expensive, but make
> lots of functions are a good design habit in many other languages, so
> is there any principle when writing python function?
Lots of them. None of them have to do with performanc
usec per loop
the function call overhead becomes trivial.
Cases where function call overhead is significant are rare. Not vanishingly
rare, but rare enough that you shouldn't worry about them.
> but make
> lots of functions are a good design habit in many other languages, so
>
I accidentally sent below mail only to roy. Resending to groups.
-- Yönlendirilmiş ileti --
Kimden: Yaşar Arabacı
Tarih: 23 Ağustos 2011 16:19
Konu: Re: is there any principle when writing python function
Kime: Roy Smith
I don't see myself a good python programmer or any
smith jack wrote:
> i have heard that function invocation in python is expensive, but make
> lots of functions are a good design habit in many other languages, so
> is there any principle when writing python function?
> for example, how many lines should form a function?
Don'
In article , Peter Otten <__pete...@web.de>
wrote:
> smith jack wrote:
>
> > i have heard that function invocation in python is expensive, but make
> > lots of functions are a good design habit in many other languages, so
> > is there any principle when writing py
In article ,
smith jack wrote:
> i have heard that function invocation in python is expensive, but make
> lots of functions are a good design habit in many other languages, so
> is there any principle when writing python function?
> for example, how many lines should form a funct
smith jack wrote:
> i have heard that function invocation in python is expensive, but make
> lots of functions are a good design habit in many other languages, so
> is there any principle when writing python function?
It's hard to discuss in the abstract. A function sh
smith jack wrote:
> i have heard that function invocation in python is expensive, but make
> lots of functions are a good design habit in many other languages, so
> is there any principle when writing python function?
> for example, how many lines should form a function?
Five
i have heard that function invocation in python is expensive, but make
lots of functions are a good design habit in many other languages, so
is there any principle when writing python function?
for example, how many lines should form a function?
--
http://mail.python.org/mailman/listinfo/python
48 matches
Mail list logo
