On 08/09/2017 03:39 PM, Ian Kelly wrote:
On Wed, Aug 9, 2017 at 2:20 PM, Ethan Furman wrote:
On 08/09/2017 12:59 PM, Ian Pilcher wrote:
I do want to prevent frozenset.__init__ from being called *again* when
an existing instance is returned, so I've decided to take this
approach:
def __
On Aug 9, 2017 4:39 PM, "Ian Kelly" wrote:
By the way, "whom" is not the verb object in "Whom do you think is
going to call", so it should properly be "who do you think is going to
call". I point this out because although I don't really care when
people use "who" incorrectly, it looks pretty si
On Wed, Aug 9, 2017 at 2:20 PM, Ethan Furman wrote:
> On 08/09/2017 12:59 PM, Ian Pilcher wrote:
>
>> I do want to prevent frozenset.__init__ from being called *again* when
>> an existing instance is returned, so I've decided to take this
>> approach:
>>
>> def __new__(cls, *args, **kwargs):
On 08/09/2017 12:59 PM, Ian Pilcher wrote:
I do want to prevent frozenset.__init__ from being called *again* when
an existing instance is returned, so I've decided to take this
approach:
def __new__(cls, *args, **kwargs):
self = super(UniqueSet, cls).__new__(cls, *args, **kwargs)
On 08/09/2017 07:54 AM, Steve D'Aprano wrote:
On Wed, 9 Aug 2017 10:08 am, Ian Pilcher wrote:
I have created a class to provide a "hash consing"[1] set.
Your footnote for [1] appears to be missing. What's a hash consing set? It
appears to be nothing more than frozen sets which you put in a ca
On 08/08/2017 10:19 PM, Ian Kelly wrote:
It's initialized by the superclass call to __new__. frozenset is
immutable, and __init__ methods of immutable types generally don't do
anything (if they could, then they wouldn't be immutable), which is
why it doesn't really matter that you didn't call it.
On Thu, 10 Aug 2017 12:39 am, Dennis Lee Bieber wrote:
> On Wed, 09 Aug 2017 22:54:00 +1000, Steve D'Aprano
> declaimed the following:
>
>>Its not just frozenset. Any mutable class must initialise its instances in
>>__new__. Immutable classes can use either __new__ or __init__, but for
>>histori
On Wed, 9 Aug 2017 10:08 am, Ian Pilcher wrote:
> I have created a class to provide a "hash consing"[1] set.
Your footnote for [1] appears to be missing. What's a hash consing set? It
appears to be nothing more than frozen sets which you put in a cache so as to
confuse identity and value *wink*
Ian Pilcher wrote:
> I have created a class to provide a "hash consing"[1] set.
>
>class UniqueSet(frozenset):
>
>_registry = dict()
>
>def __new__(cls, *args, **kwargs):
>set = frozenset(*args, **kwargs)
>try:
>return UniqueSet._regis
On Tue, Aug 8, 2017 at 6:08 PM, Ian Pilcher wrote:
> I have created a class to provide a "hash consing"[1] set.
>
> class UniqueSet(frozenset):
>
> _registry = dict()
>
> def __new__(cls, *args, **kwargs):
> set = frozenset(*args, **kwargs)
> try:
>
On Thu, 12 Mar 2015 22:04:30 +1100, Steven D'Aprano
wrote:
>
>3-4 seconds to instantiate is a bit worrying, but you should look at
>improving the efficiency of loading a map rather than insisting that there
>should be only one map instance. Particularly in the map editor, what if
>the user wants
On Thu, 12 Mar 2015 21:41:16 +1300, Gregory Ewing
wrote:
>Mario Figueiredo wrote:
>> But PyCharm flags the assignment
>> with a warning telling me that generate() does not return anything and
>> the I lose code completion on the mmap variable.
>
>My guess is that there is a syntax error somewhere
On Thu, 12 Mar 2015 22:29:24 +1100, Steven D'Aprano
wrote:
>
>I would have a loadfile() method which takes a filename on disk, opens the
>file and passes the contents (or the open file object) to another method,
>load() to do the actual work:
>
>
>class Map:
>def __new__(cls, width, height, f
Mario Figueiredo wrote:
> On Thu, 12 Mar 2015 16:31:12 +1100, Steven D'Aprano
> wrote:
>
>>Mario Figueiredo wrote:
>>
>>
>>If this is supposed to be a singleton, you can't create more instances.
>>The point of a singleton that there is only one instance (or perhaps a
>>small number, two or three
Mario Figueiredo wrote:
> It's just a cheap global, since is ubiquitous throughout the entire
> application, does behave like a singleton, and is a bit too expensive
> to create. A full map in the main application takes 3 or 4 seconds to
> instantiate and occupies around 2 Mb of memory.
2MB is no
On Thu, 12 Mar 2015 21:40:03 +1300, Gregory Ewing
wrote:
>Mario Figueiredo wrote:
>
>> A different application, a map editor, needs to also instantiate an
>> object of the class Map. But in this case the map needs to either be
>> empty (if the user wants to create a new map), or loaded from the
>
On Thu, 12 Mar 2015 21:38:00 +1300, Gregory Ewing
wrote:
>
>I would just provide a function:
>
>_map = None
>
>def get_map():
>global _map
>if _map is None:
> _map = Map()
>return _map
>
>and document the fact that you shouldn't call Map()
>directly.
Oh, you are so right! Been
Mario Figueiredo wrote:
But PyCharm flags the assignment
with a warning telling me that generate() does not return anything and
the I lose code completion on the mmap variable.
My guess is that there is a syntax error somewhere
in your code that's confusing the IDE.
--
Greg
--
https://mail.pyt
Mario Figueiredo wrote:
A different application, a map editor, needs to also instantiate an
object of the class Map. But in this case the map needs to either be
empty (if the user wants to create a new map), or loaded from the
saved map file (if the user wants to edit an existing map).
Then yo
Mario Figueiredo wrote:
It's just a cheap global, since is ubiquitous throughout the entire
application, does behave like a singleton, and is a bit too expensive
to create. A full map in the main application takes 3 or 4 seconds to
instantiate and occupies around 2 Mb of memory.
There's nothin
On Wed, 11 Mar 2015 16:47:32 -0700, Ethan Furman
wrote:
>
>You're code is good.
Thanks for taking a weight off my shoulder.
>
> The only question is if you /really/ need a singleton -- and only
> you can answer that (although plenty of folks will tell you you
> don't ;) .
Yeah. I debated that
On Thu, 12 Mar 2015 16:31:12 +1100, Steven D'Aprano
wrote:
>Mario Figueiredo wrote:
>
>
>If this is supposed to be a singleton, you can't create more instances. The
>point of a singleton that there is only one instance (or perhaps a small
>number, two or three say). Why do you need two differen
Mario Figueiredo wrote:
> I'm fairly new to Python, so I don't know if the following is me
> abusing the programming language idioms, or simply a mistake of my IDE
> code inspection routine.
>
> I have a singleton Map class which is defined like so:
>
> class Map:
> _instance = None
> de
On 03/11/2015 04:33 PM, Mario Figueiredo wrote:
> The following code runs just fine. But PyCharm flags the assignment
> with a warning telling me that generate() does not return anything and
> the I lose code completion on the mmap variable.
>
> if __name__ == '__main__':
> mmap = Map.generat
macaronikazoo <[EMAIL PROTECTED]> writes:
> ok thansk - i will search again. i did try searching but didn't find
> anything relevant...
Here's a link to the thread on google groups:
http://groups.google.com/group/comp.lang.python/browse_thread/thread/7aff4eabc6182858
Unfortunately two threads
ok thansk - i will search again. i did try searching but didn't find
anything relevant...
--
http://mail.python.org/mailman/listinfo/python-list
macaronikazoo <[EMAIL PROTECTED]> writes:
> i'm having a hell of a time getting this to work. basically I want to
> be able to instantiate an object using either a list, or a string, but
> the class inherits from list.
>
> if the class is instantiated with a string, then run a method over it
> to
Rhamphoryncus wrote:
On Aug 4, 11:46 am, Ethan Furman <[EMAIL PROTECTED]> wrote:
Mel wrote:
Ethan Furman wrote:
Emile van Sebille wrote:
Ethan Furman wrote:
--> d25._int = (1, 5)
Python considers names that start with a leading underscore as internal
or private, and that abuse i
On Aug 4, 11:46 am, Ethan Furman <[EMAIL PROTECTED]> wrote:
> Mel wrote:
> > Ethan Furman wrote:
>
> >>Emile van Sebille wrote:
>
> >>>Ethan Furman wrote:
>
> --> d25._int = (1, 5)
>
> >>>Python considers names that start with a leading underscore as internal
> >>>or private, and that abuse
Mel wrote:
Ethan Furman wrote:
Emile van Sebille wrote:
Ethan Furman wrote:
--> d25._int = (1, 5)
Python considers names that start with a leading underscore as internal
or private, and that abuse is the burden of the abuser...
Is bytecodehacks still around? That was serious abuse :
Ethan Furman wrote:
> Emile van Sebille wrote:
>> Ethan Furman wrote:
>>> --> d25._int = (1, 5)
>>
>> Python considers names that start with a leading underscore as internal
>> or private, and that abuse is the burden of the abuser...
>> Is bytecodehacks still around? That was serious abuse
Calvin Spealman wrote:
[snip]
ask if you really feel the need to know.
I am. ;)
--
http://mail.python.org/mailman/listinfo/python-list
its a good point you make. if its not _technically_ immutable, why use
__new__ when __init__ would work just as fine? well, if it should be
treated as immutable, then we should do what we can to follow that,
even in internal code that knows otherwise. Besides, maybe down the
road, protections will
Emile van Sebille wrote:
Ethan Furman wrote:
--> d25._int = (1, 5)
Python considers names that start with a leading underscore as internal
or private, and that abuse is the burden of the abuser...
Is bytecodehacks still around? That was serious abuse :)
Emile
Good point. What I'm
Ethan Furman wrote:
--> d25._int = (1, 5)
Python considers names that start with a leading underscore as internal
or private, and that abuse is the burden of the abuser...
Is bytecodehacks still around? That was serious abuse :)
Emile
--
http://mail.python.org/mailman/listinfo/python
James Stroud wrote:
> Hello All,
>
> I'm running 2.3.4
>
> I was reading the documentation for classes & types
>http://www.python.org/2.2.3/descrintro.html
> And stumbled on this paragraph:
>
> """
> __new__ must return an object. There's nothing that requires that it return a
> new obj
Peter Otten <[EMAIL PROTECTED]> wrote:
...
> is as __new__ had left it). Thus, for a new-style class C, the statement
> x=C(23) is equivlent to the following code:
>
> x = C.__new__(C, 23)
> if isinstance(x, C): C.__init__(x, 23)
...
> the "Nutshell" example should be changed to
>
>
James Stroud wrote:
> I'm running 2.3.4
>
> I was reading the documentation for classes & types
>http://www.python.org/2.2.3/descrintro.html
> And stumbled on this paragraph:
>
> """
> __new__ must return an object. There's nothing that requires that it
> return a new object that is an i
James Stroud The quote implies that when I call carol, b.__init__ should be called.
> However, this does not seem to be the case (see code below). What am I
> not
> understanding? Shouldn't the interpreter call b.__init__ when b is
> returned
> from carol.__new__?
>
> James
>
> py> class bo
Aahz wrote:
In article <[EMAIL PROTECTED]>,
Steven Bethard <[EMAIL PROTECTED]> wrote:
Yeah, I saw the same thing in playing around with this. Don't know
what to make of it. I wonder if we should file a documentation bug? I
can't find __new__ explained anywhere in the Language Reference. Can
do
In article <[EMAIL PROTECTED]>,
Steven Bethard <[EMAIL PROTECTED]> wrote:
>
>Yeah, I saw the same thing in playing around with this. Don't know
>what to make of it. I wonder if we should file a documentation bug? I
>can't find __new__ explained anywhere in the Language Reference. Can
>document
41 matches
Mail list logo
