473,327 Members | 2,094 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,327 software developers and data experts.

Coding style

PTY
Which is better?

lst = [1,2,3,4,5]

while lst:
lst.pop()

OR

while len(lst) 0:
lst.pop()

Jul 17 '06
86 2644
Bruno Desthuilliers wrote:
"Irrelevant" may not be the best expression of my thought here - it's
just that Carl's assertion is kind of a tautology and doesn't add
anything to the discussion. If Python had been designed as statically
typed (with declarative typing), the rules would be different. Yeah,
great. And now ?
I was answering someone who said you should use "if lst" because PEP 8
says to. I proposed that the PEP might be outdated here, and gave
reasons why I think it would be different if it were written today. (I
also, regrettably, implied the language might have been designed
differently.) This all might be irrelevant to you, but it's relevant
to the original question of whether that clause of PEP 8 is outdated.
I think it is.

BTW, I'm still waiting for anyone to come up with a real benefit of the
"if lst" test. I have yet to see a good reason than non-answer
cop-outs "it's Pythonic", "it's stood the test of time", and "it's in
PEP 8". "It's standard idiom" is about the best I've seen, and that's
pretty weak. "Saving a few keystrokes" is, as always, not a good
reason.
Carl Banks

Jul 18 '06 #51
Bruno Desthuilliers wrote:
There are less risk of a typo with "if a:" than with "if len(a) 0".
So, it's more important to protect against typos than subtle bugs?
Carl Banks

Jul 18 '06 #52
Carl Banks a écrit :
Bruno Desthuilliers wrote:
>>There are less risk of a typo with "if a:" than with "if len(a) 0".


So, it's more important to protect against typos than subtle bugs?
People making smart points are really annoying... !-)

wrt/ to the "subtle bug" point, MHO is that a better solution could be
to have iterators/generators implement __nonzero__ the same way numpy
arrays do. It may not be a very strong argument, but I actually like the
fact that empty sequences eval to false just like numeric zeros and None...
Jul 19 '06 #53

Bruno Desthuilliers wrote:
Carl Banks a écrit :
Bruno Desthuilliers wrote:
>There are less risk of a typo with "if a:" than with "if len(a) 0".

So, it's more important to protect against typos than subtle bugs?

People making smart points are really annoying... !-)

wrt/ to the "subtle bug" point, MHO is that a better solution could be
to have iterators/generators implement __nonzero__ the same way numpy
arrays do. It may not be a very strong argument, but I actually like the
fact that empty sequences eval to false just like numeric zeros and None....
Well, I certainly can agree with that, except for the last point. :) I
certainly wouldn't want to keep that unfortunate behavior around just I
have something to use as an argument using len to test emptiness.
Carl Banks

Jul 19 '06 #54
"Carl Banks" <pa************@gmail.comwrites:
Well, I certainly can agree with that, except for the last point. :) I
certainly wouldn't want to keep that unfortunate behavior around just I
have something to use as an argument using len to test emptiness.
On the other hand, having this behavior makes it so simple to deal with some
algorithms because on doesn't need to know if the given object does or does
not support len()...

Having to test if something is of certain type then choosing what kind of test
to apply is not something I'd like to have to do all the time.

--
Jorge Godoy <jg****@gmail.com>
Jul 19 '06 #55

"Patrick Maupin" <pm*****@gmail.comwrote in message
news:11*********************@h48g2000cwc.googlegro ups.com...
>
Carl Banks wrote:
> def process_values(lst):
if not lst:
return
do_expensive_initialization_step()
for item in lst:
do_something_with(item)
do_expensive_finalization_step()
What if you called the function like this:

process_values(x.strip() for x in values_lst)
The perverse wish, expressed in the specific example, that SOME piece
of code SOMEWHERE should PLEASE throw an exception because some idiot
passed a generator expression rather than a list into a function, is
not apt to be well received by an audience which strives for generality
when it makes sense; and I daresay most members of that audience, if
confronted with the wished-for exception, would fix the function so
that it quite happily accepted generator expressions, rather than
changing a conditional to use len() just so that an equivalent
exception could happen a bit earlier.
Given that the input is going to be scanned by an iterator, it really makes
sense to me to accept an iterator as input. (Unless the function is for
special-case usage in a predefined, never to be expanded, set of
circumstances in which such generality is not needed. In such a case, if
lst: is no problem.) I think the following, untested rewrite suffices.

def process_values(lst):
it = iter(lst)
try:
item = it.next()
do_expensive_initialization_step()
do_something_with(item) # see note
for item in it:
do_something_with(item)
do_expensive_finalization_step()
except StopIteration:
pass # or any special empty input code

# note: if writing do_something_with(item) is bothersome,
# replace 3 lines with
while True:
do_something_with(item)
try:
item = it.next
except StopIteration:
break

In general, to work with iterators instead of containers, change

if container:
do_stuff()
else:
do_empty()

to

try:
item = it.next()
do_modified_stuff() # taking into account that have item already
except StopIteration:
do_empty()

Guido has so far vetoed adding .__len__() to the iterator protocol because
a) it is not always possible and b) he want to keep the protocol as simple
as it is.

Terry Jan Reedy


Jul 19 '06 #56

Jorge Godoy wrote:
"Carl Banks" <pa************@gmail.comwrites:
Well, I certainly can agree with that, except for the last point. :) I
certainly wouldn't want to keep that unfortunate behavior around just I
have something to use as an argument using len to test emptiness.

On the other hand, having this behavior makes it so simple to deal with some
algorithms because on doesn't need to know if the given object does or does
not support len()...
First of all, the unfortunate behavior I was referring to was the fact
that iterables that have unknown length are true in a boolean context,
even if they happen to be empty. Bruno and I had a disagreement over
whether this should also be a wart for lists and such, but I think we
agree that it would be better generators and other iterators raised an
exception in a boolean context.

Getting back to your reply--can you give an example of a useful
function that needs to do what you want? (Let's disregard iterators
and arrays for now, and focus on older Python types like lists, tuples,
strings, integers, floats, None, etc.) Can you give me an example of a
useful function that needs to test the truth value of an object, but
that can't rely on it having a length?

The only example I can think of here is a function that does nothing
with an object except pass it to other functions. Almost anything else
you do with an object pigeonholes it as a sequence or atomic type:
you've already assumed whether it has a length or not.
Carl Banks

Jul 19 '06 #57
Terry Reedy wrote:
Guido has so far vetoed adding .__len__() to the iterator protocol because
a) it is not always possible and
Be warned that this is a veto after the fact:

