Enum class with ToString functionality

  • Thread starter Bruno Desthuilliers
  • Start date
B

Bruno Desthuilliers

TheFlyingDutchman a écrit :
class TestOutcomes:
PASSED = 0
FAILED = 1
ABORTED = 2

def ToString(outcome):
if outcome == TestOutcomes.PASSED:
return "Passed"
elif outcome == TestOutcomes.FAILED :
return "Failed"
else:
return "Aborted"

ToString = staticmethod(ToString)

if __name__ == "__main__":
testResult = TestOutcomes.PASSED
testResultAsString = TestOutcomes.ToString(testResult)
print testResultAsString
print TestOutcomes.ToString(testResult)
Click to expand...

Technically correct, but totally unpythonic.

May I suggest some reading ?
http://dirtsimple.org/2004/12/python-is-not-java.html
 
B

Bruno Desthuilliers

TheFlyingDutchman a écrit :
Speaking of unpythonic, I would call

ToString = staticmethod(ToString)

A Perlific syntax.
Click to expand...

Nope, just a good ole HOF.

But nowadays, it's usually written this way:

@staticmethod
def some_static_method():
pass
Well the Foo.Foo complaint is bogus:

from Foo import Foo
Click to expand...

Yes. And properties are bogus - just use getters and setters.

Seriously, writing Java in Python is definitively on the masochist side.
But if you like pain...
 
B

bg_ie

Hi,

I have the following class -

class TestOutcomes:
PASSED = 0
FAILED = 1
ABORTED = 2

plus the following code -

testResult = TestOutcomes.PASSED

testResultAsString
if testResult == TestOutcomes.PASSED:
testResultAsString = "Passed"
elif testResult == TestOutcomes.FAILED :
testResultAsString = "Failed"
else:
testResultAsString = "Aborted"

But it would be much nicer if I had a function to covert to string as
part of the TestOutcomes class. How would I implement this?

Thanks,

Barry
 
Z

Zara

Hi,

I have the following class -

class TestOutcomes:
PASSED = 0
FAILED = 1
ABORTED = 2

plus the following code -

testResult = TestOutcomes.PASSED

testResultAsString
if testResult == TestOutcomes.PASSED:
testResultAsString = "Passed"
elif testResult == TestOutcomes.FAILED :
testResultAsString = "Failed"
else:
testResultAsString = "Aborted"

But it would be much nicer if I had a function to covert to string as
part of the TestOutcomes class. How would I implement this?
Click to expand...
You should implement __str__ (or __repr__) method in your class,

class TestOutcomes:
PASSED = 0
FAILED = 1
ABORTED = 2

def __str__(self):
textResultAsString="Unknown"
if testResult == TestOutcomes.PASSED:
testResultAsString = "Passed"
elif testResult == TestOutcomes.FAILED :
testResultAsString = "Failed"
else:
testResultAsString = "Aborted"
return testResultAsString

Regards,

Zara
 
D

David

Hi,

I have the following class -

class TestOutcomes:
PASSED = 0
FAILED = 1
ABORTED = 2

plus the following code -

testResult = TestOutcomes.PASSED

testResultAsString
if testResult == TestOutcomes.PASSED:
testResultAsString = "Passed"
elif testResult == TestOutcomes.FAILED :
testResultAsString = "Failed"
else:
testResultAsString = "Aborted"

But it would be much nicer if I had a function to covert to string as
part of the TestOutcomes class. How would I implement this?
Click to expand...

You can use reflection to do this. Perhaps a constructor that goes
through your class dict (dir(self)) and builds an int->string mapping
property based on the value and name of the attributes (perhaps just
the ones whose type is int). To get the exact same result as your code
above you can capitalize the first letter of the attribute name, and
lowercase the rest.
 
T

TheFlyingDutchman

Hi,

I have the following class -

class TestOutcomes:
PASSED = 0
FAILED = 1
ABORTED = 2

plus the following code -

testResult = TestOutcomes.PASSED

testResultAsString
if testResult == TestOutcomes.PASSED:
testResultAsString = "Passed"
elif testResult == TestOutcomes.FAILED :
testResultAsString = "Failed"
else:
testResultAsString = "Aborted"

But it would be much nicer if I had a function to covert to string as
part of the TestOutcomes class. How would I implement this?

