In article 87sir2et1d@elektro.pacujo.net,
Marko Rauhamaa ma...@pacujo.net wrote:
Mark Lawrence breamore...@yahoo.co.uk:
http://c2.com/cgi/wiki?SwitchStatementsSmell
Your brief summary, please, Mark?
Anyway, the first 1000 lines or so that I managed to read from that page
stated a valid
alb...@spenarnc.xs4all.nl (Albert van der Horst):
I can't see why parsers decoders are any different. The Pentium
assembler in my ciforth's ``forth.lab'' library has not a single if
statement and I reckon it is a superior design. (State is kept in an
ai blackboard fashion in bitmaps.) Forth
On 2014-03-02, Chris Angelico ros...@gmail.com wrote:
On Mon, Mar 3, 2014 at 3:55 AM, Mark Lawrence breamore...@yahoo.co.uk wrote:
On 02/03/2014 16:45, Grant Edwards wrote:
That's irrelevent. The actual location of the memory containing the
struct object (static, stack, heap, shared)
On Tue, Mar 4, 2014 at 1:18 AM, Grant Edwards invalid@invalid.invalid wrote:
Note that, technically, Grant is correct as long as you grant (heh)
that a structure may have an invisible member, the virtual function
table pointer. C++ only (I don't believe C has virtual functions -
but it may
Grant Edwards invalid@invalid.invalid:
any decent compiler should be able to generate the same code for a
switch statement and for an equivalent chained if/else.
It's not so easy to be decent, especially when it comes to a language as
dynamic as Python.
Marko
--
Roy Smith r...@panix.com:
Python already has a switch statement. It's just spelled funny...
[...]
try:
raise value
except Case1:
print did case 1
except (Case2, Case3):
print did either case 2 or 3
else:
print did default
Not bad! Definitely worth considering.
No
Ben Finney ben+pyt...@benfinney.id.au:
The unreliability is “will objects defined elsewhere have a different
identity?”
That question is not interesting in my context, and has no bearing on
the correctness of the program.
Marko
--
https://mail.python.org/mailman/listinfo/python-list
On Sat, 01 Mar 2014 19:29:41 +0200, Marko Rauhamaa wrote:
Michael Torrie torr...@gmail.com:
No, '==' works fine no matter what objects you assign to your state
variables.
Well, it doesn't since
a = float(nan)
a is a
True
a == a
False
No, that is working
Steven D'Aprano steve+comp.lang.pyt...@pearwood.info:
On Sat, 01 Mar 2014 19:29:41 +0200, Marko Rauhamaa wrote:
Michael Torrie torr...@gmail.com:
No, '==' works fine no matter what objects you assign to your state
variables.
Well, it doesn't since
a = float(nan)
a is a
True
Marko Rauhamaa ma...@pacujo.net:
If I take the API documentation on its face value, [...]
I *must* use is for os.POSIX_FAVD_*:
if fsavd_flag is os.POSIX_FADV_RANDOM:
...
However, since a documentation flaw is more than likely, it is even more
prudent to avoid both == and is and
On Sun, Mar 2, 2014 at 8:35 PM, Marko Rauhamaa ma...@pacujo.net wrote:
However, on the same reference page, os.posix_fadvise() is defined. We
read:
advice is one of POSIX_FADV_NORMAL, POSIX_FADV_SEQUENTIAL,
POSIX_FADV_RANDOM, POSIX_FADV_NOREUSE, POSIX_FADV_WILLNEED or
Chris Angelico ros...@gmail.com:
And there's another thing you can do to test.
import os
type(os.POSIX_FADV_RANDOM)
class 'int'
Is that what you do in your programs?
So use ==. If it's later changed and you have to instead use 'is', you
can change your code.
Quite a robust API, huh?
On Sun, 02 Mar 2014 11:35:43 +0200, Marko Rauhamaa wrote:
Nobody is saying there's a bug in the implementation of ==. I'm just
saying == cannot be taken as a universal superset of is. Therefore a
program cannot blindly use == to test for identity.
Um, yes? Nor can you use to test for
Marko Rauhamaa ma...@pacujo.net writes:
Ben Finney ben+pyt...@benfinney.id.au:
The unreliability is “will objects defined elsewhere have a different
identity?”
That question is not interesting in my context, and has no bearing on
the correctness of the program.
You keep vacillating
Steven D'Aprano steve+comp.lang.pyt...@pearwood.info:
On Sun, 02 Mar 2014 11:35:43 +0200, Marko Rauhamaa wrote:
Now, what kinds of object are those constants? We are not supposed to
know or care.
Incorrect. We are supposed to know and care.
Then, the documentation is seriously flawed. It
On 02/03/2014 10:59, Ben Finney wrote:
Marko Rauhamaa ma...@pacujo.net writes:
Ben Finney ben+pyt...@benfinney.id.au:
The unreliability is “will objects defined elsewhere have a different
identity?”
That question is not interesting in my context, and has no bearing on
the correctness of
On 02/03/2014 09:35, Marko Rauhamaa wrote:
Steven D'Aprano steve+comp.lang.pyt...@pearwood.info:
On Sat, 01 Mar 2014 19:29:41 +0200, Marko Rauhamaa wrote:
Michael Torrie torr...@gmail.com:
No, '==' works fine no matter what objects you assign to your state
variables.
Well, it doesn't since
Chris Angelico ros...@gmail.com Wrote in message:
On Sun, Mar 2, 2014 at 3:02 PM, Dave Angel da...@davea.name wrote:
The quote you make from the C standard doesn't mention malloc, so
you're arguing different things. It's not the compiler that casts
the malloc return value to the struct
On Mon, Mar 3, 2014 at 12:22 AM, Dave Angel da...@davea.name wrote:
Sure, for some definition of usable. Overhead such as block
size, freelist pointer etc., are obviously outside of the
returned block. But the array size that's specified in a call to
new [], and the vptr, are definitely
Marko Rauhamaa ma...@pacujo.net:
Roy Smith r...@panix.com:
Python already has a switch statement. It's just spelled funny...
[...]
try:
raise value
except Case1:
print did case 1
except (Case2, Case3):
print did either case 2 or 3
else:
print did default
Not bad!
In article 87fvn08vux@elektro.pacujo.net,
Marko Rauhamaa ma...@pacujo.net wrote:
Marko Rauhamaa ma...@pacujo.net:
Roy Smith r...@panix.com:
Python already has a switch statement. It's just spelled funny...
[...]
try:
raise value
except Case1:
print did case 1
Roy Smith r...@panix.com:
In article 87fvn08vux@elektro.pacujo.net,
Marko Rauhamaa ma...@pacujo.net wrote:
3. TRY-EXCEPT (3500% slower than DICT DISPATCH TABLE)
I'm glad to hear that. I hope nobody took me seriously when I
suggested this.
I actually have employed the idea before in a
On Mon, Mar 3, 2014 at 2:52 AM, Marko Rauhamaa ma...@pacujo.net wrote:
Roy Smith r...@panix.com:
In article 87fvn08vux@elektro.pacujo.net,
Marko Rauhamaa ma...@pacujo.net wrote:
3. TRY-EXCEPT (3500% slower than DICT DISPATCH TABLE)
I'm glad to hear that. I hope nobody took me seriously
On 2014-03-02, Dave Angel da...@davea.name wrote:
Grant Edwards invalid@invalid.invalid Wrote in message:
On 2014-02-24, Michael Torrie torr...@gmail.com wrote:
Why would you think that? The address of the start of your malloc'ed
structure is the same as the address of the first element.
On 02/03/2014 16:23, Chris Angelico wrote:
A switch block that works with constants and equality *can* be turned
into a dict. If the constants are hashable, use them as the keys
directly; if they're not hashable and/or you want to use object
identity as the criterion (effectively like using
On 02/03/2014 16:45, Grant Edwards wrote:
That's irrelevent. The actual location of the memory containing the
struct object (static, stack, heap, shared) doesn't matter. The
address of the first field in a struture object _is_ the address of
the structure object.
You say struture, I'll say
On 03/02/2014 03:07 AM, Chris Angelico wrote:
import os
type(os.POSIX_FADV_RANDOM)
class 'int'
So use ==. If it's later changed and you have to instead use 'is', you
can change your code.
I don't see why == wouldn't continue to work if os.POSIX_FADV_RANDOM
became an object of a different
Chris Angelico ros...@gmail.com Wrote in message:
On Mon, Mar 3, 2014 at 12:22 AM, Dave Angel da...@davea.name wrote:
Sure, for some definition of usable. Overhead such as block
size, freelist pointer etc., are obviously outside of the
returned block. But the array size that's specified
On Mon, Mar 3, 2014 at 3:55 AM, Mark Lawrence breamore...@yahoo.co.uk wrote:
On 02/03/2014 16:45, Grant Edwards wrote:
That's irrelevent. The actual location of the memory containing the
struct object (static, stack, heap, shared) doesn't matter. The
address of the first field in a
On Mon, Mar 3, 2014 at 6:17 AM, Dave Angel da...@davea.name wrote:
Array size is inside the malloc block, but outside the struct
block. As you can see if you try to delete without the brackets
when you used new [], some runtimes will crash.
As in, you have to use delete [] x to correspond
Michael Torrie torr...@gmail.com:
I don't see why == wouldn't continue to work if os.POSIX_FADV_RANDOM
became an object of a different type.
It probably would.
If one were begging for trouble, one *could* define:
class ABC:
A = 1
B = 1.0
C = 1+0j
Now:
ABC.A ==
In article 87txbg48kd@elektro.pacujo.net,
Marko Rauhamaa ma...@pacujo.net wrote:
Michael Torrie torr...@gmail.com:
I don't see why == wouldn't continue to work if os.POSIX_FADV_RANDOM
became an object of a different type.
It probably would.
If one were begging for trouble, one
On Mon, Mar 3, 2014 at 8:03 AM, Marko Rauhamaa ma...@pacujo.net wrote:
If one were begging for trouble, one *could* define:
class ABC:
A = 1
B = 1.0
C = 1+0j
You're missing the point of flags, though. One does not use floats for
flags. Flags are normally going to be
On 03/02/2014 02:03 PM, Marko Rauhamaa wrote:
Michael Torrie torr...@gmail.com:
I don't see why == wouldn't continue to work if os.POSIX_FADV_RANDOM
became an object of a different type.
It probably would.
If one were begging for trouble, one *could* define:
class ABC:
A =
Michael Torrie torr...@gmail.com:
And one could also set A=1 and B=1 if he was trying to be stupid.
[...]
If Mark H wants to use an idiom that isn't conventional, or isn't
widely used, he is free to do so; I can't see much harm in it. But
certainly it's not the normal way that it's done in
Chris Angelico ros...@gmail.com Wrote in message:
}
so in that case, the array size is inside the malloc'd block, but it's
still invisible to the calling function.
Please quit using negative language when you're so vehemently
agreeing with me.
The data is sometimes not at the
On Sun, 02 Mar 2014 13:33:11 +0200, Marko Rauhamaa wrote:
Steven D'Aprano steve+comp.lang.pyt...@pearwood.info:
On Sun, 02 Mar 2014 11:35:43 +0200, Marko Rauhamaa wrote:
Now, what kinds of object are those constants? We are not supposed to
know or care.
Incorrect. We are supposed to know
Ben Finney ben+pyt...@benfinney.id.au:
Since you don't care about identity, only that the objects have
different values, you should be comparing for equality with ‘==’.
Ok, one last attempt.
I need *identifiers*. I could simply define:
class ABC:
A = object()
B = object()
Steven D'Aprano steve+comp.lang.pyt...@pearwood.info:
But I'm not sure that there is a good reason to put the class definitions
inside the __init__ method. That means every time you create a new
StateMachine instance, the classes have to be re-created.
[...]
It will be much more
Marko Rauhamaa ma...@pacujo.net writes:
Ben Finney ben+pyt...@benfinney.id.au:
Since you don't care about identity, only that the objects have
different values, you should be comparing for equality with ‘==’.
Ok, one last attempt.
I need *identifiers*.
And, as you've realised, without
Ben Finney ben+pyt...@benfinney.id.au:
Use ‘==’, since that's all that matters for getting a value that will
work fine.
You are telling me to use '==' if I choose string objects and 'is' if I
choose some other objects.
I prefer a solution that works regardless of what objects I choose for
On Sat, Mar 1, 2014 at 10:28 PM, Marko Rauhamaa ma...@pacujo.net wrote:
Ben Finney ben+pyt...@benfinney.id.au:
Use ‘==’, since that's all that matters for getting a value that will
work fine.
You are telling me to use '==' if I choose string objects and 'is' if I
choose some other objects.
Marko Rauhamaa ma...@pacujo.net writes:
Ben Finney ben+pyt...@benfinney.id.au:
Use ‘==’, since that's all that matters for getting a value that will
work fine.
You are telling me to use '==' if I choose string objects and 'is' if I
choose some other objects.
No. I'm telling you that
On 01/03/2014 11:59, Chris Angelico wrote:
On Sat, Mar 1, 2014 at 10:28 PM, Marko Rauhamaa ma...@pacujo.net wrote:
There really is no taboo against string object identity if you know what
you are doing.
And, as proven here in this thread, you do not know what you are doing.
Why do you
On 03/01/2014 04:28 AM, Marko Rauhamaa wrote:
Ben Finney ben+pyt...@benfinney.id.au:
Use ‘==’, since that's all that matters for getting a value that will
work fine.
You are telling me to use '==' if I choose string objects and 'is' if I
choose some other objects.
No, '==' works fine no
On Sat, 01 Mar 2014 22:59:52 +1100, Chris Angelico wrote:
On Sat, Mar 1, 2014 at 10:28 PM, Marko Rauhamaa ma...@pacujo.net
wrote:
Ben Finney ben+pyt...@benfinney.id.au:
Use ‘==’, since that's all that matters for getting a value that will
work fine.
You are telling me to use '==' if I
On Sat, 01 Mar 2014 12:31:39 +0200, Marko Rauhamaa wrote:
I need *identifiers*. I could simply define:
class ABC:
A = object()
B = object()
C = object()
The program would work perfectly.
Except, if it's got a bug. I know self.abc contains either A, B or C,
Ben Finney ben+pyt...@benfinney.id.au:
No. I'm telling you that ‘is’ is *wrong* for comparing strings,
because it is unreliable.
No, it isn't as long as the string object references have a common
assignment pedigree. Assignment (including parameter passing) is
guaranteed to preserve identity
On Sun, Mar 2, 2014 at 4:07 AM, Steven D'Aprano
steve+comp.lang.pyt...@pearwood.info wrote:
On Sat, 01 Mar 2014 22:59:52 +1100, Chris Angelico wrote:
And, as proven here in this thread, you do not know what you are doing.
Steady on, that's a bit harsh. In context, I think that Marko is
On Sun, Mar 2, 2014 at 4:23 AM, Marko Rauhamaa ma...@pacujo.net wrote:
Ben Finney ben+pyt...@benfinney.id.au:
No. I'm telling you that ‘is’ is *wrong* for comparing strings,
because it is unreliable.
No, it isn't as long as the string object references have a common
assignment pedigree.
Michael Torrie torr...@gmail.com:
No, '==' works fine no matter what objects you assign to your state
variables.
Well, it doesn't since
a = float(nan)
a is a
True
a == a
False
More generally, it depends on how the __eq__ method has been implemented
for the class. You might
On Sun, Mar 2, 2014 at 4:29 AM, Marko Rauhamaa ma...@pacujo.net wrote:
You might even (foolishly) define a class such that:
a == b
False
a != b
False
Not necessarily even foolish; the SQL NULL value [1] behaves like that.
ChrisA
[1] Which isn't a value, except when it is
--
On 03/01/2014 10:29 AM, Marko Rauhamaa wrote:
Michael Torrie torr...@gmail.com:
No, '==' works fine no matter what objects you assign to your state
variables.
Well, it doesn't since
a = float(nan)
a is a
True
a == a
False
More generally, it depends on how the
Steven D'Aprano steve+comp.lang.pyt...@pearwood.info:
It seems to me that he's just assuming that symbols ought to be
singletons, hence his focus on identity rather than equality.
Yes.
A practical angle is this: if I used strings as symbols and compared
them with ==, logically I shouldn't
On 2014-02-24, Michael Torrie torr...@gmail.com wrote:
On 02/24/2014 11:05 AM, j.e.ha...@gmail.com wrote:
typedef struct {
int value;
} Number;
Number *o;
o = malloc(sizeof(*o));
o-value=3;
printf(o%p, o-value%p\n, o, o-value);
o0x9fe5008, o-value0x9fe5008
Is the compiler
On 2014-02-28, Marko Rauhamaa ma...@pacujo.net wrote:
Chris Angelico ros...@gmail.com:
Can you elaborate on this nonliteral constants point? How is it a
problem if DISCONNECTING isn't technically a constant? It follows the
Python convention of being in all upper-case, so the programmer
On Sat, Mar 1, 2014 at 10:06 AM, Marko Rauhamaa ma...@pacujo.net wrote:
A colleague of mine taught me decades back that the whole point of OO
was the avoidance of if and switch statements. So if your code has an if
or switch statement, chances are you are doing something wrong.
This sounds
In article 87d2i7wbxs@elektro.pacujo.net,
Marko Rauhamaa ma...@pacujo.net wrote:
Neil Cerutti ne...@norwich.edu:
Check out Go's switch statement for an example of what it might
look like in Python. Except you'd get it without labeled break or
the fallthrough statement.
Python
On 2014-02-28, Marko Rauhamaa ma...@pacujo.net wrote:
Here's a use case for is with strings (or ints):
class Connection:
IDLE = IDLE
CONNECTING = CONNECTING
CONNECTED = CONNECTED
DISCONNECTING = DISCONNECTING
DISCONNECTED = DISCONNECTED
def
On 2014-02-28, Mark Lawrence breamore...@yahoo.co.uk wrote:
http://c2.com/cgi/wiki?SwitchStatementsSmell
So lack of a switch state is an attempt to force Python programmers to
write things in an object oriented way?
--
Grant Edwards grant.b.edwardsYow! FUN is never
In article 0b414429-74ee-45dd-9465-c87e98c36...@googlegroups.com,
Mark H. Harris harrismh...@gmail.com wrote:
On Friday, February 28, 2014 3:03:25 PM UTC-6, Marko Rauhamaa wrote:
Marko
... and between me and you, here is a snip from dmath.py from the atan(x)
function:
if
In article mailman.7483.1393632181.18130.python-l...@python.org,
Ben Finney ben+pyt...@benfinney.id.au wrote:
Of course. That's the point of describing something as a âcode smellâ:
it may have exceptions where the smell does not indicate an actual
problem, but those are not the normal
In article 87mwh9969m@elektro.pacujo.net,
Marko Rauhamaa ma...@pacujo.net wrote:
Michael Torrie torr...@gmail.com:
No, '==' works fine no matter what objects you assign to your state
variables.
Well, it doesn't since
a = float(nan)
a is a
True
a == a
False
On Saturday, March 1, 2014 12:24:15 AM UTC-6, Chris Angelico wrote:
much code. If you want to change anything, you potentially have to
edit three places: the list of constants at the top, the condition
function, and the switch.
This can't be your idea of readability. Show me where
On 01/03/2014 21:40, Mark H. Harris wrote:
On Saturday, March 1, 2014 12:24:15 AM UTC-6, Chris Angelico wrote:
much code. If you want to change anything, you potentially have to
edit three places: the list of constants at the top, the condition
function, and the switch.
This can't be your
On Saturday, March 1, 2014 4:01:12 PM UTC-6, Mark Lawrence wrote:
No elipses, just the paragraphs not wrapped and the double line spacing.
Good old gg, I just love it.
How do I fix it? Is there a setting someplace? I tried pulling up the page
you linked, but blank.
Thanks in
On Sun, Mar 2, 2014 at 8:40 AM, Mark H. Harris harrismh...@gmail.com wrote:
hi Chris, I don't think you're wrong. There are two issues for me (and one
of them is not how the switch is implemented).
1) Is it easier for average users of python as a language to read switch case
default, or
Marko Rauhamaa ma...@pacujo.net writes:
Steven D'Aprano steve+comp.lang.pyt...@pearwood.info:
It seems to me that he's just assuming that symbols ought to be
singletons, hence his focus on identity rather than equality.
Yes.
Give that up, then. Your assumption is false in Python, and is
Marko Rauhamaa ma...@pacujo.net writes:
Ben Finney ben+pyt...@benfinney.id.au:
No. I'm telling you that ‘is’ is *wrong* for comparing strings,
because it is unreliable.
No, it isn't as long as the string object references have a common
assignment pedigree. Assignment (including parameter
Grant Edwards invalid@invalid.invalid writes:
On 2014-02-28, Mark Lawrence breamore...@yahoo.co.uk wrote:
http://c2.com/cgi/wiki?SwitchStatementsSmell
So lack of a switch state is an attempt […]
Since when is the absence of action an “attempt” to do anything?
You're assuming the not-doing
On Saturday, March 1, 2014 4:36:07 PM UTC-6, Ben Finney wrote:
Since when is the absence of action an attempt to do anything?
You're assuming the not-doing of something must have a purpose. That
assumption doesn't seem justified.
Correct. Argument from silence is logical fallacy; lack of
On Sat, 01 Mar 2014 20:25:51 +0200, Marko Rauhamaa wrote:
Steven D'Aprano steve+comp.lang.pyt...@pearwood.info:
It seems to me that he's just assuming that symbols ought to be
singletons, hence his focus on identity rather than equality.
Yes.
A practical angle is this: if I used
On 01/03/2014 22:07, Mark H. Harris wrote:
On Saturday, March 1, 2014 4:01:12 PM UTC-6, Mark Lawrence wrote:
No elipses, just the paragraphs not wrapped and the double line spacing.
Good old gg, I just love it.
How do I fix it? Is there a setting someplace? I tried pulling up the
On Saturday, March 1, 2014 5:21:57 PM UTC-6, Mark Lawrence wrote:
https://wiki.python.org/moin/GoogleGroupsPython
Thanks, Mark. Whoohoo! Looks like gg has some work to do. rats(). Ok, so I'm
typing away here and when
I get to the boarder I should press the enter key so that the text is forced
On Sun, Mar 2, 2014 at 11:23 AM, Mark H. Harris harrismh...@gmail.com wrote:
On Saturday, March 1, 2014 5:21:57 PM UTC-6, Mark Lawrence wrote:
https://wiki.python.org/moin/GoogleGroupsPython
Thanks, Mark. Whoohoo! Looks like gg has some work to do. rats(). Ok, so I'm
typing away here and
On 02/03/2014 00:23, Mark H. Harris wrote:
On Saturday, March 1, 2014 5:21:57 PM UTC-6, Mark Lawrence wrote:
https://wiki.python.org/moin/GoogleGroupsPython
Thanks, Mark. Whoohoo! Looks like gg has some work to do. rats(). Ok, so I'm
typing away here and when
I get to the boarder I should
In article
captjjmqgh5-n8fgki+vmd8grzcw5np64kinka9_b6ewf8gv...@mail.gmail.com,
Chris Angelico ros...@gmail.com wrote:
What I would recommend, if you don't feel like setting up NNTP, is to
subscribe to the mailing list:
https://mail.python.org/mailman/listinfo/python-list
All the same
On 02/03/2014 00:55, Ned Deily wrote:
In article
captjjmqgh5-n8fgki+vmd8grzcw5np64kinka9_b6ewf8gv...@mail.gmail.com,
Chris Angelico ros...@gmail.com wrote:
What I would recommend, if you don't feel like setting up NNTP, is to
subscribe to the mailing list:
Grant Edwards invalid@invalid.invalid Wrote in message:
On 2014-02-24, Michael Torrie torr...@gmail.com wrote:
Why would you think that? The address of the start of your malloc'ed
structure is the same as the address of the first element. Surely
this is logical?
Not only is it logical,
On Sun, Mar 2, 2014 at 3:02 PM, Dave Angel da...@davea.name wrote:
The quote you make from the C standard doesn't mention malloc, so
you're arguing different things. It's not the compiler that casts
the malloc return value to the struct type.
C++ does implicitly convert the result, and
On Fri, 28 Feb 2014 09:43:58 +0200, Marko Rauhamaa wrote:
Chris Angelico ros...@gmail.com:
Simple rule of thumb: Never use 'is' with strings or ints. They're
immutable, their identities should be their values. Playing with 'is'
will only confuse you, unless you're specifically going for
Steven D'Aprano st...@pearwood.info writes:
On Fri, 28 Feb 2014 09:43:58 +0200, Marko Rauhamaa wrote:
class Connection:
IDLE = IDLE
[...]
CONNECTED = CONNECTED
[...]
def disconnect(self):
...
if self.state is CONNECTED:
On Fri, Feb 28, 2014 at 6:43 PM, Marko Rauhamaa ma...@pacujo.net wrote:
Here's a use case for is with strings (or ints):
class Connection:
IDLE = IDLE
CONNECTING = CONNECTING
CONNECTED = CONNECTED
DISCONNECTING = DISCONNECTING
DISCONNECTED =
Ben Finney ben+pyt...@benfinney.id.au:
There are two reasons why I think this is *still* not a justification
for using ‘is’ with string values:
First reason: This is better done by making it clear the value is an
arbitrary object that won't be compared for equality. Just use
‘object()’ to
On Fri, Feb 28, 2014 at 9:02 PM, Marko Rauhamaa ma...@pacujo.net wrote:
Yes, enums are long overdue. However, since any distinct objects will
do, there is nothing preventing you from using string objects.
String literals will often be interned if they look like (especially,
if they *are*)
On Fri, Feb 28, 2014 at 9:02 PM, Marko Rauhamaa ma...@pacujo.net wrote:
PS On the topic of enums, when are we getting support for a switch
statement?
I don't see that they're particularly connected. In my C code, I've
used enums frequently as quick constants, often never switching on
them.
Chris Angelico ros...@gmail.com:
String literals will often be interned if they look like (especially,
if they *are*) identifiers, so if you want to prevent other strings
from happening to match, you can't trust 'is'.
[...]
If you're using strings as state values, you should be using == to
Chris Angelico ros...@gmail.com:
Python currently has dispatch tables and if/elif chains, and a strong
cultural aversion to switch. You could change that by coming up with
some *really* awesome proposal, but you'll be fighting against the
tide a bit.
It's easy have a cultural aversion when
On Fri, Feb 28, 2014 at 10:30 PM, Marko Rauhamaa ma...@pacujo.net wrote:
Chris Angelico ros...@gmail.com:
String literals will often be interned if they look like (especially,
if they *are*) identifiers, so if you want to prevent other strings
from happening to match, you can't trust 'is'.
On Fri, Feb 28, 2014 at 10:38 PM, Marko Rauhamaa ma...@pacujo.net wrote:
Chris Angelico ros...@gmail.com:
Python currently has dispatch tables and if/elif chains, and a strong
cultural aversion to switch. You could change that by coming up with
some *really* awesome proposal, but you'll be
Chris Angelico ros...@gmail.com:
On Fri, Feb 28, 2014 at 10:30 PM, Marko Rauhamaa ma...@pacujo.net wrote:
Chris Angelico ros...@gmail.com:
a.state = a.INIT
In theory, yes. If that's all people will ever do, then you can safely
use == to check. Why are you using is?
The main reason to
On 2014-02-28, Marko Rauhamaa ma...@pacujo.net wrote:
Chris Angelico ros...@gmail.com:
Python currently has dispatch tables and if/elif chains, and a
strong cultural aversion to switch. You could change that by
coming up with some *really* awesome proposal, but you'll be
fighting against the
Neil Cerutti ne...@norwich.edu:
Check out Go's switch statement for an example of what it might
look like in Python. Except you'd get it without labeled break or
the fallthrough statement.
No need for the fallthrough (except that multiple cases should be
supported).
Labeled breaks wouldn't
On 2014-02-28, Ben Finney ben+pyt...@benfinney.id.au wrote:
Mark H. Harris harrismh...@gmail.com writes:
So, yeah, thinking about variables is just not going away.
Right. I would like, ideally, for the Python documentation to
avoid mentioning that term entirely; and I would hope for that
to
On Sat, Mar 1, 2014 at 1:26 AM, Marko Rauhamaa ma...@pacujo.net wrote:
Python isn't averse to the switch statement because it would be not
that useful. Rather, the problem is that Python doesn't have nonliteral
constants (scheme has builtin symbols). It is difficult to come up with
truly
On 28/02/2014 11:38, Marko Rauhamaa wrote:
Switch statements provide for excellent readability in parsers and state
machines, for example. They also allow the Python compiler to optimize
the statement internally unlike long if-else chains.
There are umpteen recipes for switch statements so
On 02/28/2014 01:46 AM, Ben Finney wrote:
Steven D'Aprano st...@pearwood.info writes:
On Fri, 28 Feb 2014 09:43:58 +0200, Marko Rauhamaa wrote:
class Connection:
IDLE = IDLE
[...]
CONNECTED = CONNECTED
[...]
def disconnect(self):
...
if
Chris Angelico ros...@gmail.com:
Can you elaborate on this nonliteral constants point? How is it a
problem if DISCONNECTING isn't technically a constant? It follows the
Python convention of being in all upper-case, so the programmer
understands not to rebind it. Is the problem that someone
On Sat, Mar 1, 2014 at 2:29 AM, Marko Rauhamaa ma...@pacujo.net wrote:
BTW, here's a syntax that doesn't introduce any new keywords:
with self.state from Connection.State:
if CONNECTING or CONNECTED:
...
elif DISONNECTING:
...
else:
On Fri, 28 Feb 2014 12:02:03 +0200, Marko Rauhamaa wrote:
PS On the topic of enums, when are we getting support for a switch
statement?
http://legacy.python.org/dev/peps/pep-3103/
http://legacy.python.org/dev/peps/pep-0275/
--
Steven
--
1 - 100 of 212 matches
Mail list logo