# (only) python 2.4
>>len(iter(range(42)))
42

# python 2.5
>>len(iter(range(42)))
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: len() of unsized object
b) he want to keep the protocol as simple
as it is.
You will be able to write considerably more complex generators in 2.5:

http://docs.python.org/dev/whatsnew/pep-342.html

Peter
Jul 19 '06 #58
In message <44***********************@news.free.fr>, Bruno Desthuilliers
wrote:
Lawrence D'Oliveiro wrote:
>In message <Q8******************************@nmt.edu>, Bob Greschke
wrote:

>>>I'd go even one step further. Turn it into English (or your favorite
non-computer language):

1. While list, pop.

2. While the length of the list is greater than 0, pop.

Which one makes more sense? Guess which one I like. CPU cycles be
damned.
:)


One of my rules is, always program like the language actually has a
Boolean type, even if it doesn't.

Python has a boolean type.
A _proper_ boolean type would _have_ to be used in conditionals.
>That means, never assume that arbitrary values
can be interpreted as true or false,

There's nothing to assume, and nothing arbitrary in it. It's all clearly
defined in whole letters in the language references.
Not simply enough.
>always put in an explicit comparison
if necessary so it's obvious the expression is a Boolean.

The fact that the expression is used in the context of a if statement is
clearly enough to denote a boolean expression.
Which is an inconsistent use of the term "boolean" compared to your
statement above that "Python has a boolean type", is it not?
Explicitly testing against a boolean is uselessly redundant...
Not sure this has anything with what I was saying.

Jul 19 '06 #59
Lawrence D'Oliveiro wrote:
In message <Q8******************************@nmt.edu>, Bob Greschke wrote:
>I'd go even one step further. Turn it into English (or your favorite
non-computer language):

1. While list, pop.

2. While the length of the list is greater than 0, pop.

Which one makes more sense? Guess which one I like. CPU cycles be
damned.
:)

One of my rules is, always program like the language actually has a Boolean
type, even if it doesn't. That means, never assume that arbitrary values
can be interpreted as true or false, always put in an explicit comparison
if necessary so it's obvious the expression is a Boolean.
You can do that, but it's not considered Pythonic. And it might be ineffective.

Other than in PHP, Python has clear rules when an object of a builtin type
is considered false (i.e. when it's empty). So why not take advantage of
this?

Georg
Jul 19 '06 #60
PTY wrote:
Which is better?

lst = [1,2,3,4,5]

while lst:
lst.pop()

OR

while len(lst) 0:
lst.pop()
allways that either-or stuff ! And why did you not consider

while len(lst) : list.pop()

a neat middle ground, wouldn't you say ?

Cheers, BB
--
666 ?? - 666 ~ .666 ~ 2/3 ~ 1-1/3 ~ tertium non datur ~ the excluded middle
~ "either with us, or against us" !!
Jul 19 '06 #61
Bruno Desthuilliers wrote:
>
empty_list = []
bool(empty_list) is False
=True
it's just a pity that the symmetric expression

list(False) is []

doesn't hold.

I guess the problem is that if list(False) was thus defined, it would be
difficult not to define list(True). And then the zen of Python clashes

"In the presence of ambiguity, refuse the temptation to guess".

OTOH, my favorite there would be

list(True) is [None]

together with

list(n) == n*[None] for all positive integers n

Cheers, BB
--
666 ?? - 666 ~ .666 ~ 2/3 ~ 1-1/3 ~ tertium non datur ~ the excluded middle
~ "either with us, or against us" !!
Jul 19 '06 #62
Patrick Maupin a écrit :
The perverse wish, expressed in the specific example, that SOME piece
of code SOMEWHERE should PLEASE throw an exception because some idiot
passed a generator expression rather than a list into a function, is
not apt to be well received by an audience which strives for generality
when it makes sense
Well then, you haven't beed using enouth generator expressions or else,
that kind of mistake would have bitten you badly by now and you would
agree with that remark !
confronted with the wished-for exception, would fix the function so
that it quite happily accepted generator expressions, rather than
changing a conditional to use len() just so that an equivalent
exception could happen a bit earlier.
Thanks but NO. If that function needs to iterate twice on the
expression, then it needs to iterate twice and passing it a generator
will only cause strange bugs.
Jul 19 '06 #63
In <44********@news.bluewin.ch>, Boris Borcic wrote:
Bruno Desthuilliers wrote:
>>
empty_list = []
bool(empty_list) is False
=True

it's just a pity that the symmetric expression

list(False) is []

doesn't hold.
You want the empty list to be a singleton!? And I don't find
`list(False)` to return an empty list be very obvious.
I guess the problem is that if list(False) was thus defined, it would be
difficult not to define list(True). And then the zen of Python clashes

"In the presence of ambiguity, refuse the temptation to guess".

OTOH, my favorite there would be

list(True) is [None]
Wow it even gets better, the list containing one `None` object should be a
singleton too. Argh.

Ciao,
Marc 'BlackJack' Rintsch
Jul 19 '06 #64
Ant

Christophe wrote:
... you haven't beed using enouth generator expressions ...
You should get yourself to the doctors about that cold dude. :-)

Jul 19 '06 #65
Marc 'BlackJack' Rintsch wrote:
In <44********@news.bluewin.ch>, Boris Borcic wrote:
>Bruno Desthuilliers wrote:
>>empty_list = []
bool(empty_list) is False
=True
it's just a pity that the symmetric expression

list(False) is []

doesn't hold.

You want the empty list to be a singleton!?
Oops,

list(False) == [], then.

BTW, be careful with 'singleton' when applying to aggregates - it took me a
while to figure out you did not mean an obj X s.t. len(X)==1.

And I don't find
`list(False)` to return an empty list be very obvious.
What would be your choice ?
Jul 19 '06 #66
On 2006-07-19, Georg Brandl <g.*************@gmx.netwrote:
Lawrence D'Oliveiro wrote:
>In message <Q8******************************@nmt.edu>, Bob Greschke wrote:
>>I'd go even one step further. Turn it into English (or your favorite
non-computer language):

1. While list, pop.

2. While the length of the list is greater than 0, pop.

Which one makes more sense? Guess which one I like. CPU cycles be
damned.
:)

One of my rules is, always program like the language actually has a Boolean
type, even if it doesn't. That means, never assume that arbitrary values
can be interpreted as true or false, always put in an explicit comparison
if necessary so it's obvious the expression is a Boolean.

You can do that, but it's not considered Pythonic. And it might be ineffective.