Thanks,

Barry
Click to expand...

The equivalent to Java's toString() is __str__() in Python:

class TestOutcomes:
PASSED = 0
FAILED = 1
ABORTED = 2

def __init__(self,outcome):
self.outcome = outcome

def __str__(self):
if self.outcome == TestOutcomes.PASSED:
return "Passed"
elif self.outcome == TestOutcomes.FAILED :
return "Failed"
else:
return "Aborted"

if __name__ == "__main__":
testResult = TestOutcomes(TestOutcomes.ABORTED)
print testResult
testResult = TestOutcomes(TestOutcomes.FAILED)
a = testResult.__str__()
print a

Aborted
Failed
 
A

aine_canby

The equivalent to Java's toString() is __str__() in Python:

class TestOutcomes:
PASSED = 0
FAILED = 1
ABORTED = 2

def __init__(self,outcome):
self.outcome = outcome

def __str__(self):
if self.outcome == TestOutcomes.PASSED:
return "Passed"
elif self.outcome == TestOutcomes.FAILED :
return "Failed"
else:
return "Aborted"

if __name__ == "__main__":
testResult = TestOutcomes(TestOutcomes.ABORTED)
print testResult
testResult = TestOutcomes(TestOutcomes.FAILED)
a = testResult.__str__()
print a

Aborted
Failed- Dölj citerad text -

- Visa citerad text -
Click to expand...

Would this be crazy? -

class TestOutcomes:
PASSED = "PASSED"
FAILED = "FAILED"
ABORTED = "ABORTED"
 
B

Bjoern Schliessmann

I have the following class -

class TestOutcomes:
PASSED = 0
FAILED = 1
ABORTED = 2

plus the following code -

testResult = TestOutcomes.PASSED

testResultAsString
if testResult == TestOutcomes.PASSED:
testResultAsString = "Passed"
elif testResult == TestOutcomes.FAILED :
testResultAsString = "Failed"
else:
testResultAsString = "Aborted"

But it would be much nicer if I had a function to covert to string
as part of the TestOutcomes class. How would I implement this?
Click to expand...

Why don't use the simple approach like this?

TEST_PASSED = "Passed"
TEST_FAILED = "Failed"
TEST_ABORTED = "Aborted"

In Python, no one forces you to put everything in classes.

If you are determined to use the class approach, use the __str__
method. It's called when you do str(instance).

Regards,


Björn
 
T

TheFlyingDutchman

Hi,

I have the following class -

class TestOutcomes:
PASSED = 0
FAILED = 1
ABORTED = 2

plus the following code -

testResult = TestOutcomes.PASSED

testResultAsString
if testResult == TestOutcomes.PASSED:
testResultAsString = "Passed"
elif testResult == TestOutcomes.FAILED :
testResultAsString = "Failed"
else:
testResultAsString = "Aborted"

But it would be much nicer if I had a function to covert to string as
part of the TestOutcomes class. How would I implement this?

Thanks,

Barry
Click to expand...

class TestOutcomes:
PASSED = 0
FAILED = 1
ABORTED = 2

def ToString(outcome):
if outcome == TestOutcomes.PASSED:
return "Passed"
elif outcome == TestOutcomes.FAILED :
return "Failed"
else:
return "Aborted"

ToString = staticmethod(ToString)

if __name__ == "__main__":
testResult = TestOutcomes.PASSED
testResultAsString = TestOutcomes.ToString(testResult)
print testResultAsString
print TestOutcomes.ToString(testResult)


Passed
Passed
 
B

Ben Finney

But it would be much nicer if I had a function to covert to string
as part of the TestOutcomes class. How would I implement this?
Click to expand...

Others have given ad hoc implementations that may do what you want.

I'd like to know if the Cheeseshop package 'enum' is useful to
you. Any constructive feedback would be appreciated.

<URL:http://cheeseshop.python.org/pypi/enum/>
 
B

Ben Finney

