Re: [Python-Dev] infinities
On 11/26/06, tomer filiba <[EMAIL PROTECTED]> wrote: > i found several places in my code where i use positive infinity > (posinf) for various things, i.e., > > > i like the concept, but i hate the "1e1" stuff... why not add > posint, neginf, and nan to the float type? i find it much more readable as: > > if limit < 0: > limit = float.posinf > > posinf, neginf and nan are singletons, so there's no problem with > adding as members to the type. There's no reason this has to be part of the float type. Just define your own PosInf/NegInf singletons and PosInfType/NegInfType classes, giving them the appropriate special methods. NaN is a bit iffier, but in your case it's sufficient to raise an exception whenever it would be created. Consider submitting it to the Python Cookbook when you're done. ;) -- Adam Olsen, aka Rhamphoryncus ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python and the Linux Standard Base (LSB)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Phillip J. Eby napsal(a): > Just a suggestion, but one issue that I think needs addressing is the FHS > language that leads some Linux distros to believe that they should change > Python's normal installation layout (sometimes in bizarre ways) (...) > Other vendors apparently also patch Python in various > ways to support their FHS-based theories of how Python should install > files. +1 on that. There should be a clear (and clearly presented) idea of how Python is supposed to be laid out in the distribution-provided /usr hierarchy. And it would be nice if this idea complied to FHS. It would also be nice if somebody finally admitted the existence of /usr/lib64 and made Python aware of it ;e) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFFaupFjBrWA+AvBr8RArJcAKCGbeoih7TwKp2tBHtV3RMoY4JqvQCeJq87 +RgREnCI7DM/G5MNtjqmdVI= =WHpB -END PGP SIGNATURE- ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python and the Linux Standard Base (LSB)
At 02:38 PM 11/27/2006 +0100, Jan Matejek wrote: >-BEGIN PGP SIGNED MESSAGE- >Hash: SHA1 > >Phillip J. Eby napsal(a): > > Just a suggestion, but one issue that I think needs addressing is the FHS > > language that leads some Linux distros to believe that they should change > > Python's normal installation layout (sometimes in bizarre ways) (...) > > Other vendors apparently also patch Python in various > > ways to support their FHS-based theories of how Python should install > > files. > >+1 on that. There should be a clear (and clearly presented) idea of how >Python is supposed to be laid out in the distribution-provided /usr >hierarchy. And it would be nice if this idea complied to FHS. > >It would also be nice if somebody finally admitted the existence of >/usr/lib64 and made Python aware of it ;e) Actually, I meant that (among other things) it should be clarified that it's alright to e.g. put .pyc and data files inside Python library directories, and NOT okay to split them up. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PyFAQ: thread-safe interpreter operations
Way back on 11/22/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > Nick Coghlan schrieb: > > Martin v. Löwis wrote: > >> I personally consider it "good style" to rely on implementation details > >> of CPython; > > > > Is there a 'do not' missing somewhere in there? > > No - I really mean it. I can find nothing wrong with people relying on > reference counting to close files, for example. It's a property of > CPython, and not guaranteed in other Python implementations - yet it > works in a well-defined way in CPython. Code that relies on that feature > is not portable, but portability is only one goal in software > development, and may be irrelevant for some projects. It's not necessarily future-portable either. Having your software not randomly break over time is relevant for most nontrivial projects. > Similarly, it's fine when people rely on the C type "int" to have > 32-bits when used with gcc on x86 Linux. Relying on behavior that's implementation-defined in a particular way for a reason (like int being 32 bits on 32-bit hardware) is one thing. Relying on behavior that even the implementors might not be consciously aware of (or consider important to retain across versions) is another. -j ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PyFAQ: thread-safe interpreter operations
On Mon, Nov 27, 2006, Jason Orendorff wrote: > Way back on 11/22/06, "Martin v. L?wis" <[EMAIL PROTECTED]> wrote: >> Nick Coghlan schrieb: >>> Martin v. L?wis wrote: I personally consider it "good style" to rely on implementation details of CPython; >>> >>> Is there a 'do not' missing somewhere in there? >> >> No - I really mean it. I can find nothing wrong with people relying on >> reference counting to close files, for example. It's a property of >> CPython, and not guaranteed in other Python implementations - yet it >> works in a well-defined way in CPython. Code that relies on that feature >> is not portable, but portability is only one goal in software >> development, and may be irrelevant for some projects. > > It's not necessarily future-portable either. Having your software not > randomly break over time is relevant for most nontrivial projects. We recently had this discussion at my day job. We ended up agreeing that using close() was an encouraged but not required style, because to really avoid breakage we'd have to go with a full-bore try/except style for file handling, and that would require too many changes (especially without upgrading to 2.5, and we're still using 2.2/2.3). -- Aahz ([EMAIL PROTECTED]) <*> http://www.pythoncraft.com/ Usenet is not a democracy. It is a weird cross between an anarchy and a dictatorship. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PyFAQ: thread-safe interpreter operations
On 11/27/06, Aahz <[EMAIL PROTECTED]> wrote: > On Mon, Nov 27, 2006, Jason Orendorff wrote: > > Way back on 11/22/06, "Martin v. L?wis" <[EMAIL PROTECTED]> wrote: > >> [...] I can find nothing wrong with people relying on > >> reference counting to close files, for example. It's a property of > >> CPython, and not guaranteed in other Python implementations - yet it > >> works in a well-defined way in CPython. [...] > > > > [Feh.] > > We recently had this discussion at my day job. We ended up agreeing > that using close() was an encouraged but not required style, because to > really avoid breakage we'd have to go with a full-bore try/except style > for file handling, and that would require too many changes (especially > without upgrading to 2.5, and we're still using 2.2/2.3). Well, CPython's refcounting is something Python-dev is (understatement) very conscious of. I think I've even heard assurances that it won't change Any Time Soon. But this isn't the case for every CPython implementation detail. Remember what brought all this up. If it's obscure enough that Fredrik Lundh has to ask around, I wouldn't bet the ranch on it. -j ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Cloning threading.py using processes
Version 0.10 of the 'processing' package is available at the cheeseshop:
http://cheeseshop.python.org/processing
It is intended to make writing programs using processes almost the
same as writing
programs using threads. (By importing from 'processing.dummy' instead
of 'processing'
one can use threads with the same API.)
It has been tested on both Windows and Unix.
Shared objects are created on a 'manager' which runs in its own processes.
Communication with it happens using sockets or (on windows) named pipes.
An example where integers are sent through a shared queue from a child
process to
its parent:
. from processing import Process, Manager
.
. def f(q):
. for i in range(10):
. q.put(i*i)
. q.put('STOP')
.
. if __name__ == '__main__':
. manager = Manager()
. queue = manager.Queue(maxsize=10)
.
. p = Process(target=f, args=[queue])
. p.start()
.
. result = None
. while result != 'STOP':
. result = queue.get()
. print result
.
. p.join()
It has had some changes since the version I posted lasted month:
1) The use of tokens to identify shared objects is now hidden, so now
the API of
'processing' really is very similar to that of 'threading'.
2) It is much faster than before: on both Windows XP and Linux a manager serves
roughly 20,000 requests/second on a 2.5 Ghz Pentium 4. (Though it is
not a fair comparison that is 50-100 times faster than using
SimpleXMLRPCServer/xmlrpclib.)
3) The manager process just reuses the standard synchronization types from
threading.py, Queue.py and spawns a new thread to serve each process/thread
which owns a proxy. (The old version was single threaded and had a
select loop.)
4) Registering new shared types is straight forward, for instance
.from processing.manager import ProcessBaseManager
.
.class Foo(object):
.def bar(self):
.print 'BAR'
.
.class NewManager(ProcessBaseManager):
.pass
.
.NewManager.register('Foo', Foo, exposed=['bar'])
.
.if __name__ == '__main__':
.manager = NewManager()
.foo = manager.Foo()
.foo.bar() # => prints 'BAR'
Cheers
Richard
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Distribution tools: What I would like to see
Talin schrieb: > As far as rewriting it goes - I can only rewrite things that I understand. So if you want this to change, you obviously need to understand the entire distutils. It's possible to do that; some people have done it (the "understanding" part) - just go ahead and start reading source code. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python and the Linux Standard Base (LSB)
Phillip J. Eby schrieb: > Actually, I meant that (among other things) it should be clarified that > it's alright to e.g. put .pyc and data files inside Python library > directories, and NOT okay to split them up. My gut feeling is that this is out of scope for the LSB. The LSB would only specify what a confirming distribution should do, not what confirming applications need to do. But we will see. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python and the Linux Standard Base (LSB)
Jan Matejek schrieb: > +1 on that. There should be a clear (and clearly presented) idea of how > Python is supposed to be laid out in the distribution-provided /usr > hierarchy. And it would be nice if this idea complied to FHS. The LSB refers to the FHS, so it is clear that LSB support for Python will have follow the LHS. Specifically, LSB 3.1 includes FHS 2.3 as a normative reference. > It would also be nice if somebody finally admitted the existence of > /usr/lib64 and made Python aware of it ;e) I don't think this is really relevant for Python. The FHS specifies that 64-bit libraries must be in /lib64 on AMD64-Linux. It is silent on where to put Python source files and .pyc files, and, indeed, putting them into /usr/lib/pythonX.Y seems to be FHS-conforming: # /usr/lib includes object files, libraries, and internal binaries that # are not intended to be executed directly by users or shell scripts. In any case, changing Python is certainly out of the scope of the LSB committee: they might put requirements on Python installations, but it's not their job to "fix" Python. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Distribution tools: What I would like to see
On 11/27/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > Talin schrieb: > > As far as rewriting it goes - I can only rewrite things that I understand. > > So if you want this to change, you obviously need to understand the > entire distutils. It's possible to do that; some people have done > it (the "understanding" part) - just go ahead and start reading source > code. You (and Fredrik) are being a little harsh on Talin. I understand the need to encourage people to fix things themselves rather than just complaining about stuff they don't like. But people don't have an unlimited amount of time and expertise to work on several Python projects simultaneously. Nevertheless, they should be able to offer an "It would be good if..." suggestion without being stomped on. The suggestion itself can be a contribution if it focuses people's attention on a problem and a potential solution. Just because somebody can't learn a big subsystem and write code or docs for it *at this moment* doesn't mean they never will. And even if they don't, it's possible to make contributions in one area of Python and suggestions in another... or does the karma account not work that way? I don't see Talin saying, "You should fix this for me." He's saying, "I'd like this improved and I'm working on it, but it's a big job and I need help, ideally from someone with more expertise in distutils." Ultimately for Python the question isn't, "Does Talin want this done?" but, "Does this dovetail with the direction Python generally wants to go?" From what I've seen of setuptools/distutils evolution, yes, it's consistent with what many people want for Python. So instead of saying, "You (Talin) should take on this task alone because you want it" as if nobody else did, it would be better to say, "Thank you, Talin, for moving this important Python issue along." I've privately offered Talin some (unfinished) material I've been working on anyway that relates to his vision. When I get some other projects cleared away I'd like to put together that TOC of links I mentioned and perhaps collaborate on a Guide with whoever wants to. But I also need to learn more about setuptools before I can do that. As it happens I need the information anyway because I'm about to package an egg -- Mike Orr <[EMAIL PROTECTED]> ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Distribution tools: What I would like to see
Mike Orr wrote: > On 11/27/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: >> Talin schrieb: >>> As far as rewriting it goes - I can only rewrite things that I understand. >> So if you want this to change, you obviously need to understand the >> entire distutils. It's possible to do that; some people have done >> it (the "understanding" part) - just go ahead and start reading source >> code. > > You (and Fredrik) are being a little harsh on Talin. I understand the > need to encourage people to fix things themselves rather than just > complaining about stuff they don't like. But people don't have an > unlimited amount of time and expertise to work on several Python > projects simultaneously. Nevertheless, they should be able to offer > an "It would be good if..." suggestion without being stomped on. The > suggestion itself can be a contribution if it focuses people's > attention on a problem and a potential solution. Just because > somebody can't learn a big subsystem and write code or docs for it *at > this moment* doesn't mean they never will. And even if they don't, > it's possible to make contributions in one area of Python and > suggestions in another... or does the karma account not work that way? > > I don't see Talin saying, "You should fix this for me." He's saying, > "I'd like this improved and I'm working on it, but it's a big job and > I need help, ideally from someone with more expertise in distutils." > Ultimately for Python the question isn't, "Does Talin want this done?" > but, "Does this dovetail with the direction Python generally wants to > go?" From what I've seen of setuptools/distutils evolution, yes, it's > consistent with what many people want for Python. So instead of > saying, "You (Talin) should take on this task alone because you want > it" as if nobody else did, it would be better to say, "Thank you, > Talin, for moving this important Python issue along." > > I've privately offered Talin some (unfinished) material I've been > working on anyway that relates to his vision. When I get some other > projects cleared away I'd like to put together that TOC of links I > mentioned and perhaps collaborate on a Guide with whoever wants to. > But I also need to learn more about setuptools before I can do that. > As it happens I need the information anyway because I'm about to > package an egg > What you are saying is basically correct, although I have a slightly different spin on it. I've written a lot of documentation over the years, and I know that one of the hardest parts of writing documentation is trying to identify your own assumptions. To someone who already knows how the system works, its hard to understand the mindset of someone who is just learning it. You tend to unconsciously assume knowledge of certain things which a new user might not know. To that extent, it can be useful sometimes to have someone who is in the process of learning how to use the system, and who is willing to carefully analyze and write down their own experiences while doing so. Most of the time people are too busy to do this - they want to get their immediate problem solved, and they aren't interested in how difficult it will be for the next person. This is especially true in cases where the problem that is holding them up is three levels down from the level where their real goal is - they want to be able to "pop the stack" of problems as quickly as possible, so that they can get back to solving their *real* problem. So what I am offering, in this case, is my ignorance -- but a carefully described ignorance :) I don't demand that anyone do anything - I'm merely pointing out some things that people may or may not care about. Now, in this particular case, I have actually used distutils before. But distutils is one of those systems (like Perl) which tends to leak out of your brain if you don't use it regularly - that is, if you only use it once every 6 months, at the end of 6 months you have forgotten most of what you have learned, and you have to start the learning curve all over again. And I am in the middle of that re-learning process right now. What I am doing right now is creating a new extension project using setuputils, and keeping notes on what I do. So for example, I start by creating the directory structure: mkdir myproject cd myproject mkdir src mkdir test Next, create a minimal setup.py script. I won't include that here, but it's in the notes. Next, create the myproject.c file for the module in src/, and write the 'init' function for the module. (again, content omitted but it's in my notes). Create a projectname_unittest.py file in test. Add both of these to the setup.py file. At this point, you ought to be able to a "python setup.py test" and have it succeed. At this point, you can start adding types and methods, with a unit test for each one, testing each one as it is added. Now, I realize that all of this is "baby steps" to