Other than in PHP, Python has clear rules when an object of a builtin type
is considered false (i.e. when it's empty). So why not take advantage of
this?
Because it doesn't always do what I want.

I once had a producer consumer code. When the client asked whether new
items were available the function could return three different values

1) a list with items, to be consumed
2) an empty list (meaning there were no items available for the
moment but there could be in the future
3) None (meaning the producer was done)

Just testing for the truth value of the returned result in order
to see whether the client should continue or not would often
have made the client exit prematurely.

IME such cases where testing for the truth value of an object
don't give the expected result, happen often enough to make me
carefully think about what I want to test for and then explicitly
do so.

--
Antoon Pardon

Jul 19 '06 #67
In <44********@news.bluewin.ch>, Boris Borcic wrote:
>And I don't find `list(False)` to return an empty list be very obvious.

What would be your choice ?
``list()`` or ``[]`` for empty lists and a `TypeError` for
``list(False)``. Just like it is right now.

Ciao,
Marc 'BlackJack' Rintsch
Jul 19 '06 #68

Christophe wrote:
The perverse wish, expressed in the specific example, that SOME piece
of code SOMEWHERE should PLEASE throw an exception because some idiot
passed a generator expression rather than a list into a function, is
not apt to be well received by an audience which strives for generality
when it makes sense

Well then, you haven't beed using enouth generator expressions or else,
that kind of mistake would have bitten you badly by now and you would
agree with that remark !
I use generators frequently.
confronted with the wished-for exception, would fix the function so
that it quite happily accepted generator expressions, rather than
changing a conditional to use len() just so that an equivalent
exception could happen a bit earlier.

Thanks but NO. If that function needs to iterate twice on the
expression, then it needs to iterate twice and passing it a generator
will only cause strange bugs.
The original post did not say "this function is iterating twice over
the same data." It only said that there might be a significant
computational cost on an empty iterator, and wished that the code would
somehow throw an exception to alert the programmer to this cost. I
maintain that if the cost is low enough that the programmer doesn't
notice it without the exception, there is no problem, and if the cost
is high enough that the programmer notices it, the profiler would find
the problem easily.

I'm not sure why you say "Thanks but NO" to the option of fixing the
function so that it accepts generators, but in any case if you know
up-front that a function needs to iterate twice over the same data and
you are too lazy to write some code to do that for generators (such as
by creating a list object or using the tee function), then by all means
feel free to check that the data coming into the function is not a
generator. But this is still not a good reason why, in the general
case, "if len(lst)" should be preferred over "if lst". In fact, I'm
not sure it's a good reason to use this construct even in this specific
case. It would be too easy for someone to "fix" this during
refactoring. If you really want to make sure that a function can only
take objects which have __len__ methods, why not come right out and say
so:

assert hasattr(lst, "__len__")

Regards,
Pat

Jul 19 '06 #69
Antoon Pardon wrote:
>Other than in PHP, Python has clear rules when an object of a builtin type
is considered false (i.e. when it's empty). So why not take advantage of
this?

Because it doesn't always do what I want.

I once had a producer consumer code. When the client asked whether new
items were available the function could return three different values

1) a list with items, to be consumed
2) an empty list (meaning there were no items available for the
moment but there could be in the future
3) None (meaning the producer was done)

Just testing for the truth value of the returned result in order
to see whether the client should continue or not would often
have made the client exit prematurely.

IME such cases where testing for the truth value of an object
don't give the expected result, happen often enough to make me
carefully think about what I want to test for and then explicitly
do so.
You're right, carefully thinking is always a good thing. Not using a
language feature just because it would fail in another case is not.

Georg
Jul 19 '06 #70

Patrick Maupin wrote:
The original post did not say "this function is iterating twice over
the same data." It only said that there might be a significant
computational cost on an empty iterator, and wished that the code would
somehow throw an exception to alert the programmer to this cost.
You're misrepresenting what I said. Cost was merely the
best-case-scenario. Bugs could arise if, say, the finalization
silently depends on non-empty iterable.

But this is still not a good reason why, in the general
case, "if len(lst)" should be preferred over "if lst".
Whatever. The OP asked for a reason one should be preferred over the
other; this was simply one reason to use "if len(lst)>0". Not good
enough for you? Fine, you still have all the reasons to continue to
use "if lst" (as opposed to just bashing "if len(lst)>0") that you and
others have shared with us in this thread.

(Wait a second....)
Carl Banks

Jul 19 '06 #71
In article <e9**********@news.albasani.net>,
Georg Brandl <g.*************@gmx.netwrote:
Lawrence D'Oliveiro wrote:
One of my rules is, always program like the language actually has a Boolean
type, even if it doesn't. That means, never assume that arbitrary values
can be interpreted as true or false, always put in an explicit comparison
if necessary so it's obvious the expression is a Boolean.

You can do that, but it's not considered Pythonic. And it might be
ineffective.

Other than in PHP, Python has clear rules when an object of a builtin type
is considered false (i.e. when it's empty). So why not take advantage of
this?
I don't know whether she would welcome this or not, but here
I provide an archive link to a classic post by Laura Creighton
on this matter:

http://groups.google.com/group/comp....e5e1c8384c0360

It's lengthy but very readable, and for me it has that quality of
exposition where you feel at first reading as though you had
already known all that -- even if you really hadn't.

But I don't know where she is today, or the Python she was
writing about.

Donn Cave, do**@u.washington.edu
Jul 19 '06 #72
Terry Reedy wrote:
>
Carl Banks wrote:
def process_values(lst):
if not lst:
return
do_expensive_initialization_step()
for item in lst:
do_something_with(item)
do_expensive_finalization_step()

Given that the input is going to be scanned by an iterator, it really makes
sense to me to accept an iterator as input. (Unless the function is for
special-case usage in a predefined, never to be expanded, set of
circumstances in which such generality is not needed. In such a case, if
lst: is no problem.) I think the following, untested rewrite suffices.

def process_values(lst):
it = iter(lst)
try:
item = it.next()
do_expensive_initialization_step()
do_something_with(item) # see note
for item in it:
do_something_with(item)
do_expensive_finalization_step()
except StopIteration:
pass # or any special empty input code

# note: if writing do_something_with(item) is bothersome,
# replace 3 lines with
while True:
do_something_with(item)
try:
item = it.next
except StopIteration:
break

In general, to work with iterators instead of containers, change

if container:
do_stuff()
else:
do_empty()

to

try:
item = it.next()
do_modified_stuff() # taking into account that have item already
except StopIteration:
do_empty()
Good example. But if you want, you can also do the same thing
without explicitly dealing with StopIteration exceptions, by (ab)using
the for statment to deal with the StopIteration exceptions implicitly
for you:

def process_values(lst):
it = iter(lst)
# This for statement executes 0 or 1 times
for item in it:
do_expensive_initialization_step()
do_something_with(item)
break
else:
# Empty list code, if needed, goes here...
return
# This for statement executes max(0, len(lst) - 1) times
for item in it:
do_something_with(item)
do_expensive_finalization_step()

And, of course, if you really want to defer optimizations, and you
expect the code to not be in a critical speed path and to not be passed
huge lists or iterators, you could take the original function and add:

lst = list(lst)

as the first line. Frankly, if I had a working function in a piece of
code, and then a failure because it was being called with a generator,
I would find this very tempting unless I strongly suspected it would
cause issues later.

Regards,
Pat

Jul 20 '06 #73
In message <e9**********@news.albasani.net>, Georg Brandl wrote:
Lawrence D'Oliveiro wrote:
>In message <Q8******************************@nmt.edu>, Bob Greschke
wrote:
>>I'd go even one step further. Turn it into English (or your favorite
non-computer language):