(Please preserve attribution lines so it's clear who wrote what.)
Looking at the documentation it looks excellent. But I don't
understand the 0.4.2 version number,
Click to expand...

Note the tag that says the "Development Status" is "Beta".
particularly when you refer to it as robust.
Click to expand...

I assume you're referring to the short description, "Robust enumerated
type support in Python".

That refers to the implemented type as robust, not the state of the
code. That is, the short description should be read as "Support, in
Python, for robust enumerated types". It's a description of the
package functionality.

If, of course, the state of the code is not robust, that's a bug that
needs to be fixed; but that's true for any package.
 
T

TheFlyingDutchman

(Please preserve attribution lines so it's clear who wrote what.)


Note the tag that says the "Development Status" is "Beta".


I assume you're referring to the short description, "Robust enumerated
type support in Python".

That refers to the implemented type as robust, not the state of the
code. That is, the short description should be read as "Support, in
Python, for robust enumerated types". It's a description of the
package functionality.

If, of course, the state of the code is not robust, that's a bug that
needs to be fixed; but that's true for any package.

--
\ "Try to become not a man of success, but try rather to become a |
`\ man of value." -Albert Einstein |
_o__) |
Ben Finney
Click to expand...

What is the difference between this version and the 1.0 version?
 
B

Ben Finney

TheFlyingDutchman said:
What is the difference between this version and the 1.0 version?
Click to expand...

I don't know yet, since my time machine is currently in for repairs.
 
T

TheFlyingDutchman

I don't know yet, since my time machine is currently in for repairs.

--
\ "If you ever reach total enlightenment while you're drinking a |
`\ beer, I bet it makes beer shoot out your nose." -- Jack Handey |
_o__) |
Ben Finney
Click to expand...

When you were developing your Enum module, how did you determine you
were at the 0.4.2 version as opposed to the 0.7.1 version or the 0.9.2
version?
 
B

Ben Finney

TheFlyingDutchman said:
I think not. 42% of it is alive and kicking as we speak.
Click to expand...

That's odd. Do you think some similar matchematical relationship
exists between Python version 2.4.4 and 3.0?

You've made the common error of reading a package version as though it
were a single number on a number line. That's not the customary
semantic, though: versions are interpreted as a tuple of distinct
integers.
When you were developing your Enum module, how did you determine you
were at the 0.4.2 version as opposed to the 0.7.1 version or the
0.9.2 version?
Click to expand...

I initially developed at version 0.0, meaning "major level 0, minor
level 0" — i.e., no releases at all.

Then, when the first "alpha" release was ready, I called it version
0.1, meaning "major level 0, minor level 1" — i.e. no major releases
yet, but the first minor release.

Then, a small patch needed to be made, and the resulting release was
version 0.1.1, meaning "major level 0, minor level 1, patch level 1" —
i.e. the first patch to version 0.1.

Eventually some extra features warranted a release of version 0.2,
meaning "major level 0, minor level 2" — i.e. the second minor release
with still no major releases. Implicit in this is "patch level 0",
i.e. no patch-level versions yet; the version could be called 0.2.0
and have the same meaning.

Each dot-separated integer is interpreted as a distinct level,
subordinate to the preceding one:

* Two versions with different major numbers can be expected to be
incompatible.

* If two versions have the same major number, one can expect only
minor feature differences.

* If two versions have the same major and minor number, one can
expect that they differ only in bug fixes or the like.

* Subsequent integers would imply even smaller differences at that
same level if all preceding numbers were the same.

Within a level, subsequent integers imply subsequent release times:
version 0.4.1 can only be released before 0.4.2. However, this is not
true across levels: a hypothetical version 0.2.7 could be released
before *or* after 0.4.2, if the author decides a patch to the (equally
hypothetical) version 0.2.6 is warranted.

As for a putative version 1.0, that will not be released until I
determine the package is functionally complete and warrants a first
major release. Depending on how much changes between now and then, it
may have most, some, or none of the code you see presently in version
0.4.2.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Similar Threads

Rock paper scissors in python with "algorithm" 1
adding class functionality, nested scoping 1
unittest.py patch: add skipped test functionality 0
Doctests and decorated methods don't get along 7
Case study: library class inheritance with property declarations 5
problem with weakref.proxy 5
TkInter: Problem with propagation of resize events through geometrymanager hierarchy? 2
Virtual Slicing 3

Members online

No members online now.
Total: 159 (members: 0, guests: 159)
Robots: 324

Forum statistics

Threads
474,432
Messages
2,571,680
Members
48,796
Latest member
Greg L.

Latest Threads

Top