On 5/23/2020 2:21 PM, Ralf M. wrote:
# Code of mod1.py #
import enum, mod2
class En(enum.Enum):
A = 1
B = 2
def main():
a = mod2.getA()
print("a is En.A:", a is En.A)
print("a:", repr(a), " En.A:", repr(En.A))
print("id(a), id(a.__class__)", id(a), id(a._
Richard Damon schreef op 23/05/2020 om 20:57:
On 5/23/20 2:21 PM, Ralf M. wrote:
Hello,
recently I wrote a small library that uses an Enum. That worked as
expected. Then I added a main() and if __name__ == "__main__" to make
it runable as script. Now Enum members that should be the same aren't
27;nets already.
According to Kushal's link:
The most interesting thing about Enum members is that they are singletons.
The only time using `==` is necessary is for mixed-Enums, such as IntEnum, and
you need to compare what could be an IntEnum member in code that could be using
actual `int`s.
On Sun, May 24, 2020 at 5:58 AM Kushal Kumaran wrote:
>
> "Ralf M." writes:
>
> > Below are a simplified code sample, the results when I run it and my
> > thoughts.
> >
> > # Code of mod1.py #
> > import enum, mod2
> > def main():
> > a = mod2.getA()
> > # End of mod1.py #
> >
f the import and
> another, different instance of En and its members is created.
>
> How do I have to change mod1.py to avoid the problem?
> Currently I have moved main() into a new file script.py. That works,
> but is not what I wanted.
>
I think of circular dependencies as a cod
Peter Otten wrote:
>> # Code of mod2.py #
> import __main__ as mod1
>> def getA():
>>return mod1.En.A
>> # End of mod2.py #
>
> but that would hardcode the assumption that __main__ is always mod1.py.
I should have mentioned the cyclic dependency -- if two modules import each
oth
Richard Damon writes:
> On 5/23/20 2:21 PM, Ralf M. wrote:
>> Hello,
>>
>> recently I wrote a small library that uses an Enum. That worked as
>> expected. Then I added a main() and if __name__ == "__main__" to make
>> it runable as script. Now Enum members that should be the same aren't
>> identi
Ralf M. wrote:
> Hello,
>
> recently I wrote a small library that uses an Enum. That worked as
> expected. Then I added a main() and if __name__ == "__main__" to make it
> runable as script. Now Enum members that should be the same aren't
> identical any more, there seem to be two instances of th
On 5/23/20 2:21 PM, Ralf M. wrote:
> Hello,
>
> recently I wrote a small library that uses an Enum. That worked as
> expected. Then I added a main() and if __name__ == "__main__" to make
> it runable as script. Now Enum members that should be the same aren't
> identical any more, there seem to be t
Hello,
recently I wrote a small library that uses an Enum. That worked as
expected. Then I added a main() and if __name__ == "__main__" to make it
runable as script. Now Enum members that should be the same aren't
identical any more, there seem to be two instances of the same Enum.
I think I
On 2019-07-29 03:59, Cameron Simpson wrote:
On 29Jul2019 10:15, Chris Angelico wrote:
On Mon, Jul 29, 2019 at 10:06 AM Richard Damon wrote:
When talking of empty strings, we need to look a bit at context. "The
empty string" implies that there is only one of them, and if we are
talking about
On 29Jul2019 10:15, Chris Angelico wrote:
On Mon, Jul 29, 2019 at 10:06 AM Richard Damon wrote:
When talking of empty strings, we need to look a bit at context. "The
empty string" implies that there is only one of them, and if we are
talking about values, then there is only one empty string v
On 28Jul2019 20:11, Richard Damon wrote:
On 7/28/19 11:13 AM, MRAB wrote:
On 2019-07-28 13:30, Cameron Simpson wrote:
The collection is "the things". "all" qualifies it, versus, say,
"some of the things" or "the first of the things" etc.
[snip]
It's strange that "all the things" (meaning "a
On Mon, Jul 29, 2019 at 10:06 AM Richard Damon wrote:
> When talking of empty strings, we need to look a bit at context. "The
> empty string" implies that there is only one of them, and if we are
> talking about values, then there is only one empty string values, so
> "The empty string value" wou
On 7/28/19 11:13 AM, MRAB wrote:
> On 2019-07-28 13:30, Cameron Simpson wrote:
>>
>> The collection is "the things". "all" qualifies it, versus, say, "some
>> of the things" or "the first of the things" etc.
>>
> [snip]
>
> It's strange that "all the things" (meaning "all of the things") is
> OK, b
On 7/28/19 7:04 PM, Chris Angelico wrote:
> On Sun, Jul 28, 2019 at 5:36 PM Marko Rauhamaa wrote:
>> So it depends on the context if the relevant equivalence is "is" or
>> "==". Maybe the rule of thumb is that if we are talking about strings,
>> integers and similar things, we should think about i
On 2019-07-29 00:04, Chris Angelico wrote:
On Sun, Jul 28, 2019 at 5:36 PM Marko Rauhamaa wrote:
So it depends on the context if the relevant equivalence is "is" or
"==". Maybe the rule of thumb is that if we are talking about strings,
integers and similar things, we should think about it from
On Sun, Jul 28, 2019 at 5:36 PM Marko Rauhamaa wrote:
> So it depends on the context if the relevant equivalence is "is" or
> "==". Maybe the rule of thumb is that if we are talking about strings,
> integers and similar things, we should think about it from the point of
> view of Python's data mod
On 28/07/2019 17:13, MRAB wrote:
> [snip]
>
> It's strange that "all the things" (meaning "all of the things") is OK,
> but otherwise it's "one of the things", "some of the things", etc.
Is it?
It's the same in French, Dutch and German. Can't tell if it just makes
sense or if it's Common Average
On 2019-07-28 13:30, Cameron Simpson wrote:
On 28Jul2019 10:32, Peter Otten <__pete...@web.de> wrote:
Chris Angelico wrote:
When talking about indistinguishable objects, is it correct to talk
about "the " or "an "?
Example:
def f(s):
"""Frob a thing.
If s is an empty string, frobs a
On 27/07/2019 17.43, Stefan Ram wrote:
> Terry Reedy writes:
>> In mathematics, *every* set is 'the'.
This is correct, at least in ZF, where the Axiom of Extensionality says
that (in English) if A and B have exactly the same elements, they are
the same set.
> |Example 2 Let T be an non-empty s
On 28Jul2019 10:32, Peter Otten <__pete...@web.de> wrote:
Chris Angelico wrote:
When talking about indistinguishable objects, is it correct to talk
about "the " or "an "?
Example:
def f(s):
"""Frob a thing.
If s is an empty string, frobs all the things.
OR
If s is the empty s
Chris Angelico wrote:
> When talking about indistinguishable objects, is it correct to talk
> about "the " or "an "?
>
> Example:
>
> def f(s):
> """Frob a thing.
>
> If s is an empty string, frobs all the things.
> OR
> If s is the empty string, frobs all the things.
> """
Ethan Furman :
> On 07/27/2019 02:10 PM, Chris Angelico wrote:
>> When talking about indistinguishable objects, is it correct to talk
>> about "the " or "an "?
>
> Multiple indistinguishable objects are still multiple, so "an".
>
> Implementation details should only enter the conversation when
> s
On 28/07/19 9:10 AM, Chris Angelico wrote:
When talking about indistinguishable objects, is it correct to talk
about "the " or "an "?
Example:
def f(s):
"""Frob a thing.
If s is an empty string, frobs all the things.
OR
If s is the empty string, frobs all the things.
"""
On 7/27/2019 5:10 PM, Chris Angelico wrote:
When talking about indistinguishable objects, is it correct to talk
about "the " or "an "?
Example:
def f(s):
"""Frob a thing.
If s is an empty string, frobs all the things.
OR
If s is the empty string, frobs all the things.
Am 27.07.2019 um 23:10 schrieb Chris Angelico:
> When talking about indistinguishable objects, is it correct to talk
> about "the " or "an "?
>
> Example:
>
> def f(s):
> """Frob a thing.
>
> If s is an empty string, frobs all the things.
> OR
> If s is the empty string, frobs al
On 07/27/2019 02:10 PM, Chris Angelico wrote:
When talking about indistinguishable objects, is it correct to talk
about "the " or "an "?
Multiple indistinguishable objects are still multiple, so "an".
Implementation details should only enter the conversation when specifically
discussing the
On 28Jul2019 07:10, Chris Angelico wrote:
When talking about indistinguishable objects, is it correct to talk
about "the " or "an "?
Example:
def f(s):
"""Frob a thing.
If s is an empty string, frobs all the things.
OR
If s is the empty string, frobs all the things.
"""
It's e
When talking about indistinguishable objects, is it correct to talk
about "the " or "an "?
Example:
def f(s):
"""Frob a thing.
If s is an empty string, frobs all the things.
OR
If s is the empty string, frobs all the things.
"""
It's entirely possible that a Python implement
In article <[EMAIL PROTECTED]>,
Craig Allen <[EMAIL PROTECTED]> wrote:
>
>(option 2)
>Therefore option two is a family of options where class level members
>can be used to share whatever needs to be shared, though strictly the
>class is not a singleton since multiple instances are created which
>m
; so let me ask it here. It's about how to approach making singletons.
>
> Hi Craig,
> This might be good for a general background on Design Patters in
> Python:
>
> http://uk.youtube.com/watch?v=0vJJlVBVTFg
>
> - Paddy.
thanks for the link paddy, I'll watch it.
--
http://mail.python.org/mailman/listinfo/python-list
On Jul 16, 11:20 pm, Craig Allen <[EMAIL PROTECTED]> wrote:
> Hey, forgive me for just diving in, but I have a question I was
> thinking of asking on another list but it really is a general question
> so let me ask it here. It's about how to approach making singletons.
Hi
In message
<[EMAIL PROTECTED]>, Craig
Allen wrote:
> On Jul 16, 7:01 pm, Lawrence D'Oliveiro <[EMAIL PROTECTED]
> central.gen.new_zealand> wrote:
>>
>> >>> class TehLibrary(object) :
>>
>> ... @classmethod
>> ... def __new__(self, cls) :
>> ... return self
>>
>> >>> s = TehLibrary(
On Jul 17, 2:15 am, Uwe Schmitt <[EMAIL PROTECTED]>
wrote:
> On 17 Jul., 00:20, Craig Allen <[EMAIL PROTECTED]> wrote:
>
>
>
> > I have several classes in our system which need to act like
> > singletons, they are libraries of data classifications, and other
On 17 Jul., 00:20, Craig Allen <[EMAIL PROTECTED]> wrote:
>
> I have several classes in our system which need to act like
> singletons, they are libraries of data classifications, and other such
> libraries of configurations for the system which need to be global.
> ...
&g
On Jul 16, 7:01 pm, Lawrence D'Oliveiro <[EMAIL PROTECTED]
central.gen.new_zealand> wrote:
> In message
> <[EMAIL PROTECTED]>, Craig
>
> Allen wrote:
> > ... the ideal is still that
>
> > tl = TehLibrary() would always return the same object.
> >> class TehLibrary(object) :
>
> ... @classmethod
On Jul 16, 6:20 pm, Craig Allen <[EMAIL PROTECTED]> wrote:
> Anyone have any comments? Is there anything wrong, evil, or ugly
> about using a module this way, or am I correct to think that actually,
> this is a common approach in python.
>
> Is it pythonic?
The one drawback to this is that it co
In message
<[EMAIL PROTECTED]>, Craig
Allen wrote:
> ... the ideal is still that
>
> tl = TehLibrary() would always return the same object.
>> class TehLibrary(object) :
... @classmethod
... def __new__(self, cls) :
... return self
>>> s = TehLibrary()
>>> s == TehLibrary()
True
On Jul 17, 8:20 am, Craig Allen <[EMAIL PROTECTED]> wrote:
> Is it pythonic?
You probably can't get anymore pythonic than something written by the
BDFL. In describing the use of __new__ in Unifying types and
classes in Python 2.2 he gives this recipe for a Singleton.
class Singleton(object):
t; > thinking of asking on another list but it really is a general question
> > so let me ask it here. It's about how to approach making singletons.
> > Background: I've been programming in python seriously for about a year
> > now, maybe a little longer depending ho
On Jul 16, 5:20 pm, Craig Allen <[EMAIL PROTECTED]> wrote:
> Hey, forgive me for just diving in, but I have a question I was
> thinking of asking on another list but it really is a general question
> so let me ask it here. It's about how to approach making singletons.
>
Hey, forgive me for just diving in, but I have a question I was
thinking of asking on another list but it really is a general question
so let me ask it here. It's about how to approach making singletons.
Background: I've been programming in python seriously for about a year
now, mayb
On Thu, 06 Mar 2008 06:30:41 -0800, Carl Banks wrote:
> On Mar 5, 8:44 pm, Steven D'Aprano <[EMAIL PROTECTED]
> cybersource.com.au> wrote:
>> But what about classes? Are they singletons? Obviously classes aren't
>> Singleton classes, that is, given an arbitrary
En Thu, 06 Mar 2008 20:45:09 -0200, <[EMAIL PROTECTED]> escribi�:
> I'd like to question the source of the definition of C.__eq__.
>
> Observation:
>
class C: pass
> ...
class D: pass
> ...
C== D
> False
>
> What is different about them? I've created two empty classes, nothing
> mo
On Mar 6, 3:24 pm, [EMAIL PROTECTED] (Aahz) wrote:
> In article <[EMAIL PROTECTED]>,
> Steven D'Aprano <[EMAIL PROTECTED]> wrote:
>
>
>
> >I accept my question about classes being singletons is not well-formed,
> >not even in my own mind. I guess one wa
On Mar 6, 2:57 pm, Marc 'BlackJack' Rintsch <[EMAIL PROTECTED]> wrote:
> On Thu, 06 Mar 2008 11:06:50 -0800, castironpi wrote:
> > On Mar 6, 8:30 am, Carl Banks <[EMAIL PROTECTED]> wrote:
> >> Anyway, the answer to what you are probably asking is No. Try this:
>
> >> >>>import module
> >> >>>c1 =
In article <[EMAIL PROTECTED]>,
Steven D'Aprano <[EMAIL PROTECTED]> wrote:
>
>I accept my question about classes being singletons is not well-formed,
>not even in my own mind. I guess one way of asking is, for any two class
>objects (not instances) C1 and C2, do
On Thu, 06 Mar 2008 11:06:50 -0800, castironpi wrote:
> On Mar 6, 8:30 am, Carl Banks <[EMAIL PROTECTED]> wrote:
>> Anyway, the answer to what you are probably asking is No. Try this:
>>
>> >>>import module
>> >>>c1 = module.Someclass
>> >>>reload(module)
>> >>>c2 = module.Someclass
>> >>>c1 is c
On Mar 6, 8:30 am, Carl Banks <[EMAIL PROTECTED]> wrote:
> On Mar 5, 8:44 pm, Steven D'Aprano <[EMAIL PROTECTED]
>
> cybersource.com.au> wrote:
> > But what about classes? Are they singletons? Obviously classes aren't
> > Singleton classes, that is
On Mar 5, 8:44 pm, Steven D'Aprano <[EMAIL PROTECTED]
cybersource.com.au> wrote:
> But what about classes? Are they singletons? Obviously classes aren't
> Singleton classes, that is, given an arbitrary class C you can create
> multiple instances of C. But what about class
> I accept my question about classes being singletons is not well-formed,
> not even in my own mind. I guess one way of asking is, for any two class
> objects (not instances) C1 and C2, does "C1 == C2" imply "C1 is C2"?
C and D are instances of metaC in that.
cl
On Mar 5, 9:51 pm, [EMAIL PROTECTED] wrote:
> > > > If I understand your question, classes are not singletons:
> > > >>>> ll=[]
> > > >>>> for i in range(2):
> > > > import string
> > > > ll[i]=string
>
> > &g
> > > If I understand your question, classes are not singletons:
> > >>>> ll=[]
> > >>>> for i in range(2):
> > > import string
> > > ll[i]=string
>
> > Where's the IndexError? :-)
>
> > I accept my question a
On Mar 5, 8:31 pm, Steven D'Aprano <[EMAIL PROTECTED]
cybersource.com.au> wrote:
> On Wed, 05 Mar 2008 21:05:31 -0500, Terry Reedy wrote:
> > If I understand your question, classes are not singletons:
> >>>> ll=[]
> >>>> for i in range(2):
&g
Steven D'Aprano <[EMAIL PROTECTED]> writes:
> I recall that Python guarantees that module objects are singletons, and
> that this must hold for any implementation, not just CPython: you can
> only ever create one instance of a module via the import mechanism. But
> my
On Wed, 05 Mar 2008 21:05:31 -0500, Terry Reedy wrote:
> If I understand your question, classes are not singletons:
>>>> ll=[]
>>>> for i in range(2):
> import string
> ll[i]=string
Where's the IndexError? :-)
>>>> ll[0] is ll[1]
> True
"Steven D'Aprano" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
|I recall that Python guarantees that module objects are singletons, and
| that this must hold for any implementation, not just CPython: you can
| only ever create one instance of a module via the
I recall that Python guarantees that module objects are singletons, and
that this must hold for any implementation, not just CPython: you can
only ever create one instance of a module via the import mechanism. But
my google-foo is obviously weak today, I cannot find where the Python
language
Alan asked:
> > 2. If I really want a value True will I ever go astray with the test:
> > if a is True:
> > >>> a = True
> > >>> b = 1.
> > >>> c = 1
> > >>> a is True, b is True, c is True
> > (True, False, False)
"Ziga Seilnacht" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> I th
Em Sáb, 2006-03-25 às 09:11 -0800, Ziga Seilnacht escreveu:
> Python has a special internal list of integers in which it caches
> numbers smaller than 1000 (I'm not sure that the number is correct),
> but that is an implementation detail and you should not rely on it.
By testing:
>>> a = 10
>>> b
David Isaac wrote:
> "Ziga Seilnacht" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
> > >>> a = 1
> > >>> b = 1
> > >>> a == b
> > True
> > >>> a is b
> > False
>
> Two follow up questions:
>
> 1. I wondered about your example,
> and noticed
> >>> a = 10
> >>> b = 10
> >>> a
y with the test:
> if a is True:
> >>> a = True
> >>> b = 1.
> >>> c = 1
> >>> a is True, b is True, c is True
> (True, False, False)
>
None, True, and False are all singletons and should be compared with
"is". There are some ot
"Ziga Seilnacht" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> >>> a = 1
> >>> b = 1
> >>> a == b
> True
> >>> a is b
> False
Two follow up questions:
1. I wondered about your example,
and noticed
>>> a = 10
>>> b = 10
>>> a is b
True
Why the difference?
2. If I really w
Steven Watanabe wrote:
> PEP 8 says, "Comparisons to singletons like None should always be done
> with 'is' or 'is not', never the equality operators." I know that "is"
> is an identity operator, "==" and "!=" are the equality o
PEP 8 says, "Comparisons to singletons like None should always be done
with 'is' or 'is not', never the equality operators." I know that "is"
is an identity operator, "==" and "!=" are the equality operators, but
I'm not sure what o
66 matches
Mail list logo