1. While list, pop.

2. While the length of the list is greater than 0, pop.

Which one makes more sense? Guess which one I like. CPU cycles be
damned.
:)

One of my rules is, always program like the language actually has a
Boolean type, even if it doesn't. That means, never assume that arbitrary
values can be interpreted as true or false, always put in an explicit
comparison if necessary so it's obvious the expression is a Boolean.

You can do that, but it's not considered Pythonic. And it might be
ineffective.

Other than in PHP, Python has clear rules when an object of a builtin type
is considered false (i.e. when it's empty). So why not take advantage of
this?
Because the clearest rule of all is that True is true, and False is false,
and that's all I want to have to remember.
Jul 20 '06 #74
On 2006-07-19, Georg Brandl <g.*************@gmx.netwrote:
Antoon Pardon wrote:
>>Other than in PHP, Python has clear rules when an object of a builtin type
is considered false (i.e. when it's empty). So why not take advantage of
this?

Because it doesn't always do what I want.

I once had a producer consumer code. When the client asked whether new
items were available the function could return three different values

1) a list with items, to be consumed
2) an empty list (meaning there were no items available for the
moment but there could be in the future
3) None (meaning the producer was done)

Just testing for the truth value of the returned result in order
to see whether the client should continue or not would often
have made the client exit prematurely.

IME such cases where testing for the truth value of an object
don't give the expected result, happen often enough to make me
carefully think about what I want to test for and then explicitly
do so.

You're right, carefully thinking is always a good thing. Not using a
language feature just because it would fail in another case is not.
I would say the opposite is just as true. Using a language feature
just because it happens to give the right answer, is not a good thing.
You don't know how your code will evolve and my experience is that the
lesser you use this feature, the lesser the chance you will have
to track a nasty bug later.

--
Antoon Pardon
Jul 20 '06 #75
On 2006-07-19, Donn Cave <do**@u.washington.eduwrote:
In article <e9**********@news.albasani.net>,
Georg Brandl <g.*************@gmx.netwrote:
>Lawrence D'Oliveiro wrote:
One of my rules is, always program like the language actually has a Boolean
type, even if it doesn't. That means, never assume that arbitrary values
can be interpreted as true or false, always put in an explicit comparison
if necessary so it's obvious the expression is a Boolean.

You can do that, but it's not considered Pythonic. And it might be
ineffective.

Other than in PHP, Python has clear rules when an object of a builtin type
is considered false (i.e. when it's empty). So why not take advantage of
this?

I don't know whether she would welcome this or not, but here
I provide an archive link to a classic post by Laura Creighton
on this matter:

http://groups.google.com/group/comp....e5e1c8384c0360

It's lengthy but very readable, and for me it has that quality of
exposition where you feel at first reading as though you had
already known all that -- even if you really hadn't.
Well for me it wasn't, I don't agree with it at all.

IMO, whether something is to be considered "True" or "False"
is application dependent. There are cases where I would
consider an empty sequence as True, because a sequence in
itself would mean, continue and the members would be
the current available elements to be processed.

Nothing is IMO not specific enough and doesn't make
the disctinction between nothing (temporarily) now
and nothing more (for ever).

That is why I think the distinction between True and
False is more usefull than the distinction between
nothing and something.

--
Antoon Pardon
Jul 20 '06 #76
On 2006-07-19, Dennis Lee Bieber <wl*****@ix.netcom.comwrote:
On 19 Jul 2006 12:27:39 GMT, Antoon Pardon <ap*****@forel.vub.ac.be>
declaimed the following in comp.lang.python:

>>
I once had a producer consumer code. When the client asked whether new
items were available the function could return three different values

1) a list with items, to be consumed
2) an empty list (meaning there were no items available for the
moment but there could be in the future
3) None (meaning the producer was done)
You have a documented interface with a tri-state return... For this
situation, you would need the explicit test... I'd probably end up with
something like

while True:
retrn = function()
if retrn is None:
break
elif retrn:
consume
The problem is how people here react:

Suppose I have the following kind of code:

while True:
try:
if len(result) 0:
foo()
else
bar()
except TypeError:
break

This code makes the distinction between the three possibilities,
whether it is a good way or not I won't discuss, this is just
meant as an illustration.

Now I have a problem with the code between the if and else, so
I come to the newsgroup and post something like:

I have a problem with the following kind of code, it seems
to do blob, but I would have expected blib.

if len(result) 0:
foo()
else:
...
And before you know it someone will respond that I shouldn't
use

if len(result) 0:

but should just use:

if result:
Which isn't at all helpfull with my original problem, but would
be wrong in the context where the code is actually used.

--
Antoon Pardon
Jul 20 '06 #77
Lawrence D'Oliveiro wrote:
In message <44***********************@news.free.fr>, Bruno Desthuilliers
wrote:

>>Lawrence D'Oliveiro wrote:
>>>In message <Q8******************************@nmt.edu>, Bob Greschke
wrote:

I'd go even one step further. Turn it into English (or your favorite
non-computer language):

1. While list, pop.

2. While the length of the list is greater than 0, pop.

Which one makes more sense? Guess which one I like. CPU cycles be
damned.
:)
One of my rules is, always program like the language actually has a
Boolean type, even if it doesn't.

Python has a boolean type.


A _proper_ boolean type would _have_ to be used in conditionals.
Try using something that cannot be fed to bool() into a conditional.
>
>>>That means, never assume that arbitrary values
can be interpreted as true or false,

