property confusion
Could someone please explain to me why the two values at the bottom of
this example are different?
Python-3.3 if it makes any difference.
Is this a difference in evaluation between a class attribute and an
instance attribute?
--rich
class C:
def __init__(self):
self._x = None
def getx(self):
print('getx')
return self._x
def setx(self, value):
print('setx')
self._x = value
def delx(self):
print('delx')
del self._x
x = property(getx, setx, delx, "I'm the 'x' property.")
class D:
def getx(self):
print('getx')
return self._x
def setx(self, value):
print('setx')
self._x = value
def delx(self):
print('delx')
del self._x
def __init__(self):
self._x = None
self.x = property(self.getx, self.setx, self.delx, "I'm the 'x'
property.")
type(C().x)
type(D().x)
--
https://mail.python.org/mailman/listinfo/python-list
Re: The devolution of English language and slothful c.l.p behaviors exposed!
On 1/25/12 12:14 , Rick Johnson wrote: You don't even need "pretty" to get your point across. If that's your argument, then we can drop the verb "to be", most articles, most verb conjugations, and nearly all adjectives and adverbs. For that matter, the vast majority of posts here can be dropped as they don't convey any new factual knowledge at all. Terseness isn't the only goal of language. --rich -- http://mail.python.org/mailman/listinfo/python-list
Re: The devolution of English language and slothful c.l.p behaviors exposed!
On 1/23/12 21:57 , Rick Johnson wrote: Here is a grep from the month of September 2011 showing the rampantly egregious misuse of the following words and phrases: * pretty * hard * right * used to * supposed to "Pretty" is the most ludicrous of them all! As you will see, "pretty" is used superfluously, over and over again! In fact, you could safely omit "pretty" without sacrificing any meaning of most all the sentences that include the word "pretty". Likewise, in 99% of the examples, the word "difficult" can be substituted for the word "hard" without sacrificing any meaning. Same for "correct" and "right". Of course, "used to" and "supposed to" will require people to rethink there lazy and slothful ways. I disagree on all points. "Pretty" means "mostly". The difference in meaning is significant. "I'm sure" is definitive. "I'm pretty sure" leaves room for variation. My dictionary lists "arduous" as the second, (of 17), definitions for "hard". etc. --rich -- http://mail.python.org/mailman/listinfo/python-list
Re: Is a with on open always necessary?
On 1/21/12 03:38 , Lie Ryan wrote: It is only strictly necessary for programs that opens thousands of files in a short while, since the operating system may limit of the number of active file handlers you can have. The number you're looking for is 20 on many unix systems. That's all. 20 concurrently open file descriptors. Modern systems open that number up somewhat, or make it tailorable. But the number is still much lower than you might expect. --rich -- http://mail.python.org/mailman/listinfo/python-list
Re: Is a with on open always necessary?
On 1/20/12 07:44 , Andrea Crotti wrote: I normally didn't bother too much when reading from files, and for example I always did a content = open(filename).readlines() But now I have the doubt that it's not a good idea, does the file handler stays open until the interpreter quits? So maybe doing a with open(filename) as f: contents = f.readlines() is always a better idea?? It's a better idea when possible. Sometimes the descriptor is opened in one method and closed in another. In that case, "with" isn't possible. --rich -- http://mail.python.org/mailman/listinfo/python-list
Re: stable object serialization to text file
On 1/11/12 12:16 , Máté Koch wrote: Hello All, I'm developing an app which stores the data in file system database. The data in my case consists of large python objects, mostly dicts, containing texts and numbers. The easiest way to dump and load them would be pickle, but I have a problem with it: I want to keep the data in version control, and I would like to use it as efficiently as possible. Is it possible to force pickle to store the otherwise unordered (e.g. dictionary) data in a kind of ordered way, so that if I dump a large dict, then change 1 tiny thing in it and dump again, the diff of the former and the new file will be minimal? If pickle is not the best choice for me, can you suggest anything else? (If there isn't any solution for it so far, I will write the module of course, but first I'd like to look around and make sure it hasn't been created yet.) Json kinda sucks. Try yaml. If your data is simple enough, you can just write and read your own format. Sort it first and you're golden. You might also try sorted dicts. I don't know if those will come out of pickle any differently than regular dicts, but it's worth trying. You can also write your own serializer for any of the previously mentioned serializers. If you sort during serialization, then they'll be sorted in the disk file. --rich -- http://mail.python.org/mailman/listinfo/python-list
Re: Two questions about logging
On 1/11/12 18:19 , Matthew Pounsett wrote:
Second, I'm trying to get a handle on how libraries are meant to
integrate with the applications that use them. The naming advice in
the advanced tutorial is to use __name__ to name loggers, and to allow
log messages to pass back up to the using application's logger for
processing, but these two pieces of advice seem contradictory.. since
log messages only pass back up to the root if the loggers are named
hierarchically.
Here's the confusion. Each log named __name__ is under the root logger.
If you want them all, then catch them all with the root logger.
In foo.py, change getLogger(__name__) to getLogger(''). Only the
included modules need __name__. Or use two - one logger for setting
handlers based on the root logger, and another based on __name__ for
logging from the top level.
--rich
--
http://mail.python.org/mailman/listinfo/python-list
Re: codecs in a chroot / without fs access
On 1/9/12 16:41 , Philipp Hagemeister wrote:
I want to forbid my application to access the filesystem. The easiest
way seems to be chrooting and droping privileges. However, surprisingly,
python loads the codecs from the filesystem on-demand, which makes my
program crash:
import os
os.getuid()
0
os.chroot('/tmp')
''.decode('raw-unicode-escape')
Traceback (most recent call last):
File "", line 1, in
(Interestingly, Python goes looking for the literal file "" in
sys.path. Wonder what happens if I touch
/usr/lib/python2.7/dist-packages/).
Is there a neat way to solve this problem, i.e. have access to all
codecs in a chroot?
The traditional solution is to copy the data you want to make available
into the subdirectory tree that will be used as the target of the chroot.
If not, I'd love to have a function codecs.preload_all() that does what
my workaround does:
import codecs,glob,os.path
encs = [os.path.splitext(os.path.basename(f))[0]
for f in glob.glob('/usr/lib/python*/encodings/*.py')]
for e in encs:
try:
codecs.lookup(e)
except LookupError:
pass # __init__.py or something
enumerate /usr/lib/python.*/encodings/*.py and call codecs.lookup for
every os.path.splitext(os.path.basename(filename))[0]
Dou you see any problem with this design?
Only the timing. If you're using the shell level chroot(1) program then
you're already chroot'd before this can execute. If you're using
os.chroot, then:
a) you're unix specific
b) your program must initially run as root
c) you have to drop privilege yourself rather than letting something
like chroot(1) handle it.
As alternatives, you might consider building a root file system in a
file and mounting it separately on a read-only basis. You can chroot
into that without much worry of how it will affect your regular file system.
With btrfs as root, you can create snapshots and chroot into those. You
can even mount them separately, read-only if you like, before chrooting.
The advantage of this approach is that the chroot target is built
"automatically" in the sense that it's a direct clone of your underlying
root file system, without allowing anything in the underlying root file
system to be altered. Files can be changed, but since btrfs is
copy-on-write, only the files in the snapshot will be changed.
--rich
--
http://mail.python.org/mailman/listinfo/python-list
socketserver question
Once I've instantiated my server class, along with a handler class, called server.serve_forever(), handler.handle() has been called, I've done my work, and I'm ready to shut the whole thing down... How do I do that? The doc says server.shutdown(), but if I call self.server.shutdown() from within handler.handle(), I seem to get a deadlock, which is exactly what I'd expect in a single threaded system with no way to "signal" the server.server_forever() loop which is several frames up the stack. I've also tried sys.exit() but it seems that the server object is catching that as an exception. How is this expected to work? How do I terminate the server.serve_forever() loop? --rich -- http://mail.python.org/mailman/listinfo/python-list
Re: help me get excited about python 3
You get some of the good stuff by importing future, unicode literals which essentially means you're working in unicode by default most of the time, and print function, (a small fix but long overdue). I try to write python3 whenever I can. It's rare that dependencies keep me back. More often it's debugger problems or lack of distributions, (python3 doesn't entirely build on MacOsX Lion and the distributed binaries can't download third party code that requires compilation). If you do anything with raw data, the bytes/unicode upgrades are a god send. The old way was workable, (although I still don't understand string quoting). The new way is much better, more rational, easier to understand, more consistent, better documented, closer to intuitive expectations, and expressively clearer. Trying to find idioms that work for both is horrendous, though. Unicode rocks. This change alone is leading me to use python in many places where, in the past, I would have used /bin/sh for portability. Utf-8 file names, file names with spaces and other "special characters", and user entered data fields with diacriticals are all difficult to handle in /bin/sh, awkward in python2, but near trivial in python3. Classic classes are finally dead. Range now works like xrange used to. This is great, although a bit clumsy when trying to write for both 2 and 3 concurrently. In practice, most of the library changes are 1:1 renames, which are both worthwhile and easy enough to work with. Most of the other interesting features, (imo), have been backported to 2.7. Context managers, "with", str.format(), etc. I'm currently writing in both more or less concurrently most of the time, (can't afford to live without the debugger), and I'm really, REALLY looking forward to the day when I can drop the python2 idioms. I really hate adding crap to python3 clean code in order to backport support for python2. Really, the biggest win to 3, aside from the unicode/bytes change, is the fact that a lot of outdated stuff is finally getting flushed. IMO, it's not so much about the new features, (context managers are big, but have been backported), as it is about the lack of pollution from ancient ones. Many of the new changes are ramifications of these removals. --rich -- http://mail.python.org/mailman/listinfo/python-list
Re: Python3 on MacOsX Lion?
On 1/2/12 13:03 , Benjamin Kaplan wrote: On Mon, Jan 2, 2012 at 2:32 PM, K Richard Pixley wrote: Where would I look to find the current expected status of python3 on MacOsX Lion? The distributed binaries aren't capable of allowing extensions that use gcc. I can build the source naked, but then it lacks some libraries, notably, readline. Attempting to build the full Mac packages fails, even with the few tiny patches I used for 2.7.2. Is anyone working on this? Are there pre-release patches available? Should I be asking elsewhere? --rich -- Have you tried building through Macports? No, I haven't. Macports scares me. When I tried them, or fink, in the past, they rapidly polluted my boot disk and I didn't have any way to unpollute it other than reloading from scratch. In freebsd, netbsd, or any of the linux distributions, I can trivially create a virtual machine in about 20 minutes, screw with it as I like, and toss it in seconds. In modern linux, I can create a root file system with btrfs, snapshot, chroot to the snapshot and munge away. When I'm done, I can just toss the snapshot. (Can do snapshots in vmware too). If I screw up my boot drive in MacOsX, I'm in for hours of recovery time reloading from Time Machine. While that's a lot better than it used to be now that Time Machine is available, (reloading can now be done largely unattended), it's not a price I'm willing to pay in order to attempt to use Macports. --rich -- http://mail.python.org/mailman/listinfo/python-list
Python3 on MacOsX Lion?
Where would I look to find the current expected status of python3 on MacOsX Lion? The distributed binaries aren't capable of allowing extensions that use gcc. I can build the source naked, but then it lacks some libraries, notably, readline. Attempting to build the full Mac packages fails, even with the few tiny patches I used for 2.7.2. Is anyone working on this? Are there pre-release patches available? Should I be asking elsewhere? --rich -- http://mail.python.org/mailman/listinfo/python-list
Re: readline for mac python? (really, reproducing mac python packages)
On 1/1/12 19:04 , K Richard Pixley wrote: On 1/1/12 16:49 , K Richard Pixley wrote: I'm having trouble finding a reasonable python environment on mac. The supplied binaries, (2.7.2, 3.2.2), are built with old versions of macosx and are not capable of building any third party packages that require gcc. The source builds easily enough out of the box, (./configure --enable-framework && make && sudo make install), but when I do that, I end up with a python interpreter that lacks readline. How do I get readline involved? Or better... is there an instruction sheet somewhere on how to reproduce the python.org binary packages? --rich Bah. I just needed to dig a little deeper into the source. All the doc I wanted is in there. Well, partial victory. 2.7.2 builds. 3.2 doesn't. --rich -- http://mail.python.org/mailman/listinfo/python-list
Re: readline for mac python? (really, reproducing mac python packages)
On 1/1/12 16:49 , K Richard Pixley wrote: I'm having trouble finding a reasonable python environment on mac. The supplied binaries, (2.7.2, 3.2.2), are built with old versions of macosx and are not capable of building any third party packages that require gcc. The source builds easily enough out of the box, (./configure --enable-framework && make && sudo make install), but when I do that, I end up with a python interpreter that lacks readline. How do I get readline involved? Or better... is there an instruction sheet somewhere on how to reproduce the python.org binary packages? --rich Bah. I just needed to dig a little deeper into the source. All the doc I wanted is in there. --rich -- http://mail.python.org/mailman/listinfo/python-list
readline for mac python? (really, reproducing mac python packages)
I'm having trouble finding a reasonable python environment on mac. The supplied binaries, (2.7.2, 3.2.2), are built with old versions of macosx and are not capable of building any third party packages that require gcc. The source builds easily enough out of the box, (./configure --enable-framework && make && sudo make install), but when I do that, I end up with a python interpreter that lacks readline. How do I get readline involved? Or better... is there an instruction sheet somewhere on how to reproduce the python.org binary packages? --rich -- http://mail.python.org/mailman/listinfo/python-list
Re: Generating sin/square waves sound
On 12/29/11 23:17 , Paulo da Silva wrote: Hi, Sorry if this is a FAQ, but I have googled and didn't find any satisfatory answer. Is there a simple way, preferably multiplataform (or linux), of generating sinusoidal/square waves sound in python? Thanks for any answers/suggestions. I just posted on this elsewhere. Look for a thread titled: "Which library for audio playback ?" --rich -- http://mail.python.org/mailman/listinfo/python-list
Re: Which library for audio playback ?
On 12/29/11 05:55 , Jérôme wrote: I'm writing a small application that plays sound through the speakers. The sounds are juste sine waves of arbitrary frequency I create in the code, not sample .wav files. I didn't expect the choice for an audio library to be that complicated. There are several libraries, and none of them seems to be *the* reference. Searching the web, I found these resources : http://wiki.python.org/moin/Audio http://wiki.python.org/moin/PythonInMusic * I privileged ALSA to OSS as I read elsewhere that OSS is deprecated, or on its way to be. (And JACK is not widely installed, apart from specific applications (audio work).) * Then, I picked the alsaaudio library (http://pyalsaaudio.sourceforge.net/). I don't remember exactly why. I think the project had the most recent updates. I don't think any project claims to be (let alone aims at being) complete. I'm wondering if I made a sensible choice. There are other libraries, including the following two that are platform independent : * PyAudiere (http://pyaudiere.org/), OSS , not packaged for debian * PyAudio (http://people.csail.mit.edu/hubert/pyaudio/) What solution would you recommend ? Are there other criterions I should take into account ? Thanks. I made a similar survey of available libraries recently. I'm interested in MIDI also, though, primarily on mac. There doesn't seem to be any definitive audio library for linux, although several, (jack, oss, alsa), exist. (My impression is similar to yours, OSS is obsolete. Jack may be the better library technically, but is not as widely ported or available as ALSA.) There is a definitive library for both audio and MIDI on mac - core audio. There really aren't any competitors. There is also a definitive library for windows, although I don't use windows. It's the open source one with low latency that everyone in the professional world uses to replace windows because, (surprise!), windows isn't capable of coping. I have found python libraries for each of these, although some are very low level libraries, basically just wrapping something even lower. If anyone has done an integrated "full solution" for linux or mac, I didn't find it. The closest I found was PortMIDI and PortAudio which appear to have ports for all three platforms as well as one or two sets of python bindings and seem to be high enough level to be both useful and productive. The hard part there is that PortMIDI and PortAudio come in source, which requires a bit of hunting to track down prerequisites, etc. Please keep us posted as I'm chasing a similar problem. --rich -- http://mail.python.org/mailman/listinfo/python-list
Re: confused about __new__
On 12/27/11 12:34 , Ian Kelly wrote: On Tue, Dec 27, 2011 at 1:31 PM, K Richard Pixley wrote: On 12/27/11 10:28 , Ian Kelly wrote: On Tue, Dec 27, 2011 at 10:41 AM, K Richard Pixleywrote: The conceptual leap for me was in recognizing that a class is just an object. The best way, (imo, so far), to create a singleton in python is to use the class itself as the singleton rather than ever instantiating it. With a little work, you can even prevent it from ever being instantiated. I don't think that's actually possible: Python 3.2 (r32:88445, Feb 20 2011, 21:29:02) [MSC v.1500 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. class Foo: ... def __new__(cls): ... raise TypeError ... def __init__(self): ... raise TypeError ... type(object.__new__(Foo)) Try: class Foo(object): def __new__(cls): return cls Okay: Python 3.2 (r32:88445, Feb 20 2011, 21:29:02) [MSC v.1500 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. class Foo: ... def __new__(cls): ... return cls ... f1 = object.__new__(Foo) f2 = object.__new__(Foo) type(f1), type(f2) (,) f1 is f2 False I'm not seeing why you're using "object.__new__". With Foo(), it seems fine. r...@fuji-land.noir.com> python Python 2.7.2 (default, Dec 12 2011, 13:05:49) [GCC 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.1.00)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> class Foo(object): ... def __new__(cls): ... return cls ... >>> f1 = Foo() >>> f2 = Foo() >>> id(Foo) 4298515984 >>> id(f1) 4298515984 >>> id(f2) 4298515984 r...@fuji-land.noir.com> python3 Python 3.2.2 (default, Dec 26 2011, 15:03:08) [GCC 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.1.00)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> class Foo(object): ... def __new__(cls): ... return cls ... >>> f1 = Foo() >>> f2 = Foo() >>> id(f1) 4298841008 >>> id(f2) 4298841008 >>> f1.stuff = True >>> f2.stuff True >>> id(Foo) 4298841008 Are you trying to demonstrate that I haven't prevented you from instantiating Foo? If so, then I will cede that point. I certainly don't know enough about python internals just now to even claim to be capable of protecting a class from a hostile user. My guess is that short of a privileged/unprivileged split, or castrating the interpreter and locking you into it, such a protection would not be possible. My point was that I can indeed intercept common and convenient usage to create a lovely singleton semantic. I can't force you to use it. (Nor do I have any motivation to so do.) --rich -- http://mail.python.org/mailman/listinfo/python-list
Re: Python education survey
On 12/27/11 10:26 , Andrew Berg wrote: On 12/27/2011 11:59 AM, K Richard Pixley wrote: You'd do better to encourage eclipse, but setting that up isn't trivial either. IIRC, all I had to do to set up PyDev was copy a URL to Eclipse's "Install New Software" wizard, and have Eclipse download and install it. Extra steps are needed if a different implementation of Python (e.g. Jython) is needed, but other than that, the user only needs to specify a couple options (e.g. Python grammar version) at project creation time. This assumes that Python is already installed, but why wouldn't it be? You still need to match versions of PyDev to versions of Eclipse to versions of operating system to versions of other eclipse plugins. I spent a few days trying to get it together once and came to the conclusion that it was a much bigger effort than I was willing to commit to. You could create your own distribution of eclipse, but then you have that "only useful for python" problem again. AFAIK, Eclipse should always be good for Java unless you do some serious hacking. Depends on which versions of eclipse, java, os, other plugins, etc. If students are going to go anywhere else after this class, they're going to need to either be able to learn to switch editors or find an editor they can use more generally. There are a ton of editors that have syntax highlighting and other little features for many languages. Exactly. My preference is emacs but I'll admit that the learning curve there is pretty high by today's standards. (Whether it's worth the effort is a debatable point.) There are certainly many others. --rich -- http://mail.python.org/mailman/listinfo/python-list
Re: Python education survey
On 12/27/11 10:21 , Rick Johnson wrote: On Dec 27, 11:59 am, K Richard Pixley wrote: The problem is that IDLE is hard to set up. (I've never managed it and I'm a well seasoned veteran). Can you qualify that statement? Do you mean "difficult to set up on certain OS's"? Because for windows there is no difficulty. The distributed binaries haven't worked when I tried on any version of linux or macosx that I used. Attempting to build from source also failed. (I'm pretty much an anti-microsoft bigot). Everyone ends up writing some html eventually, for instance. most folks write more than just HTML! Ruby, Lisp, Perl, C, Java, etc. Dedicated computer folks and experimental tinkerers, yes, I concur. But even casual computer users eventually want to write html, or compose for a wiki and get annoyed when their 3 hours of work in a web browser test field are lost because they changed pages. --rich -- http://mail.python.org/mailman/listinfo/python-list
Re: confused about __new__
On 12/27/11 10:28 , Ian Kelly wrote: On Tue, Dec 27, 2011 at 10:41 AM, K Richard Pixley wrote: The conceptual leap for me was in recognizing that a class is just an object. The best way, (imo, so far), to create a singleton in python is to use the class itself as the singleton rather than ever instantiating it. With a little work, you can even prevent it from ever being instantiated. I don't think that's actually possible: Python 3.2 (r32:88445, Feb 20 2011, 21:29:02) [MSC v.1500 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. class Foo: ... def __new__(cls): ... raise TypeError ... def __init__(self): ... raise TypeError ... type(object.__new__(Foo)) Try: class Foo(object): def __new__(cls): return cls --rich -- http://mail.python.org/mailman/listinfo/python-list
Re: Python education survey
On 12/19/11 19:51 , Raymond Hettinger wrote: Do you use IDLE when teaching Python? If not, what is the tool of choice? If your goal is to quickly get new users up and running in Python, what IDE or editor do you recommend? I would: a) let the students pick their own editor. b) encourage emacs and use emacs as a reference editor. The problem is that IDLE is hard to set up. (I've never managed it and I'm a well seasoned veteran). And pretty much only good for python, I'd expect. You'd do better to encourage eclipse, but setting that up isn't trivial either. You could create your own distribution of eclipse, but then you have that "only useful for python" problem again. If students are going to go anywhere else after this class, they're going to need to either be able to learn to switch editors or find an editor they can use more generally. Everyone ends up writing some html eventually, for instance. Either way requires climbing a learning curve that would be difficult to justify for a single class. OTOH, there are binary emacs distributions for all systems you've mentioned. And they work. I'm an antimicrosoft bigot, but I think my answer is probably the same regardless of whether we know the OS the students will be using or not. --rich -- http://mail.python.org/mailman/listinfo/python-list
Re: confused about __new__
On 12/26/11 21:48 , Fredrik Tolf wrote: On Mon, 26 Dec 2011, K. Richard Pixley wrote: I don't understand. Can anyone explain? I'm also a bit confused about __new__. I'd very much appreciate it if someone could explain the following aspects of it: * The manual (<http://docs.python.org/reference/datamodel.html>) says that __new__ is "a static method (special-cased so you need not declare it as such)". What does "special-cased" mean? Apparently, for instance, in OP's case, Python did not automatically detect that it should not be bound as a method. * Is there any part of the manual that explains, holistically, the greater context of object instantiation into which __new__ fits? I can only find small parts of it spread around the documentation for __new__ and __init__, but no complete explanation of it. There are several things I'm wondering about, like what it means to call a type object at all; how methods, properties and the like are bound; how pickle can instantiate a class without calling __init__; when and whether __dict__ is created and a couple of other things. Is there a complete documentation of the process anywhere that I haven't managed to find? Everything I know about this stuff I got by reading the manual. Search for __init__ and you'll find a pretty complete description of how objects are created, how to perturb that process, how attributes are looked up, and how to perturb that process. At least, you do in both python 2 and python 3 current manuals, I think. The conceptual leap for me was in recognizing that a class is just an object. The best way, (imo, so far), to create a singleton in python is to use the class itself as the singleton rather than ever instantiating it. With a little work, you can even prevent it from ever being instantiated. The concept of a "factory" gets a little weird then, as a factory might return an instantiation of some class but it might instead return a class proper - perhaps even an automatically constructed class - which is a somewhat different sort of factory. Calling a type is a little bit different. Calling a class is how you initiate an instantiation of that class. Calling an instantiation leads to __call__, (which may or may not have much semantic meaning, depending on your class). It's the difference between C() and C()(). (And the analogy holds for other builtin types, I think). Super() is also fairly well documented. But __metaclass__ could use a few more examples, imo. I'm still not entirely clear on __metaclass__. As I understand it, (which may well be completely wrong), __metaclass_ is the means of perturbing the results of "isinstance". You can create, (or delete), inheritance arbitrarily, and without even requiring real, existing classes to do it. I'm not clear on why you'd want to do this, nor why __metaclass__ is a better mechanism than, say, any of the implementations of "interface" which have been done in various tool kits or "mixins", which all seem to be somewhat overlapping in functionality. --rich -- http://mail.python.org/mailman/listinfo/python-list
Re: confused about __new__
On 12/26/11 20:53 , Steven D'Aprano wrote: On Mon, 26 Dec 2011 20:28:26 -0800, K. Richard Pixley wrote: I'm confused about the following. The idea here is that the set of instances of some class are small and finite, so I'd like to create them at class creation time, then hijack __new__ to simply return one of the preexisting classes instead of creating a new one each call. I'm surprised it works in Python3. Try this in Python 2 instead: Foo.__new__ = staticmethod(__Foo__new__) Excellent. Thank you. --rich -- http://mail.python.org/mailman/listinfo/python-list
confused about __new__
I'm confused about the following. The idea here is that the set of instances of some class are small and finite, so I'd like to create them at class creation time, then hijack __new__ to simply return one of the preexisting classes instead of creating a new one each call. This seems to work in python3, but fails in python2 with: Foo(23) TypeError: unbound method __Foo__new__() must be called with Foo instance as first argument (got type instance instead) I don't understand. Can anyone explain? --rich class Foo(object): def __init__(self, val): self.val = val foos = [Foo(0), Foo(1)] def __Foo__new__(cls, val): if val & 0x1: return foos[0] else: return foos[1] Foo.__new__ = __Foo__new__ Foo(23) -- http://mail.python.org/mailman/listinfo/python-list
@property; @classmethod; def f()
Can anyone explain to me why this doesn't work? class Foo(object): @property @classmethod def f(cls): return 4 I mean, I think it seems to be syntactically clear what I'm trying to accomplish. What am I missing? --rich -- http://mail.python.org/mailman/listinfo/python-list
emacs, pdb, python3, ubuntu
Does anyone have this combination working? And if so, which version of ubuntu and what did you have to do to get it to work? --rich -- http://mail.python.org/mailman/listinfo/python-list