There's nothing to assume, and nothing arbitrary in it.
It's all clearly
defined in whole letters in the language references.


Not simply enough.
Then it's a documentation problem.
>
>>>always put in an explicit comparison
if necessary so it's obvious the expression is a Boolean.

The fact that the expression is used in the context of a if statement is
clearly enough to denote a boolean expression.


Which is an inconsistent use of the term "boolean" compared to your
statement above that "Python has a boolean type", is it not?
No. It is not. A boolean expression is an expression you can pass to
bool().
>
>>Explicitly testing against a boolean is uselessly redundant...


Not sure this has anything with what I was saying.
You said:
"""
>>>always put in an explicit comparison
if necessary so it's obvious the expression is a Boolean.
"""

Since the expression following an if will be handled as if passed to
bool() [1], adding a comparison to True will yield a strictly equivalent
result (True == True =True, False == True =False). From a boolean
logic POV, it's a no-op [2]. So it's useless and redundant.
[1] FWIW, it may be just how it works - I've not checked implementation.
Anyway you can easily verify by yourself that it works the same way.

[2] but it still requires extra work from the interpreter - without
changing anything to the result of the test.

FWIW, what would you rather use:

if <some_exp== True:
return True
elif <some_exp== False:
return False
else:
raise "???"

or:

return bool(<some_exp>)
--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'o****@xiludom.gro'.split('@')])"
Jul 20 '06 #78
In article <sl********************@rcpc42.vub.ac.be>,
Antoon Pardon <ap*****@forel.vub.ac.bewrote:
On 2006-07-19, Donn Cave <do**@u.washington.eduwrote:
....
http://groups.google.com/group/comp....e5e1c8384c0360

It's lengthy but very readable, and for me it has that quality of
exposition where you feel at first reading as though you had
already known all that -- even if you really hadn't.

Well for me it wasn't, I don't agree with it at all.
People sometimes ask, "what does `the exception that proves the rule'
mean?"

Donn Cave, do**@u.washington.edu
Jul 20 '06 #79
On 2006-07-20, Dennis Lee Bieber <wl*****@ix.netcom.comwrote:
On 20 Jul 2006 08:50:44 GMT, Antoon Pardon <ap*****@forel.vub.ac.be>
declaimed the following in comp.lang.python:
>>
Suppose I have the following kind of code:

while True:
try:
if len(result) 0:
foo()
else
bar()
except TypeError:
break

This code makes the distinction between the three possibilities,
whether it is a good way or not I won't discuss, this is just
meant as an illustration.
<shudder> I look at that and my first thought is:

there is no way to tell if foo() or bar() raised TypeError.

In the absence of documentation about a tri-state "result" being
normal, my second thought IS that the len(result) 0 is redundandant;
bar() should be responsible for properly handling the difference between
None and empty conditions.

A third thought -- foo() and bar() must be implementing hidden
side-effects since the only way out of the loop is by changing result,
and result is not an argument in or out of either foo or bar.

>Which isn't at all helpfull with my original problem, but would
be wrong in the context where the code is actually used.

Well, in this case, you didn't supply the context (an expected
tri-state return, for example) so most of us would react as to a
two-state model: if result: process data; else: nothing to process

In your above example, I'd probably even skip the elif format

while True:
if result is None: break
if result:
foo()
else:
bar()

It explicitly shows that the value "None" is expected, and is the
signal for loop termination... and that there is different processing
for empty/0 results versus non-empty/non-0 results (and this scheme even
works with scalars, not just sequences)
Thank you for illustrating my point so well. What happened here? You saw
some code who made you shudder, and you reacted in a way to get released
from that shudder. Whether that reaction would be helpfull or relevant
to the problem of the original person seems to be unimportant.

What happens a lot is that someone has trouble with some code, a bug
or lack of understanding. So he reduces his code to a sample he can
use as an illustration of the problem and will easily fit in a news
article. That there can be issues with this code is normal, but
fixing the code so that these issues go a way, will probably just
obscure the point that he is trying to make.

So we have code with certain shudder characteristics. And instead
of trying to help the OP with his problem, some people react
to the shudder and come with all sort of comments that might be
true if the code as shown was production code, but which totally
miss the point the code was illustrating and thus aren't much
helpfull.

--
Antoon Pardon
Jul 21 '06 #80
On 2006-07-21 09:00:43, Antoon Pardon wrote:
So we have code with certain shudder characteristics. And instead
of trying to help the OP with his problem, some people react
to the shudder and come with all sort of comments that might be
true if the code as shown was production code, but which totally
miss the point the code was illustrating and thus aren't much
helpfull.
In general, I'd say that in this case the example was not well-chosen.
After such a "shudder removal", a poster should IMO review what caused the
shudder, and rephrase the original problem without the shudder. That might
take a few iterations, but in general, either one or more of the "shudder
removals" actually address the OP's issue, maybe without any individual
helper understanding all of the problem (due to incomplete example code),
or the iterations lead to a code that's "shudder free" and still shows the
original problem -- now usually in a clearer form, because free of other
issues that are not relevant to the OP's point.

E.g. if someone makes a suggestion that is valid with the example code I
posted but not with the real code I have, I need to post an updated example
code that introduces a restriction similar to the one I actually have,
which then correctly invalidates the formerly valid suggestion -- and helps
getting more helpful responses. This is a process that in the past has
taught me a lot (not Python, but that's just because I'm too new here :).
Once you get good at this process, it often helps you find the problem even
before posting, because boiling code down to what the /real/ problem is can
show you a lot you otherwise miss.

(In case that sounds too general -- it is <g>. But it answers a general
point...)

Gerhard

Jul 21 '06 #81
Lawrence D'Oliveiro a écrit :
In message <e9**********@news.albasani.net>, Georg Brandl wrote:

(snip)
>>Other than in PHP, Python has clear rules when an object of a builtin type
is considered false (i.e. when it's empty). So why not take advantage of
this?

Because the clearest rule of all is that True is true, and False is false,
and that's all I want to have to remember.
I somewhat agree with Laura Craighton (cf Donn's post above in this
thread). Things were clearer when there was no boolean type in Python,
and we just had the difference between 'nothing' (empty sequence, zero
numeric, None) and 'something' (almost anything else).
Jul 21 '06 #82
On 2006-07-21, Dennis Lee Bieber <wl*****@ix.netcom.comwrote:
On 21 Jul 2006 12:00:43 GMT, Antoon Pardon <ap*****@forel.vub.ac.be>
declaimed the following in comp.lang.python:
>So we have code with certain shudder characteristics. And instead
of trying to help the OP with his problem, some people react
to the shudder and come with all sort of comments that might be
true if the code as shown was production code, but which totally
miss the point the code was illustrating and thus aren't much
helpfull.

You miss one factor -- the specification of what the code sample is
supposed to handle. Showing a sample of code which may reproduce an
apparent problem, without stating /all/ the requirements of the
data/process, leaves the reviewer in the state of assuming all the
conditions are explicit in the code.
No that leaves the reviewer in the state of assuming all *relevant*
conditions are explicit in the code.
And in the case of your sample --
that just isn't true. The try/except block is too general, and seems to
imply that the exception might be raised in either (or both) foo() or
bar()
Which in this case is totally irrelevant. The try/except block
was not part of the code that would have been posetd to the
newsgroup.
-- it is not clear that the try/except is being used to detect an
unstated exit condition requirement.
Again irrelevant. This was an example where someone had trouble
with his code (the try/except statement) which he would then
reduce to a minimal piece of code that would still show the
trouble some behaviour (Just the then part of an if statement)
which he would then post to the list.

All trouble with the so called original code is totally irrelevant
to the point I was trying to make and the more you try to critisize
it the more you are an illustration of the point I am trying to make.

This remark was just under that example code in my originle
article:

This code makes the distinction between the three possibilities,
whether it is a good way or not I won't discuss, this is just
meant as an illustration.

What didn't you understand about the code just meant to be an
illustration.

--
Antoon Pardon
Jul 23 '06 #83
On 2006-07-21, Gerhard Fiedler <ge*****@gmail.comwrote:
On 2006-07-21 09:00:43, Antoon Pardon wrote:
>So we have code with certain shudder characteristics. And instead
of trying to help the OP with his problem, some people react
to the shudder and come with all sort of comments that might be
true if the code as shown was production code, but which totally
miss the point the code was illustrating and thus aren't much
helpfull.

In general, I'd say that in this case the example was not well-chosen.
After such a "shudder removal", a poster should IMO review what caused the
shudder, and rephrase the original problem without the shudder.
The shudder is not with the poster. The poster can't predict how
the readers will react.
That might
take a few iterations, but in general, either one or more of the "shudder
removals" actually address the OP's issue, maybe without any individual
helper understanding all of the problem (due to incomplete example code),
or the iterations lead to a code that's "shudder free" and still shows the
original problem -- now usually in a clearer form, because free of other
issues that are not relevant to the OP's point.
I doubt that. My experience is that you have more chance of being helped
by people who try to understand where the OP is trying to go form than
from those who react to style issues. I have never seem a bug go away
because someone suggested to write "if Number:" instead of "if Number != 0:"
E.g. if someone makes a suggestion that is valid with the example code I
posted but not with the real code I have, I need to post an updated example
code that introduces a restriction similar to the one I actually have,
which then correctly invalidates the formerly valid suggestion -- and helps
getting more helpful responses.
Not necessarily. A valid suggestion doesn't imply a relevant suggestion.

If someone come with code like:

if Number != 0:

And someone suggests that the python idiom is

if Number:

Then that suggestion is valid, but it also is irrelevant. A bug doesn't
disappear because the latter is the python idiom for the former.
This is a process that in the past has
taught me a lot (not Python, but that's just because I'm too new here :).
Once you get good at this process, it often helps you find the problem even
before posting, because boiling code down to what the /real/ problem is can
show you a lot you otherwise miss.
Sure, but if you do that, you sometimes have code that deviates from
the python idiom because there was originnaly a good reason for, but
that isn't obvious any more because you are temporarily working with
a boiled down piece of code. People making suggestions on how to
make that boiled down code look more pythonic by using the python
idiom are IMO not very helpfull because essentially those are just
aesthetic.

--
Antoon Pardon
Jul 23 '06 #84
On 2006-07-23 06:24:09, Antoon Pardon wrote:
>In general, I'd say that in this case the example was not well-chosen.
After such a "shudder removal", a poster should IMO review what caused
the shudder, and rephrase the original problem without the shudder.

The shudder is not with the poster. The poster can't predict how the
readers will react.
Correct. But if someone with the potential to help shudders, I might just
rephrase my "question" (the code) to suit that person's preferences. Why
not?
>That might take a few iterations, but in general, either one or more of
the "shudder removals" actually address the OP's issue, maybe without
any individual helper understanding all of the problem (due to
incomplete example code), or the iterations lead to a code that's
"shudder free" and still shows the original problem -- now usually in a
clearer form, because free of other issues that are not relevant to the
OP's point.

I doubt that.
I'm not sure, but I've seen in the short time I've been here that a few of
the regulars both have their specific "shudder" issues, and post helpful
alternative solutions and corrections. So I think it definitely can help to
address their "shudder" issues and get this out of the way.
My experience is that you have more chance of being helped by people who
try to understand where the OP is trying to go form than from those who
react to style issues.
No contest to that. But why not talk to the others, who in a way insist on
their idiom but otherwise contribute to helpful solutions, in their idiom?
I have never seem a bug go away because someone suggested to write "if
Number:" instead of "if Number != 0:"
Of course. I didn't mean to imply this. But if the only thing that's
required from me is to rephrase my code idiom and replace the "number != 0"
comparisons with "number", that's a small price to pay.

You are right, IMO, that this stuff comes over as petty sometimes. And that
it often is far away from the original question. But just as often
corrections that at first seem petty lead to different ideas about
implementation that the OP didn't consider.

My view is: I ask for help on a public forum. I get what I get... and if I
consider that someone who responded with something that's not immediately
helpful has a potential to help me better, I try to get in a dialog and
address what has been suggested, carving out my real problem in the idiom
of that person. This is my responsibility -- after all, I'm the one who
wants to learn how that person would solve my problem. Later then I can try
to separate what I want to use from that solution from what I consider
personal preference of the helping person.

>E.g. if someone makes a suggestion that is valid with the example code I
posted but not with the real code I have, I need to post an updated
example code that introduces a restriction similar to the one I
actually have, which then correctly invalidates the formerly valid
suggestion -- and helps getting more helpful responses.

Not necessarily. A valid suggestion doesn't imply a relevant suggestion.

If someone come with code like:

if Number != 0:

And someone suggests that the python idiom is

if Number:

Then that suggestion is valid, but it also is irrelevant.
Correct. But if it helps the person who suggested it to see the original
problem, now not hidden (for that person) under offending idiom, then the
change was relevant -- not for the problem, but for the communication about
it.

It's like if you want good stock advice from your uncle, who's experienced
in the matter but very formal, ask him without using the f*** word. You can
use it when asking your other uncle, who's also experienced but doesn't
really care about formalities. Tune in if you want a good channel...

>This is a process that in the past has taught me a lot (not Python, but
that's just because I'm too new here :). Once you get good at this
process, it often helps you find the problem even before posting,
because boiling code down to what the /real/ problem is can show you a
lot you otherwise miss.

Sure, but if you do that, you sometimes have code that deviates from the
python idiom because there was originnaly a good reason for, but that
isn't obvious any more because you are temporarily working with a boiled
down piece of code. People making suggestions on how to make that boiled
down code look more pythonic by using the python idiom are IMO not very
helpfull because essentially those are just aesthetic.
I agree that mere aesthetic changes usually don't address the problem in
itself. But it's just like posting here in a distant Chinese dialect won't
do you any good (and neither in a distant, say, Scottish dialect :). If you
want to get up a helpful communication, you need to use the right language.
Here it is English and Python :) and if making my example code more
pythonic (and my textual part more English) helps me creating a better
communication about the issue I'm interested in, that's what I do (and what
I'd recommend everybody else to do).

If there is a valid reason for a part of the code being different
("non-pythonic"), and that difference may be relevant, then there's a way
to show that reason in the example code. It may be that exactly this
process of boiling the code down to the relevant pieces shows you the
answer. That happens more often than most people realize, and is a process
that's quite valuable.

To apply that to your example... If there's no particular reason to write
"number != 0", then just repost the problem code with "number" instead and
you're done. But if there's a reason, try to set up your example code so it
shows that reason. This both helps people understand your problem better,
and may just show the reason for the problem -- after all, you most often
than not don't know where exactly your problem is, so you're not in a good
position to judge what you can leave out of the code without taking out the
problematic part. So: boil down your code to what shows the problem, and
nothing more, as much as possible, and present it in an idiom that helps
the others to help you.

Gerhard

Jul 23 '06 #85
On 2006-07-23, Gerhard Fiedler <ge*****@gmail.comwrote:
On 2006-07-23 06:24:09, Antoon Pardon wrote:
>>In general, I'd say that in this case the example was not well-chosen.
After such a "shudder removal", a poster should IMO review what caused
the shudder, and rephrase the original problem without the shudder.

The shudder is not with the poster. The poster can't predict how the
readers will react.

Correct. But if someone with the potential to help shudders, I might just
rephrase my "question" (the code) to suit that person's preferences. Why
not?
The point is that the shudder makes people react in an unhelpfull way.
If you think they still can be helpfull and you want to respond in
such a way that makes it more likely they will respond in a helpfull
way, sure go ahead.
>>That might take a few iterations, but in general, either one or more of
the "shudder removals" actually address the OP's issue, maybe without
any individual helper understanding all of the problem (due to
incomplete example code), or the iterations lead to a code that's
"shudder free" and still shows the original problem -- now usually in a
clearer form, because free of other issues that are not relevant to the
OP's point.

I doubt that.

I'm not sure, but I've seen in the short time I've been here that a few of
the regulars both have their specific "shudder" issues, and post helpful
alternative solutions and corrections. So I think it definitely can help to
address their "shudder" issues and get this out of the way.
Sure, but it takes time. Not everyone thinks it is worth that time.
>My experience is that you have more chance of being helped by people who
try to understand where the OP is trying to go form than from those who
react to style issues.

No contest to that. But why not talk to the others, who in a way insist on
their idiom but otherwise contribute to helpful solutions, in their idiom?
That is what each person has to decide for by himself. My personal
experience is others usually have come with equally usefull
contributions without losing time harping on Python idiom.
Your milage may vary.
My view is: I ask for help on a public forum. I get what I get... and if I
consider that someone who responded with something that's not immediately
helpful has a potential to help me better, I try to get in a dialog and
address what has been suggested, carving out my real problem in the idiom
of that person. This is my responsibility -- after all, I'm the one who
wants to learn how that person would solve my problem. Later then I can try
to separate what I want to use from that solution from what I consider
personal preference of the helping person.
It all depends. If that person is one of many that responded, I may
think it is not worth my time to find out how this particular person
would solve my problem. If he seems to be the only one who has a clue
I may be more inclined to get that dialog started.
>>E.g. if someone makes a suggestion that is valid with the example code I
posted but not with the real code I have, I need to post an updated
example code that introduces a restriction similar to the one I
actually have, which then correctly invalidates the formerly valid
suggestion -- and helps getting more helpful responses.

Not necessarily. A valid suggestion doesn't imply a relevant suggestion.

If someone come with code like:

if Number != 0:

And someone suggests that the python idiom is

if Number:

Then that suggestion is valid, but it also is irrelevant.

Correct. But if it helps the person who suggested it to see the original
problem, now not hidden (for that person) under offending idiom, then the
change was relevant -- not for the problem, but for the communication about
it.

It's like if you want good stock advice from your uncle, who's experienced
in the matter but very formal, ask him without using the f*** word. You can
use it when asking your other uncle, who's also experienced but doesn't
really care about formalities. Tune in if you want a good channel...
That is one side of the coin. The other side is that if the formal
uncle is heard a lot without someone contradicting him from time
to time, then all the newbies will think that formal is the
way to go, creating a lot more people who are somewhat uptight.
causing a lot of time to go into getting things formal instead
of solving the problem.
I agree that mere aesthetic changes usually don't address the problem in
itself. But it's just like posting here in a distant Chinese dialect won't
do you any good (and neither in a distant, say, Scottish dialect :). If you
want to get up a helpful communication, you need to use the right language.
Here it is English and Python :) and if making my example code more
pythonic (and my textual part more English) helps me creating a better
communication about the issue I'm interested in, that's what I do (and what
I'd recommend everybody else to do).

If there is a valid reason for a part of the code being different
("non-pythonic"), and that difference may be relevant, then there's a way
to show that reason in the example code. It may be that exactly this
process of boiling the code down to the relevant pieces shows you the
answer. That happens more often than most people realize, and is a process
that's quite valuable.

To apply that to your example... If there's no particular reason to write
"number != 0", then just repost the problem code with "number" instead and
you're done. But if there's a reason, try to set up your example code so it
shows that reason.
This goes against the advise that is given here and in other language and
programming groups: If you have a problem with particular behaviour (a
bug) reduce your program to the minimal that still produces the trouble
some behaviour.
This both helps people understand your problem better,
Sure, but it seems there are people who can tangle the problem without
knowing whether or not there is a reason. They just look at the code
and figure out what it does, whithout bothering about how it should
look like and in the end that is the most helpfull attitude.
and may just show the reason for the problem -- after all, you most often
than not don't know where exactly your problem is, so you're not in a good
position to judge what you can leave out of the code without taking out the
problematic part. So: boil down your code to what shows the problem, and
nothing more, as much as possible, and present it in an idiom that helps
the others to help you.
I don't know. It seems a waste of time a lot of the times. If I'm
talking with someone in real life about a problem and I get the
feeling that person is more interested in me wording the problem
in the proper formal way instead of caring about the problem itself,
I probably consider not longer bothering this person with my problems
unless there seems to be no alternative.

I think the same applies to newsgroups.

--
Antoon Pardon
Jul 25 '06 #86
On 2006-07-25 17:59:22, Antoon Pardon wrote:
>My view is: I ask for help on a public forum. I get what I get... and if
I consider that someone who responded with something that's not
immediately helpful has a potential to help me better, I try to get in
a dialog and address what has been suggested, carving out my real
problem in the idiom of that person. This is my responsibility -- after
all, I'm the one who wants to learn how that person would solve my
problem. Later then I can try to separate what I want to use from that
solution from what I consider personal preference of the helping
person.

It all depends. If that person is one of many that responded, I may
think it is not worth my time to find out how this particular person
would solve my problem. If he seems to be the only one who has a clue I
may be more inclined to get that dialog started.
Exactly. If there are people more tuned into your channel, that's where
you're more inclined to go. If not, you tune into some other's channel.

>It's like if you want good stock advice from your uncle, who's
experienced in the matter but very formal, ask him without using the
f*** word. You can use it when asking your other uncle, who's also
experienced but doesn't really care about formalities. Tune in if you
want a good channel...

That is one side of the coin. The other side is that if the formal uncle
is heard a lot without someone contradicting him from time to time, then
all the newbies will think that formal is the way to go, creating a lot
more people who are somewhat uptight. causing a lot of time to go into
getting things formal instead of solving the problem.
"So what?", I'm inclined to ask <g If someone does something without
knowing why, I'm not really bursting of sympathy. In real life, I've found
that there isn't that much I have to invest to get the channel clean, so to
speak. And where I think it's too much, I don't do it. I don't see much of
a difference here.

You definitely have a point in that some of that is not necessary. But
then... there's so much in a typical communication situation that is not
(objectively) necessary :)

>To apply that to your example... If there's no particular reason to
write "number != 0", then just repost the problem code with "number"
instead and you're done. But if there's a reason, try to set up your
example code so it shows that reason.

This goes against the advise that is given here and in other language and
programming groups: If you have a problem with particular behaviour (a
bug) reduce your program to the minimal that still produces the trouble
some behaviour.
Right... why against that? The minimal and communicable piece of code that
shows the problem. That's what I'm saying. To apply that to the example: if
the difference between the two styles is not relevant and "number" alone is
enough to reproduce the problem, post the code using "number". If "number
!= 0" is necessary to reproduce the problem, add some code that shows /why/
you have to use "number != 0" and can't use the simple "number". It may be
part of the problem.

Sure, but it seems there are people who can tangle the problem without
knowing whether or not there is a reason. They just look at the code
and figure out what it does, whithout bothering about how it should
look like and in the end that is the most helpfull attitude.
Sometimes. Sometimes digging deeper may be helpful, too. But nobody's
perfect anyway, so just pick up what suits you :)

Gerhard

Jul 25 '06 #87

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

18
by: craig | last post by:
I am curious about how many of you prefer style 1 vs. style 2, and why. Are there names for these style? style 1: method { }
144
by: Natt Serrasalmus | last post by:
After years of operating without any coding standards whatsoever, the company that I recently started working for has decided that it might be a good idea to have some. I'm involved in this...
29
by: Ron Burd | last post by:
Hi, As my company is moving into C# they are enforcing the use of styling convention in the source code, such as methods naming conventions, newlines, etc. Does someone know of products that...
4
by: Dotnetjunky | last post by:
Hi, So far, I've found tons of documents describing recommended coding standards for C#, but not a single piece on VB.NET yet. Anybody here knows such a coding standards guideline on VB.NET...
4
by: Mike Labosh | last post by:
I realize that you people have not seen much of me other than some framework responses I have posted. I am primarily a VB guy (yes, you can laugh) But I have lurked here for several years,...
13
by: benben | last post by:
Is there an effort to unify the c++ coding standard? Especially identifier naming. Not a big issue but it would be annoying to have to incorporate different coding styles simultaneously when...
3
by: ct-86 | last post by:
http://www.cdbook.cn/book.asp?id=2393 Organizational and Policy Issues 1 0. Don't sweat the small stuff. (Or: Know what not to standardize.) 2 1. Compile cleanly at high warning levels. 4 2....
7
by: Robert Seacord | last post by:
The CERT/CC has just deployed a new web site dedicated to developing secure coding standards for the C programming language, C++, and eventually other programming language. We have already...
1
by: Jim Johnson | last post by:
is this C style coding? I don't seem to see much C++ code in this way. is this a bad programming practice? code seem ugly coding this way. =================
7
by: MJ_India | last post by:
Style 1: struct my_struct { ... }; typedef my_struct my_struct_t; Style 2: typedef struct my_struct {
0
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
1
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: Vimpel783 | last post by:
Hello! Guys, I found this code on the Internet, but I need to modify it a little. It works well, the problem is this: Data is sent from only one cell, in this case B5, but it is necessary that data...
0
by: jfyes | last post by:
As a hardware engineer, after seeing that CEIWEI recently released a new tool for Modbus RTU Over TCP/UDP filtering and monitoring, I actively went to its official website to take a look. It turned...
0
by: ArrayDB | last post by:
The error message I've encountered is; ERROR:root:Error generating model response: exception: access violation writing 0x0000000000005140, which seems to be indicative of an access violation...
1
by: Defcon1945 | last post by:
I'm trying to learn Python using Pycharm but import shutil doesn't work
1
by: Shællîpôpï 09 | last post by:
If u are using a keypad phone, how do u turn on JavaScript, to access features like WhatsApp, Facebook, Instagram....
0
by: af34tf | last post by:
Hi Guys, I have a domain whose name is BytesLimited.com, and I want to sell it. Does anyone know about platforms that allow me to list my domain in auction for free. Thank you
0
by: Faith0G | last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.