Re: [Python-Dev] small floating point number problem
Smith [EMAIL PROTECTED] wrote:
I just ran into a curious behavior with small floating points, trying
to find the limits of them on my machine (XP). Does anyone know why the
'0.0' is showing up for one case below but not for the other? According
to my tests, the smallest representable float on my machine is much
smaller than 1e-308: it is
There are all sorts of ugly bits when working with all binary fp numbers
(for the small ones, look for a reference on 'denormals'). I'm sure that
Raymond has more than a few things to say about them (and fp in general),
but I will speed up the discussion by saying that you should read the
IEEE 754 standard for floating point, or alternatively ask on
comp.lang.python where more users would get more out of the answers that
you will recieve there.
One thing to remember is that decimal is not the native representation
of binary floating point, so 1e-100 differs from 1e-101 significantly in
various bit positions. You can use struct.pack('d', flt) to see this,
or you can try any one of the dozens of IEEE 754 javascript calculators
out there.
- Josiah
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] small floating point number problem
[Smith] I just ran into a curious behavior with small floating points, trying to find the limits of them on my machine (XP). Does anyone know why the '0.0' is showing up for one case below but not for the other? According to my tests, the smallest representable float on my machine is much smaller than 1e-308: it is 2.470328229206234e-325 but I can only create it as a product of two numbers, not directly. Here is an attempt to create the much larger 1e-308: a=1e-308 a 0.0 The clue is in that the two differ by 17 orders of magnitude (325-308) which is about 52 bits. The interpreter builds 1-e308 by using the underlying C library string-to-float function and it isn't constructing numbers outside the normal range for floats. When you enter a value outside that range, the function underflows it to zero. In contrast, your computed floats (such as 1*1e-307) return a denormal result (where the significand is stored with fewer bits than normal because the exponent is already at its outer limit). That denormal result is not zero and the C library float-to-string conversion successfully generates a decimal string representation. The asymmetric handling of denormals by the atof() and ftoa() functions is why you see a difference. A consequence of that asymmetry is the breakdown of the expected eval(repr(f))==f invariant: f = f = .1*1e-307 eval(repr(f)) == f False Raymond ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] threadsafe patch for asynchat
On Tue, Feb 07, 2006 at 08:53:46PM -0800, Bill Janssen wrote: Perhaps the right idea is to fix the various problems of asyncore. The problem with making asyncore more useful is that you end up with (a cut down version of) Twisted, although not one that would be able to integrate with Twisted. asyncore/asynchat and Twisted are really not that different, and anything you do to enhance the former will make it look more like the latter. I'd personally rather fork parts of Twisted, in spite of the maintenance issues, than re-invent Twisted, fix all the issues Twisted already solves and face the same kind of maintenance issues. It would be perfect if the twisted-light in the stdlib would integrate with the 'real' Twisted, so that users can 'upgrade' their programs just by installing Twisted and using the extra features. Not that I think we should stop at the event core and the TCP/SSL parts of Twisted; imaplib, poplib, httplib, xmlrpclib, for instance, could all do with Twisted-inspired alternatives (or even replacements, if the synchronous API was kept the same.) The synchronous versions are fine for simple scripts (or complex scripts that don't mind long blocking operations.) If we start exporting a really useful asynchronous framework, I would expect asynchronous counterparts to the useful higher-level networking modules, too. But that doesn't have to come right away ;) Anything beyond simple bugfixes on asyncore/asynchat seems like a terrible waste of effort, to me. And I hardly ever use Twisted. -- Thomas Wouters [EMAIL PROTECTED] Hi! I'm a .signature virus! copy me into your .signature file to help me spread! ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Old Style Classes Goiung in Py3K
Hello all, I understand that old style classes are slated to disappear in Python 3000. Does this mean that the following will be a syntax error : class Something: pass *or* that instead it will automatically inherit from object ? The latter would break a few orders of magnitude less code of course... All the best, Michael Foord http://www.voidspace.org.uk/python/index.shtml ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Make error on solaris 9 x86 - error: parse error before upad128_t
Hi, I am trying to build python-2.3.5 on solaris 9 - X86. 1) first I have unpacked : Python-2.3.5.tgz using : tar -zxvf Python-2.3.5.tgz no erros at this stage 2) then run : ./configure No errors at this stage 3)then /usr/ccs/bin/make it is giving some errors and the error is : gcc -c -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I./Include -DPy_BUILD_CORE -o Python/pythonrun.o Python/pythonrun.c In file included from /usr/include/sys/reg.h:13, from /usr/include/sys/regset.h:24, from /usr/include/sys/ucontext.h:21, from /usr/include/sys/signal.h:240, from /usr/include/signal.h:27, from Python/pythonrun.c:17: /usr/include/ia32/sys/reg.h:300: error: parse error before upad128_t /usr/include/ia32/sys/reg.h:302: error: parse error before '}' token /usr/include/ia32/sys/reg.h:309: error: field `kfpu_fx' has incomplete type /usr/include/ia32/sys/reg.h:314: confused by earlier errors, bailing out *** Error code 1 make: Fatal error: Command failed for target `Python/pythonrun.o' Can you please reply me with some fix for this problem. Regards -Raveendrababu ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Make error on solaris 9 x86 - error: parse errorbefore upad128_t
M, Raveendra Babu (STSD) wrote: 3)then /usr/ccs/bin/make it is giving some errors and the error is : gcc -c -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I./Include -DPy_BUILD_CORE -o Python/pythonrun.o Python/pythonrun.c In file included from /usr/include/sys/reg.h:13, from /usr/include/sys/regset.h:24, from /usr/include/sys/ucontext.h:21, from /usr/include/sys/signal.h:240, from /usr/include/signal.h:27, from Python/pythonrun.c:17: /usr/include/ia32/sys/reg.h:300: error: parse error before upad128_t /usr/include/ia32/sys/reg.h:302: error: parse error before '}' token /usr/include/ia32/sys/reg.h:309: error: field `kfpu_fx' has incomplete type /usr/include/ia32/sys/reg.h:314: confused by earlier errors, bailing out *** Error code 1 make: Fatal error: Command failed for target `Python/pythonrun.o' Can you please reply me with some fix for this problem. a quick google search indicates that this is a compiler problem. random FAQ entry: The problem is that the Solaris headers changed across updates of Solaris 9 and you are using a GCC from before the change on an updated system. (i.e. a GCC built for Solaris 9 = 12/03 on Solaris 9 = 4/04). You can either rebuild GCC for your version of the system (it works, even using a GCC built for the previous version), or fix your headers: http://groups.yahoo.com/group/solarisx86/message/6617 /F ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Let's just *keep* lambda
After so many attempts to come up with an alternative for lambda, perhaps we should admit defeat. I've not had the time to follow the most recent rounds, but I propose that we keep lambda, so as to stop wasting everybody's talent and time on an impossible quest. I agree with this. The *name* lambda is a wart, even if the deferred expression feature isn't. My preference is to simply replace the keyword lambda with a keyword expr (or if that's not acceptable because there's too much prior use of expr as a variable name, then maybe expression - but that's starting to get a bit long). Sorry, I'm a little late to this discussion. How about `procedure', or just `proc'? And to think that people thought that keeping lambda, but changing the name, would avoid all the heated discussion... :-) -Patrick ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Linking with mscvrt
Martin v. Löwis [EMAIL PROTECTED] writes: I just came up with an idea how to resolve the VC versioning problems for good: Python should link with mscvrt.dll (which is part of the operating system), not with the CRT that the compiler provides. To do that, we would need to compile and link with the SDK header files and import libraries, not with the ones that visual studio provides. For that to work, everyone building Python or Python extensions (*) would have to install the Platform SDK (which is available for free, but contains quite a number of bits). Would that be acceptable? Disclaimer: I haven't tried yet whether this would actually work. Regards, Martin (*) For Python extensions, it should be possible to use mingw instead, and configure it for linking against msvcrt. I think think would remove a lot of headaches. Downloading and installing the Platform SDK should not be an issue, imo. The only problem that I see is this: I'm not sure the platform SDK include files (.H and .IDL) are really compatible with VC7.1. I remember that we (on our company, building C++ software) had to 'Unregister the PSDK Directories with Visual Studio' (available from the start menu) before building the stuff, otherwise there were compiler errors. Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] threadsafe patch for asynchat
Josiah Carlson wrote: Fredrik Lundh [EMAIL PROTECTED] wrote: Steve Holden wrote: What is the reason that people want to use threads when they can have poll/select-style message processing? Why does Zope require threads? IOW, why would anybody *want* a threadsafe patch for asynchat? In case the processing of events needed to block? If I'm processing web requests in an async* dispatch loop and a request needs the results of a (probably lengthy) database query in order to generate its output, how do I give the dispatcher control again to process the next asynchronous network event? The usual answer is process the request in a thread. That way the dispatcher can spring to life for each event as quickly as needed. but why do such threads have to talk to asyncore directly ? Good question. Indeed. I seem to remember a discussion a few months ago about easy thread programming, which invariably directed people off to use the simplest abstractions necessary: Queues. Maybe people are finding Python too easy and they just want to complicate their code to the point where it contains interesting bugs? I dunno regards Steve -- Steve Holden +44 150 684 7255 +1 800 494 3119 Holden Web LLC www.holdenweb.com PyCon TX 2006 www.python.org/pycon/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] threadsafe patch for asynchat
On Wed, 2006-02-08 at 02:33 -0500, Steve Holden wrote: Martin v. Löwis wrote: Tim Peters wrote: [...] What is the reason that people want to use threads when they can have poll/select-style message processing? Why does Zope require threads? IOW, why would anybody *want* a threadsafe patch for asynchat? In case the processing of events needed to block? If I'm processing web requests in an async* dispatch loop and a request needs the results of a (probably lengthy) database query in order to generate its output, how do I give the dispatcher control again to process the next asynchronous network event? The usual answer is process the request in a thread. That way the dispatcher can spring to life for each event as quickly as needed. I believe that Twisted does pretty much this with it's deferred stuff. It shoves slow stuff off for processing in a separate thread that re-syncs with the event loop when it's finished. In the case of Zope/ZEO I'm not entirely sure but I think what happened was medusa (asyncore/asynchat based stuff Zope2 was based on) didn't have this deferred handler support. When they found some of the stuff Zope was doing took a long time, they came up with an initially simpler but IMHO uglier solution of running multiple async loops in separate threads and using a front-end dispatcher to distribute connections to them. This way it wasn't too bad if an async loop stalled, because the other loops in other threads could continue to process stuff. If ZEO is still using this approach I think switching to a twisted style approach would be a good idea. However, I suspect this would be a very painful refactor... -- Donovan Baarda [EMAIL PROTECTED] http://minkirri.apana.org.au/~abo/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] threadsafe patch for asynchat
Donovan Baarda wrote: On Wed, 2006-02-08 at 02:33 -0500, Steve Holden wrote: Martin v. Löwis wrote: Tim Peters wrote: [...] What is the reason that people want to use threads when they can have poll/select-style message processing? Why does Zope require threads? IOW, why would anybody *want* a threadsafe patch for asynchat? In case the processing of events needed to block? If I'm processing web requests in an async* dispatch loop and a request needs the results of a (probably lengthy) database query in order to generate its output, how do I give the dispatcher control again to process the next asynchronous network event? The usual answer is process the request in a thread. That way the dispatcher can spring to life for each event as quickly as needed. I believe that Twisted does pretty much this with it's deferred stuff. It shoves slow stuff off for processing in a separate thread that re-syncs with the event loop when it's finished. Argh! No. Threading is completely orthogonal to Deferreds. Deferreds are just an abstraction for managing callbacks for an asychronous operation. They don't magically invoke threads, or otherwise turn synchronous code into asynchronous code for you. This seems to be a depressingly common misconception. I wish I knew how to stop it. They're much simpler than people seem to think. They're an object a function returns to say I don't have a result for you yet, but if you attach callbacks to this I'll run those when I do. We've do this because it's much nicer than having to pass callbacks into functions, particularly when you want to deal with chains of callbacks and error handling. There is a single utility function in Twisted called deferToThread that will run a function in a threadpool, and arrange for a Deferred to be fired with the result (in the event loop thread, of course). This is just one of many possible uses for Deferreds, and not an especially common one. I'm happy to provide pointers to several Twisted docs if anyone is at all unclear on this. While they are very useful, I don't think they're an essential part of a minimal Twisted replacement for asyncore/asynchat -- in fact, they'd work just fine with asyncore/asynchat, because they do so little. -Andrew. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] _length_cue()
Hi all, Last september, the __len__ method of iterators was removed -- see discussion at: http://mail.python.org/pipermail/python-dev/2005-September/056879.html It was replaced by an optional undocumented method called _length_cue(), which would be used to guess the number of remaining items in an iterator, for performance reasons. I'm worried about the name. There are now exactly two names that behave like a special method without having the double-underscores around it. The first name is 'next', which is kind of fine because it's for iterator classes only and it's documented. But now, consider: the CPython implementation can unexpectedly invoke a method on a user-defined iterator class, even though this method's name is not '__*__' and not documented as special! That's new and that's bad. IMHO for safety reasons we need to stick double-underscores around this name too, e.g. __length_cue__(). It's new in 2.5 and not documented anyway so this change won't break anything. Do you agree with that? BTW the reason I'm looking at this is that I'm considering adding another undocumented internal-use-only method, maybe __getitem_cue__(), that would try to guess what the nth item to be returned will be. This would allow the repr of some iterators to display more helpful information when playing around with them at the prompt, e.g.: enumerate([3.1, 3.14, 3.141, 3.1415, 3.14159, 3.141596]) enumerate (0, 3.1), (1, 3.14), (2, 3.141),... length 6 A bientot, Armin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Linking with mscvrt
Martin v. Löwis [EMAIL PROTECTED] wrote: I just came up with an idea how to resolve the VC versioning problems for good: Python should link with mscvrt.dll (which is part of the operating system), not with the CRT that the compiler provides. Can you elaborate exactly on which versioning problems you think of? For that to work, everyone building Python or Python extensions (*) would have to install the Platform SDK (which is available for free, but contains quite a number of bits). Would that be acceptable? It would complicate the build process and make Python lag behind CRT development (including bugfixes and whatnot) that Microsoft does. You could as well ask to always stick with GCC 2.95 to solve ABI problems, but I don't think it's the correct long time solution. I expect more and more Windows libraries (binary version) to be shipped with dependencies on MSVCR71.DLL. Anyway, it's just a feeling, since I still don't understand which problems you are trying to solve in the first place. -- Giovanni Bajo ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] threadsafe patch for asynchat
On Wed, Feb 08, 2006 at 01:23:26PM +, Donovan Baarda wrote: I believe that Twisted does pretty much this with it's deferred stuff. It shoves slow stuff off for processing in a separate thread that re-syncs with the event loop when it's finished. Deferreds are only an elaborate way to deal with a bunch of callbacks. It's Twisted itself that provides a way to run something in a separate thread and then fire a deferred (from the main thread) when the child thread finishes (reactor.callInThread() to call stuff in a different thread, reactor.callFromThread() to call reactor APIs from a different thread) Deferreds are just a bit more than: class Deferred(object): def __init__(self): self.callbacks = [] def addCallback(self, callback): self.callbacks.append(callback) def callback(self, value): for callback in self.callbacks: value = callback(value) This is mostly what a deferred is (without error handling, extra argument passing, 'nested' deferreds handling and blabla, the core concept however is there). As you see there is no extra magic in deferreds (or weird dependency on Twisted, they are pure python and could be used everywhere, you can implement them in any language that supports first class functions). In the case of Zope/ZEO I'm not entirely sure but I think what happened was medusa (asyncore/asynchat based stuff Zope2 was based on) didn't have this deferred handler support. When they found some of the stuff Here I think you meant that medusa didn't handle computation in separate threads instead. -- Valentino Volonghi aka Dialtone Now Running MacOSX 10.4 Blog: http://vvolonghi.blogspot.com New Pet: http://www.stiq.it pgpMxTGEMNS2c.pgp Description: PGP signature ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Old Style Classes Goiung in Py3K
Fuzzyman wrote: Hello all, I understand that old style classes are slated to disappear in Python 3000. Does this mean that the following will be a syntax error : class Something: pass *or* that instead it will automatically inherit from object ? Of course, I would say. There's no reason to forbid this in Py3k. regards, Georg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] threadsafe patch for asynchat
On Wed, Feb 08, 2006, Thomas Wouters wrote: Anything beyond simple bugfixes on asyncore/asynchat seems like a terrible waste of effort, to me. And I hardly ever use Twisted. +1 -- Aahz ([EMAIL PROTECTED]) * http://www.pythoncraft.com/ 19. A language that doesn't affect the way you think about programming, is not worth knowing. --Alan Perlis ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Let's just *keep* lambda
On Wed, Feb 08, 2006, Patrick Collison wrote: How about `procedure', or just `proc'? -1 lambdas are *expected* to return a result -- procedures are functions with side-effects that don't return a result. -- Aahz ([EMAIL PROTECTED]) * http://www.pythoncraft.com/ 19. A language that doesn't affect the way you think about programming, is not worth knowing. --Alan Perlis ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] _length_cue()
On Wed, Feb 08, 2006, Armin Rigo wrote: IMHO for safety reasons we need to stick double-underscores around this name too, e.g. __length_cue__(). It's new in 2.5 and not documented anyway so this change won't break anything. Do you agree with that? +1 -- Aahz ([EMAIL PROTECTED]) * http://www.pythoncraft.com/ 19. A language that doesn't affect the way you think about programming, is not worth knowing. --Alan Perlis ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] small floating point number problem
On Wed, 08 Feb 2006 03:08:25 -0500, Raymond Hettinger [EMAIL PROTECTED] wrote: [Smith] I just ran into a curious behavior with small floating points, trying to find the limits of them on my machine (XP). Does anyone know why the '0.0' is showing up for one case below but not for the other? According to my tests, the smallest representable float on my machine is much smaller than 1e-308: it is 2.470328229206234e-325 but I can only create it as a product of two numbers, not directly. Here is an attempt to create the much larger 1e-308: a=1e-308 a 0.0 The clue is in that the two differ by 17 orders of magnitude (325-308) which is about 52 bits. The interpreter builds 1-e308 by using the underlying C library string-to-float function and it isn't constructing numbers outside the normal range for floats. When you enter a value outside that range, the function underflows it to zero. In contrast, your computed floats (such as 1*1e-307) return a denormal result (where the significand is stored with fewer bits than normal because the exponent is already at its outer limit). That denormal result is not zero and the C library float-to-string conversion successfully generates a decimal string representation. The asymmetric handling of denormals by the atof() and ftoa() functions is why you see a difference. A consequence of that asymmetry is the breakdown of the expected eval(repr(f))==f invariant: f = f = .1*1e-307 eval(repr(f)) == f False BTW, for the OP, chasing minimum float values is probably best done with powers of 2 math.ldexp(1, -1074) 4.9406564584124654e-324 math.ldexp(1, -1075) 0.0 .5**1074 4.9406564584124654e-324 .5**1075 0.0 math.frexp(.5**1074) (0.5, -1073) math.frexp(.5**1075) (0.0, 0) Regards, Bengt Richter ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] math.areclose ...?
Smith wrote: ... There is a problem with dividing by 'ave' if the x and y are at the floating point limits, but the symmetric behaving form (presented by Scott Daniels) will have the same problem. Upon reflection, 'max' is probably better than averaging, and avoiding divide is also a reasonably good idea. Note that relative_tol 1.0 (typically) so underflow, rather than overflow, is the issue: def nearby(x, y, relative_tol=1.e-5, absolute_tol=1.e-8): difference = abs(x - y) return (difference = absolute_tol or difference = max(abs(x), abs(y)) * relative_tol) I use =, since zero-tolerance should pass equal values. --Scott David Daniels [EMAIL PROTECTED] ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] threadsafe patch for asynchat
Neal Norwitz wrote: On 2/7/06, Christopher Armstrong [EMAIL PROTECTED] wrote: Twisted is wonderful, powerful, rich, and very large. Perhaps a small subset could be carefully extracted The subject of putting (parts of) Twisted into the standard library comes up once every 6 months or so, at least on our mailing list. For all that I think asyncore is worthless, I'm still against copying Twisted into the stdlib. Or at least I'm not willing to maintain the necessary fork, and I fear the nightmares about versioning that can easily occur when you've got both standard library and third party versions of a project. I wouldn't be enthusiastic about putting all of Twisted in the stdlib either. Twisted is on a different release schedule than Python. However, isn't there a relatively small core subset like Alex mentioned that isn't changing much? Could we split up those components and have those live in the core, but the vast majority of Twisted live outside as it does now? +1. This would be very useful for simple networking applications. Georg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Python modules should link to libpython
gjc:/usr/lib/python2.4/lib-dynload$ ldd itertools.so libpthread.so.0 = /lib/libpthread.so.0 (0x2abcc000) libc.so.6 = /lib/libc.so.6 (0x2ace2000) /lib/ld-linux-x86-64.so.2 (0x4000) gjc:/usr/lib/python2.4/lib-dynload$ It seems that Python C extension modules are not linking explicitly to libpython. Yet, they explicitly reference symbols defined in libpython. When libpython is loaded in a global scope all is fine. However, when libpython is dlopen()ed with the RTLD_LOCAL flag, python C extensions always get undefined symbols. This problem happened recently with the nautilus-python package, which installs an extension for the Nautilus file manager that allows extensions in Python. For performance reasons, it now opens extensions with RTLD_LOCAL flag, thus breaking python extensions. Any thoughts? Should I go ahead and open a bug report (maybe with patch), or is this controversial? -- Gustavo J. A. M. Carneiro [EMAIL PROTECTED] [EMAIL PROTECTED] The universe is always one step beyond logic. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] _length_cue()
I'm worried about the name. There are now exactly two names that behave like a special method without having the double-underscores around it. The first name is 'next', which is kind of fine because it's for iterator classes only and it's documented. But now, consider: the CPython implementation can unexpectedly invoke a method on a user-defined iterator class, even though this method's name is not '__*__' and not documented as special! That's new and that's bad. Might I suggest that at least you consider using hint instead of cue? I'm pretty sure that hint has been in use for some time, and always to mean a value that can't be assumed to be correct but that improves performance if it is. For example, algorithms that insert values in balanced trees sometimes take hint arguments that suggest where the algorithm should start searching for the insertion point. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] threadsafe patch for asynchat
On Wed, 08 Feb 2006 15:42:39 +0100 Georg Brandl [EMAIL PROTECTED] wrote: Neal Norwitz wrote: On 2/7/06, Christopher Armstrong [EMAIL PROTECTED] wrote: Twisted is wonderful, powerful, rich, and very large. Perhaps a small subset could be carefully extracted The subject of putting (parts of) Twisted into the standard library comes up once every 6 months or so, at least on our mailing list. For all that I think asyncore is worthless, I'm still against copying Twisted into the stdlib. Or at least I'm not willing to maintain the necessary fork, and I fear the nightmares about versioning that can easily occur when you've got both standard library and third party versions of a project. I wouldn't be enthusiastic about putting all of Twisted in the stdlib either. Twisted is on a different release schedule than Python. However, isn't there a relatively small core subset like Alex mentioned that isn't changing much? Could we split up those components and have those live in the core, but the vast majority of Twisted live outside as it does now? +1. This would be very useful for simple networking applications. I have a simple library I wrote some time ago to make asynchronous TCP servers (honeypots), and I wrote it exactly for the reasons being discussed on this thread: the other developers were not very familiar with Python (they were planning to use Perl on the project) and a bit confused with asyncore. Twisted was the obvious answer, but I could not convince them to put it in the project because of the size and the work needed to put it in all machines they were planning to use. I used this library several times the last two years. The last two weeks I've been using it with another project, but yesterday (a coincidence ?) I decided to reduce all of it to a single module. It is roughly based on Twisted, the interface is similar, some parts are a copy of Twisted code (select code, LineProtocol is a copy of twisted's LineReceiver) but only 16k in size, everything is covered by unittests. It's intended for servers, but client support can be added with some effort too. Maybe it fits the needs of what is being discussed on this thread. It's available here: http://www.pythonbrasil.com.br/moin.cgi/HoneyPython?action=AttachFiledo=gettarget=asiel.tar.bz2 -- Pedro Werneck ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] _length_cue()
+1 for __length_hint__. Raymond? On 2/8/06, Andrew Koenig [EMAIL PROTECTED] wrote: I'm worried about the name. There are now exactly two names that behave like a special method without having the double-underscores around it. The first name is 'next', which is kind of fine because it's for iterator classes only and it's documented. But now, consider: the CPython implementation can unexpectedly invoke a method on a user-defined iterator class, even though this method's name is not '__*__' and not documented as special! That's new and that's bad. Might I suggest that at least you consider using hint instead of cue? I'm pretty sure that hint has been in use for some time, and always to mean a value that can't be assumed to be correct but that improves performance if it is. For example, algorithms that insert values in balanced trees sometimes take hint arguments that suggest where the algorithm should start searching for the insertion point. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/guido%40python.org -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Let's just *keep* lambda
On 2/8/06, Patrick Collison [EMAIL PROTECTED] wrote: And to think that people thought that keeping lambda, but changing the name, would avoid all the heated discussion... :-) Note that I'm not participating in any attempts to improve lambda. Just about the only improvement I'd like to see is to add parentheses around the arguments, so you'd write lambda(x, y): x**y instead of lambda x, y: x**y. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Let's just *keep* lambda
At 10:07 AM 2/8/2006 -0800, Guido van Rossum wrote: On 2/8/06, Patrick Collison [EMAIL PROTECTED] wrote: And to think that people thought that keeping lambda, but changing the name, would avoid all the heated discussion... :-) Note that I'm not participating in any attempts to improve lambda. Just about the only improvement I'd like to see is to add parentheses around the arguments, so you'd write lambda(x, y): x**y instead of lambda x, y: x**y. lambda(x,y) looks like a function call until you hit the ':'; we don't usually have keywords that work that way. How about (lambda x,y: x**y)? It seems like all the recently added constructs (conditionals, yield expressions, generator expressions) take on this rather lisp-y look. :) Or, if you wanted to eliminate the lambda keyword, then (from x,y return x**y) could be a function expression, and it looks even more like most of the recently-added expression constructs. Well, actually, I guess to mirror the style of conditionals and genexps more closely, it would have to be something like (return x**y from x,y) or (x**y from x,y). Ugh. Never mind, let's just leave it the way it is today. :) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Linking with mscvrt
Thomas Heller wrote: I'm not sure the platform SDK include files (.H and .IDL) are really compatible with VC7.1. I remember that we (on our company, building C++ software) had to 'Unregister the PSDK Directories with Visual Studio' (available from the start menu) before building the stuff, otherwise there were compiler errors. This needs some testing, sure. However, I'm fairly confident that Microsoft has fixed/is going to fix whatever issues arise - they want the platform SDK to be usable with a recent compiler (not necessarily the latest one). There was a recent update to the platform SDK (which now comes with both Itanium and AMD64 compilers), so I'm (still) optimistic. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] _length_cue()
+1 on 'hint' vs 'cue'... also infers 'not definitive' (sort of like having a hint of how much longer the honey do list is... the honey do list is never 'exhaustive', only exhausting! ;-) On 2/8/06, Andrew Koenig [EMAIL PROTECTED] wrote: I'm worried about the name. There are now exactly two names that behave like a special method without having the double-underscores around it. The first name is 'next', which is kind of fine because it's for iterator classes only and it's documented. But now, consider: the CPython implementation can unexpectedly invoke a method on a user-defined iterator class, even though this method's name is not '__*__' and not documented as special! That's new and that's bad. Might I suggest that at least you consider using hint instead of cue? I'm pretty sure that hint has been in use for some time, and always to mean a value that can't be assumed to be correct but that improves performance if it is. For example, algorithms that insert values in balanced trees sometimes take hint arguments that suggest where the algorithm should start searching for the insertion point. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/ldlandis%40gmail.com -- LD Landis - N0YRQ - from the St Paul side of Minneapolis ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] threadsafe patch for asynchat
Barry Warsaw wrote: On Tue, 2006-02-07 at 16:01 -0800, Robert Brewer wrote: Perhaps, but please keep in mind that the smtpd module uses both, currently, and would have to be rewritten if either is removed. Would that really be a huge loss? It'd be a huge loss for the random fellow who needs to write an email fixup proxy between a broken client and Exim in a couple of hours. ;) But I can't speak for how often this need comes up among users. Robert Brewer System Architect Amor Ministries [EMAIL PROTECTED] ___ Python-Dev mailing list Python-Dev@python.org 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 modules should link to libpython
On 8-feb-2006, at 16:47, Gustavo J. A. M. Carneiro wrote: gjc:/usr/lib/python2.4/lib-dynload$ ldd itertools.so libpthread.so.0 = /lib/libpthread.so.0 (0x2abcc000) libc.so.6 = /lib/libc.so.6 (0x2ace2000) /lib/ld-linux-x86-64.so.2 (0x4000) gjc:/usr/lib/python2.4/lib-dynload$ It seems that Python C extension modules are not linking explicitly to libpython. Yet, they explicitly reference symbols defined in libpython. When libpython is loaded in a global scope all is fine. However, when libpython is dlopen()ed with the RTLD_LOCAL flag, python C extensions always get undefined symbols. This problem happened recently with the nautilus-python package, which installs an extension for the Nautilus file manager that allows extensions in Python. For performance reasons, it now opens extensions with RTLD_LOCAL flag, thus breaking python extensions. Any thoughts? Should I go ahead and open a bug report (maybe with patch), or is this controversial? I don't know about Linux, but on OSX we don't link with libpython (or Python.framework) on purpose: this allows you to share extensions between several builds of the same version of Python. If you do link with libpython and extension that was compiled by a python installed at a different location will result in having two copies of libpython in memory, only one of which is initialized. You end up with very interesting crashes. Ronald -- Gustavo J. A. M. Carneiro [EMAIL PROTECTED] [EMAIL PROTECTED] The universe is always one step beyond logic. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/ ronaldoussoren%40mac.com smime.p7s Description: S/MIME cryptographic signature ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Linking with mscvrt
Giovanni Bajo wrote: I just came up with an idea how to resolve the VC versioning problems for good: Python should link with mscvrt.dll (which is part of the operating system), not with the CRT that the compiler provides. Can you elaborate exactly on which versioning problems you think of? I could, but I don't want to elaborate too much. Please google for it - there has been written a lot about it. In short, you cannot really link two different versions of msvcrt (e.g. mscvrt.dll, msvcrt4.dll, msvcr7.dll, msvcr71.dll, mscvrtd.dll, msvcr71d.dll, ...) into a single program, plus you cannot redistribute the CRT unless you are a Visual Studio licensee. This causes problems for extension writers: they need to own the same version of visual studio that Python was built with. It would complicate the build process and make Python lag behind CRT development (including bugfixes and whatnot) that Microsoft does. There isn't really too much development in the CRT, and the little development I can see (e.g. in VS 2005) is rather counter-productive. So ideally, Python should drop usage of the CRT entirely (but getting there will be a long process). Hopefully, P3k will drop usage of stdio for file objects, which will be a big step forward. You could as well ask to always stick with GCC 2.95 to solve ABI problems, but I don't think it's the correct long time solution. I expect more and more Windows libraries (binary version) to be shipped with dependencies on MSVCR71.DLL. Now that VS2005 is out, I doubt that. More and more will also depend on msvcr80.dll. Then, when the next visual studio comes out, you can (probably) add msvcr81.dll to the list of libraries that might be used. This will go on forever, and we cannot win. It's really not using GCC 2.95 which I'm after. It's using /lib/libc.so that I want to. People should be free to use whatever compiler they have access to. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] threadsafe patch for asynchat
Steve Holden wrote: In case the processing of events needed to block? If I'm processing web requests in an async* dispatch loop and a request needs the results of a (probably lengthy) database query in order to generate its output, how do I give the dispatcher control again to process the next asynchronous network event? I see. Ideally, you should obtain the socket for the connection to the database, and add it to the asyncore loop. That would require you have an async database API, of course. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] threadsafe patch for asynchat
On Wed, 2006-02-08 at 10:24 -0800, Robert Brewer wrote: It'd be a huge loss for the random fellow who needs to write an email fixup proxy between a broken client and Exim in a couple of hours. ;) Or the guy who needs to whip together an RFC-compliant minimal SMTP server to use in unit tests of some random Python implemented mailing list manager. Just fer instance. But still... But I can't speak for how often this need comes up among users. Yeah, there is that. ;) -Barry signature.asc Description: This is a digitally signed message part ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Old Style Classes Goiung in Py3K
On 2/8/06, Fuzzyman [EMAIL PROTECTED] wrote: I understand that old style classes are slated to disappear in Python 3000. Does this mean that the following will be a syntax error : class Something: pass *or* that instead it will automatically inherit from object ? The latter of course. I never even considered making this illegal. :-) -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Old Style Classes Goiung in Py3K
On 2/8/06, Georg Brandl [EMAIL PROTECTED] wrote: Fuzzyman wrote: Hello all, I understand that old style classes are slated to disappear in Python 3000. Does this mean that the following will be a syntax error : class Something: pass *or* that instead it will automatically inherit from object ? Of course, I would say. There's no reason to forbid this in Py3k. And you would be right. Guido has always said that classes would act as if they inherited from object by default. There are no plans to change the syntax of how you can specify inheritance in Python 3. All that is changing is what the default is when you specify no superclasses. -Brett ___ Python-Dev mailing list Python-Dev@python.org 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 modules should link to libpython
Gustavo J. A. M. Carneiro wrote: Any thoughts? Should I go ahead and open a bug report (maybe with patch), or is this controversial? You should only link with libpython if there really is a shared libpython. In a standard Python installation, there is no libpython, but instead, symbols are in the executable. Notice that libpython isn't really supported: all changes to that code originate from contributions, and I refuse to develop changes to it myself. So you can file a bug report, but there likely won't be any reaction in the next few years (atleast not from me). OTOH, if a working patch was contributed, I could apply that fairly quickly: I agree that modules should link with libpython if libpython is shared. I can accept that the Mac does it differently, although I think the rationale for doing that is dangerous: you shouldn't really attempt to share extension modules across Python versions. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Let's just *keep* lambda
On 2/8/06, Phillip J. Eby [EMAIL PROTECTED] wrote: At 10:07 AM 2/8/2006 -0800, Guido van Rossum wrote: On 2/8/06, Patrick Collison [EMAIL PROTECTED] wrote: And to think that people thought that keeping lambda, but changing the name, would avoid all the heated discussion... :-) Note that I'm not participating in any attempts to improve lambda. Just about the only improvement I'd like to see is to add parentheses around the arguments, so you'd write lambda(x, y): x**y instead of lambda x, y: x**y. lambda(x,y) looks like a function call until you hit the ':'; we don't usually have keywords that work that way. I agree with Phillip. Making it look more like a function definition, I think, is a bad move to make. The thing is quirky as-is, let's not partially mask that fact. How about (lambda x,y: x**y)? It seems like all the recently added constructs (conditionals, yield expressions, generator expressions) take on this rather lisp-y look. :) Or, if you wanted to eliminate the lambda keyword, then (from x,y return x**y) could be a function expression, and it looks even more like most of the recently-added expression constructs. Well, actually, I guess to mirror the style of conditionals and genexps more closely, it would have to be something like (return x**y from x,y) or (x**y from x,y). Ugh. Never mind, let's just leave it the way it is today. :) ``(use x, y, in x**y)`` is the best I can think of off the top of my head. But if Guido is not budging on tweaking lambda in any way other than parentheses, then I say just leave the busted thing as it is and let it be the wart that was never removed. -Brett ___ Python-Dev mailing list Python-Dev@python.org 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 modules should link to libpython
On 8-feb-2006, at 19:55, Martin v. Löwis wrote: Gustavo J. A. M. Carneiro wrote: Any thoughts? Should I go ahead and open a bug report (maybe with patch), or is this controversial? I can accept that the Mac does it differently, although I think the rationale for doing that is dangerous: you shouldn't really attempt to share extension modules across Python versions. My explanation seems to be bad, I meant to say sharing extensions across different builds of the same Python version. One might install a normal unix build in /opt/python and a framework build in /Library/Frameworks. This is not as important now as it was when Python 2.3.x was state of the art, then you could have a python 2.3.x framework both in /System/Library/Frameworks (provided by Apple) and in /Library/ Frameworks (build yourself or downloaded the official MacPython binaries). Those would share the same site-packages directory (/Library/Python/2.3). Ronald smime.p7s Description: S/MIME cryptographic signature ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Let's just *keep* lambda
How about (lambda x,y: x**y)? The purpose of this thread was to conserve brain-power by bringing the issue to a close. Instead, it is turning into syntax/renaming fest. May I suggest that this be moved to comp.lang.python and return only if a community consensus emerges from the thousands of random variants? Raymond ___ Python-Dev mailing list Python-Dev@python.org 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 modules should link to libpython
On Feb 8, 2006, at 11:02 AM, Ronald Oussoren wrote: On 8-feb-2006, at 19:55, Martin v. Löwis wrote: Gustavo J. A. M. Carneiro wrote: Any thoughts? Should I go ahead and open a bug report (maybe with patch), or is this controversial? I can accept that the Mac does it differently, although I think the rationale for doing that is dangerous: you shouldn't really attempt to share extension modules across Python versions. My explanation seems to be bad, I meant to say sharing extensions across different builds of the same Python version. One might install a normal unix build in /opt/python and a framework build in /Library/ Frameworks. This is not as important now as it was when Python 2.3.x was state of the art, then you could have a python 2.3.x framework both in /System/Library/Frameworks (provided by Apple) and in /Library/ Frameworks (build yourself or downloaded the official MacPython binaries). Those would share the same site-packages directory (/Library/Python/2.3). They never shared the same site-packages directory... The major reason we use -undefined dynamic_lookup rather than linking directly to a particular Python is so that the framework can be moved around without everything going to hell.. e.g., to the inside of an application bundle. At the time, we didn't have any tools that could do the Mach-O header rewriting that py2app does now. There isn't a whole lot of reason to use -undefined dynamic_lookup these days, but there also isn't many compelling reasons to go back to direct linking. There is one use case that direct linking would support: having multiple distinct Python interpreters in the same process space, which could be useful for writing plug-ins to applications that are not Python based... Other than that, there's little reason to bother with it. -bob ___ Python-Dev mailing list Python-Dev@python.org 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 modules should link to libpython
Ronald Oussoren wrote: My explanation seems to be bad, I meant to say sharing extensions across different builds of the same Python version. One might install a normal unix build in /opt/python and a framework build in /Library/Frameworks. Sorry, I didn't read your message carefully enough. This isn't a problem in Unix/ELF: you (normally) only put the name of the library into the resulting executable/library, not the absolute path. You then use the library search path (system-defined or LD_LIBRARY_PATH) to find the library. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Let's just *keep* lambda
Raymond Hettinger wrote: How about (lambda x,y: x**y)? The purpose of this thread was to conserve brain-power by bringing the issue to a close. Instead, it is turning into syntax/renaming fest. May I suggest that this be moved to comp.lang.python and return only if a community consensus emerges from the thousands of random variants? I'd like to suggest this be moved to comp.lang.python and never return. Community consensus on syntax is a pipe dream. Robert Brewer System Architect Amor Ministries [EMAIL PROTECTED] ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] small floating point number problem
[Raymond Hettinger] ... The asymmetric handling of denormals by the atof() and ftoa() functions is why you see a difference. A consequence of that asymmetry is the breakdown of the expected eval(repr(f))==f invariant: Just noting that such behavior is a violation of the 754 standard for string-double conversion. But Microsoft's libraries don't _claim_ to support the 754 standard, so good luck suing them ;-). Python doesn't promise anything here either. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Let's just *keep* lambda
Raymond Hettinger wrote: How about (lambda x,y: x**y)? The purpose of this thread was to conserve brain-power by bringing the issue to a close. Instead, it is turning into syntax/renaming fest. May I suggest that this be moved to comp.lang.python and return only if a community consensus emerges from the thousands of random variants? Right, then we can get back to important stuff like how to represent octal constants. regards Steve -- Steve Holden +44 150 684 7255 +1 800 494 3119 Holden Web LLC www.holdenweb.com PyCon TX 2006 www.python.org/pycon/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] threadsafe patch for asynchat
Barry Warsaw wrote the following on 2006-02-08 at 13:45 PST: === Or the guy who needs to whip together an RFC-compliant minimal SMTP server to use in unit tests of some random Python implemented mailing list manager. Just fer instance. But still... But I can't speak for how often this need comes up among users. Yeah, there is that. ;) === There are other, third-party, SMTP server objects available. You could always use one of those. Once the Python egg and PyPI improve and start widespread use perhaps the question of what is in the core library and what is not will become moot. Being a Gentoo Linux user I already enjoy having many modules available, with automatic dependency installation, on demand. So the idea of core library is already blurred for me. -- -- ~ Keith Dart [EMAIL PROTECTED] public key: ID: 19017044 http://www.dartworks.biz/ = signature.asc Description: PGP signature ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Let's just *keep* lambda
Guido van Rossum wrote the following on 2006-02-08 at 10:07 PST: === Note that I'm not participating in any attempts to improve lambda. === FWIW, I like lambda. No need to change it. Thank you. -- -- ~ Keith Dart [EMAIL PROTECTED] public key: ID: 19017044 http://www.dartworks.biz/ = signature.asc Description: PGP signature ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] _length_cue()
[Armin Rigo] It was replaced by an optional undocumented method called _length_cue(), which would be used to guess the number of remaining items in an iterator, for performance reasons. I'm worried about the name. There are now exactly two names that behave like a special method without having the double-underscores around it. IMHO for safety reasons we need to stick double-underscores around this name too, e.g. __length_cue__(). The single underscore was meant to communicate that this method is private (which is why it is undocumented). Accordingly, the dir() function is smart enough to omit the method from its listing (which is a good thing). We follow similar naming conventions in pure Python library code. OTOH, this one is a bit different in that it is not truly private; rather, it is more like a friend method used internally for various tools to be able to communicate with each other. If you change to a double underscore convention, you're essentially making this a public protocol. IMHO, the safety reasons are imaginary -- the scenario would involve subclassing one of these builtin objects and attaching an identically named private method. All that being said, I don't feel strongly about it and you guys are welcome to change it if offends your naming convention sensibilities. [Andrew Koenig] Might I suggest that at least you consider using hint instead of cue? Personally, I prefer cue which my dictionary defines as a signal, hint, or suggestion. The alternate definition of a prompt for some action applies equally well. Also, to my ear, length_hint doesn't sound right. I'm -0 on changing the name. If you must, then go ahead. [Armin Rigo] BTW the reason I'm looking at this is that I'm considering adding another undocumented internal-use-only method, maybe __getitem_cue__(), that would try to guess what the nth item to be returned will be. This would allow the repr of some iterators to display more helpful information when playing around with them at the prompt, e.g.: enumerate([3.1, 3.14, 3.141, 3.1415, 3.14159, 3.141596]) enumerate (0, 3.1), (1, 3.14), (2, 3.141),... length 6 At one point, I explored and then abandoned this idea. For objects like itertools.count(n), it worked fine -- the state was readily knowable and the eval(repr(obj)) round-trip was possible. However, for tools like enumerate(), it didn't make sense to have a preview that only applied in a tiny handful of (mostly academic) cases and was not evaluable in any case. I was really attracted to the idea of having more informative iterator representations but learned that even when it could be done, it wasn't especially useful. When someone creates an iterator at the interactive prompt, they almost always either wrap it in a consumer function or they assign it to a variable. The case of typing just, enumerate([1,2,3]), comes up only once, when first learning was enumerate() does. Raymond ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] threadsafe patch for asynchat
On Wed, 2006-02-08 at 11:45 -0800, Keith Dart wrote: There are other, third-party, SMTP server objects available. You could always use one of those. Very true. In fact, Twisted comes to the rescue again here. When I needed to test Mailman's NNTP integration I could either spend several weeks figuring out how to install and configure some traditional NNTP server, or I could just install Twisted and run exactly three commands (one of which was sudo :). Once the Python egg and PyPI improve and start widespread use perhaps the question of what is in the core library and what is not will become moot. Indeed. Being a Gentoo Linux user I already enjoy having many modules available, with automatic dependency installation, on demand. So the idea of core library is already blurred for me. Although I'm doing a lot more dev on the Mac these days, I definitely agree that this is what makes Gentoo so cool for Linux, and I can't wait for Gentoo-on-OSX to switch to doing things the Right Way (can you say bye-bye DarwinPorts?). -Barry signature.asc Description: This is a digitally signed message part ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Path PEP: some comments
El Sábado, 4 de Febrero de 2006 2:35, Giovanni Bajo escribió:
Hello,
my comments on the Path PEP:
- Many methods contain the word 'path' in them. I suppose this is to help
transition from the old library to the new library. But in the context of a
new Python user, I don't think that Path.abspath() is optimal. Path.abs()
looks better. Maybe it's not so fundamental to have exactly the same names
of the old library, especially when thinking of future? If I rearrange my
code to use Path, I can as well rename methods to something more sound at
the same time.
I haven't revised the whole class to look exactly which methods contain the
word path and which do not. But, anyway this is just a simple comment. It's
clear to me that Path.abspath() look redundant and Path.abs() tells clearly
what the method does. But I think in most cases the method won't be used
through the class, like 'Path.abs(instance)' but through an existing instance
like 'home.abs()'. In this case, I think 'home.abspath()' would be more
readable than 'home.abs()'. Anyway, in the long term, I think people will
just get used to what gets finally decided, so I could say I'm +0 about this.
(Does one have to be a python developer or something to use the {+,-}{0,1}
thing?, 'cause I'm not.)
Regards,
Andy.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Let's just *keep* lambda
Robert Brewer wrote: Community consensus on syntax is a pipe dream. +1 QOTF And trust me, it'll be in there, since I'm one of the summary writers. ;-) STeVe -- Grammar am for people who can't think for myself. --- Bucky Katt, Get Fuzzy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Help on choosing a PEP to volunteer on it : 308, 328 or 343
Hi. I'm interested in doing an undergraduate project under some Python core PEP. I'm newbie to Python core. Program in C/C++. I've downloaded the sources with svn and now I'm studying it. There are 3 PEP accepted : . 308 : Conditional Expressions . 328 : Imports: Multi-Line and Absolute/Relative . 343 : The with Statement I've some questions : 1. For a newbie in the Python core development, what is the best PEP to begin with ? 2. PEP's owner is the one who submitted the proposal or the one who is working on it; 3. How do we know what are the developers working on the PEP ? Thanks in advance. Regards. Joao Macaiba (wavefunction). ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Help on choosing a PEP to volunteer on it : 308, 328 or 343
On 2/8/06, Joao Macaiba [EMAIL PROTECTED] wrote: Hi. I'm interested in doing an undergraduate project under some Python core PEP. I'm newbie to Python core. Program in C/C++. I've downloaded the sources with svn and now I'm studying it. There are 3 PEP accepted : . 308 : Conditional Expressions . 328 : Imports: Multi-Line and Absolute/Relative . 343 : The with Statement I've some questions : 1. For a newbie in the Python core development, what is the best PEP to begin with ? Wild guess? 308, but that still requires changing the grammar and editing the AST compiler. 328 will need playing with the import code which is known to be hairy. 343 has the same needs as 308, but I bet would be more complicated. 2. PEP's owner is the one who submitted the proposal or the one who is working on it; Technically it is the person who drew up the proposal and agreed to carry it through. Usually, though, they are also the ones willing to implement it (or at least make sure that happens). 3. How do we know what are the developers working on the PEP ? You ask just like you are. =) Otherwise you just have to listen on python-dev for anyone to mention they are working on it. -Brett ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Linking with mscvrt
Martin v. Löwis wrote: To do that, we would need to compile and link with the SDK header files and import libraries, not with the ones that visual studio provides. I withdraw that idea. It appears that the platform SDK doesn't (any longer?) provide an import library for msvrt.dll, and Microsoft documents mscvrt as intended only for system components. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Help on choosing a PEP to volunteer on it : 308, 328 or 343
[Joao Macaiba] 1. For a newbie in the Python core development, what is the best PEP to begin with ? I recommend, PEP 308: Conditional Expressions Raymond ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Linking with mscvrt
Martin v. Löwis: So ideally, Python should drop usage of the CRT entirely (but getting there will be a long process). Hopefully, P3k will drop usage of stdio for file objects, which will be a big step forward. You don't need to drop the CRT, just encapsulate it so there is one copy controlled by Python that hands out wrapped objects (file handles, file pointers, memory blocks, others?). These wrappers can only be manipulated through calls back to that owning code that then calls the CRT. Unfortunately this change would itself be incompatible with current extensions. Neil ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] _length_cue()
Hi Raymond, On Wed, Feb 08, 2006 at 03:02:21PM -0500, Raymond Hettinger wrote: IMHO, the safety reasons are imaginary -- the scenario would involve subclassing one of these builtin objects and attaching an identically named private method. No, the senario applies to any user-defined iterator class, not necessary subclassing an existing one: class MyIter(object): ... def __iter__(self): ... return self ... def next(self): ... return whatever ... def _length_cue(self): ... print oups! please, CPython, don't call me unexpectedly ... list(MyIter()) oups! please, CPython, don't call me unexpectedly (...) This means that _length_cue() is at the moment a special method, in the sense that Python can invoke it implicitely. This said, do we vote for __length_hint__ or __length_cue__? :-) And does anyone objects about __getitem_hint__ or __getitem_cue__? Maybe __lookahead_hint__ or __lookahead_cue__? Armin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Help on choosing a PEP to volunteer on it : 308, 328 or 343
On Wed, Feb 08, 2006 at 01:39:34PM -0800, Brett Cannon wrote: On 2/8/06, Joao Macaiba [EMAIL PROTECTED] wrote: 1. For a newbie in the Python core development, what is the best PEP to begin with ? Wild guess? 308, but that still requires changing the grammar and editing the AST compiler. 328 will need playing with the import code which is known to be hairy. 343 has the same needs as 308, but I bet would be more complicated. Joao brought up an interesting point on #python on freenode, though... Is there any documentation regarding the AST code? I started fiddling with it just to get to know it, adding some weird syntax just for the hell of it, and I *think* I understand how the AST is supposed to work. I haven't gotten around to actually coding it, though (just like I haven't gotten around to PEP 13 ;) so maybe I have it all wrong. A short description of the principles and design choices would be nice, maybe with a paragraph on how to add new syntax constructs. How tightly should the AST follow the grammar, for instance? (I pointed Joao to the augmented assignment patch for 2.0, which doesn't say anything about the AST but should be helpful hints in his quest to understand Python's internals. Lord knows that's how I learned it... By the time he groks it all, hopefully someone can help him with the AST parts ;) -- Thomas Wouters [EMAIL PROTECTED] Hi! I'm a .signature virus! copy me into your .signature file to help me spread! ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Let's just *keep* lambda
Guido van Rossum [EMAIL PROTECTED] writes: On 2/8/06, Patrick Collison [EMAIL PROTECTED] wrote: And to think that people thought that keeping lambda, but changing the name, would avoid all the heated discussion... :-) Note that I'm not participating in any attempts to improve lambda. Just about the only improvement I'd like to see is to add parentheses around the arguments, so you'd write lambda(x, y): x**y instead of lambda x, y: x**y. That would seem to be a bad idea, as it means something already: f = lambda (x,y): x + y t = (1,2) f(t) 3 Cheers, mwh -- Solaris: Shire horse that dreams of being a race horse, blissfully unaware that its owners don't quite know whether to put it out to grass, to stud, or to the knackers yard. -- Jim's pedigree of operating systems, asr ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] threadsafe patch for asynchat
Martin v. Löwis wrote: That patch looks wrong. What does it mean to run in a thread? All code runs in a thread, all the time: sometime, that thread is the main thread. Furthermore, I can't see any presumed thread-unsafety in asynchat. Ok, perhaps the notation could be improved, but the idea of the semaphore in the patch is Does it run inside of a multithreaded environment, and could its push() functions be called from a different thread? I have verified that there is a problem with running it in such an environment. My results are more or less identical to those described in the following thread: http://mail.python.org/pipermail/medusa-dev/1999/000431.html (see also the reply message to this one regarding the solution -- if you look at the Zope source, Zope deals with the problem in the way I am suggesting asynchat be patched) It seems that somehow in line 271 (python 2.4) of asynchat.py, producer_fifo.list is not empty, and thus popleft() is executed. However, popleft() finds the deque empty. This means that somehow the deque (or list -- the bug is identical in python 2.3) is emptied between the if() and the popleft(), so perhaps asyncore.loop(), running in a different thread from the thread which calls async_chat.push(), empties it. The problem is typically exhibited when running in a multithreaded environment, and when calling the async_chat.push() function many (i.e. perhaps tens of thousands) times quickly in a row from a different thread. However, this behavior is avoided by creating a Lock for refill_buffer(), so that it cannot be executed simultaneously. It is also avoided by not executing initiate_send() at all (as is done by Zope in ZHTTPServer.zhttp_channel). Sure, there is a lot of member variables in asynchat which aren't specifically protected against mutual access from different threads. So you shouldn't be accessing the same async_chat object from multiple threads. If applying this patch does indeed make it safe to use async_chat.push() from other threads, why would it be a bad thing to have? It seems to make the code less cryptic (i.e. I don't need to override base classes in order to include code which processes a nonempty Queue object -- I simply make a call to the push() function of my instance of async_chat, and I'm done). -Mark (also, of course push_with_producer() would probably also need the same changes that would be made to push() ) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] threadsafe patch for asynchat
On Wed, 08 Feb 2006 15:42:39 +0100 Georg Brandl [EMAIL PROTECTED] wrote: Neal Norwitz wrote: On 2/7/06, Christopher Armstrong [EMAIL PROTECTED] wrote: Twisted is wonderful, powerful, rich, and very large. Perhaps a small subset could be carefully extracted The subject of putting (parts of) Twisted into the standard library comes up once every 6 months or so, at least on our mailing list. For all that I think asyncore is worthless, I'm still against copying Twisted into the stdlib. Or at least I'm not willing to maintain the necessary fork, and I fear the nightmares about versioning that can easily occur when you've got both standard library and third party versions of a project. I wouldn't be enthusiastic about putting all of Twisted in the stdlib either. Twisted is on a different release schedule than Python. However, isn't there a relatively small core subset like Alex mentioned that isn't changing much? Could we split up those components and have those live in the core, but the vast majority of Twisted live outside as it does now? +1. This would be very useful for simple networking applications. I have a simple library I wrote some time ago to make asynchronous TCP servers (honeypots), and I wrote it exactly for the reasons being discussed on this thread: the other developers were not very familiar with Python (they were planning to use Perl on the project) and a bit confused with asyncore. Twisted was the obvious answer, but I could not convince them to put it in the project because of the size and the work needed to put it in all machines they were planning to use. I used this library several times the last two years. The last two weeks I've been using it with another project, but yesterday (a coincidence ?) I decided to reduce all of it to a single module. It is roughly based on Twisted, the interface is similar, some parts are a copy of Twisted code (select code, LineProtocol is a copy of twisted's LineReceiver) but only 16k in size, everything is covered by unittests. It's intended for servers, but client support can be added with some effort too. Maybe it fits the needs of what is being discussed on this thread. It's available here: http://www.pythonbrasil.com.br/moin.cgi/HoneyPython?action=AttachFiledo=gettarget=asiel.tar.bz2 -- Pedro Werneck ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Let's just *keep* lambda
On 2/8/06, Guido van Rossum [EMAIL PROTECTED] wrote: On 2/8/06, Patrick Collison [EMAIL PROTECTED] wrote: And to think that people thought that keeping lambda, but changing the name, would avoid all the heated discussion... :-) Note that I'm not participating in any attempts to improve lambda. Then, is there any chance anonymous function - or closure - is supported in python 3.0 ? Or at least have a discussion about it? (IMHO, closure is very handy for function like map, sort etc. And having to write a function for multiple statement is kind of good in that function name explains what it does. However, I sometimes feel that having no name at all is clearer. Also, having to define a function when it'll be used only once seemed inappropriate sometimes.) or is there already discussion about it (and closed)? -Jiwon -Jiwon Just about the only improvement I'd like to see is to add parentheses around the arguments, so you'd write lambda(x, y): x**y instead of lambda x, y: x**y. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/seojiwon%40gmail.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Let's just *keep* lambda
Jiwon Seo [EMAIL PROTECTED] wrote: On 2/8/06, Guido van Rossum [EMAIL PROTECTED] wrote: On 2/8/06, Patrick Collison [EMAIL PROTECTED] wrote: And to think that people thought that keeping lambda, but changing the name, would avoid all the heated discussion... :-) Note that I'm not participating in any attempts to improve lambda. Then, is there any chance anonymous function - or closure - is supported in python 3.0 ? Or at least have a discussion about it? or is there already discussion about it (and closed)? Closures already exist in Python. def foo(bar): ... return lambda: bar + 1 ... a = foo(5) a() 6 - Josiah ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] threadsafe patch for asynchat
Not terrible. I think I may try re-working Medusa to use this. Bill ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] _length_cue()
[Armin Rigo] Hi Raymond, . . . This means that _length_cue() is at the moment a special method, in the sense that Python can invoke it implicitely. Okay, that makes sense. Go ahead and make the swap. This said, do we vote for __length_hint__ or __length_cue__? :-) I prefer __length_cue__ unless someone has a strong objection. And does anyone objects about __getitem_hint__ or __getitem_cue__? Maybe __lookahead_hint__ or __lookahead_cue__? No objections here though I do question the utility of the protocol. It is going to be difficult to find pairs of objects (one providing the lookahead value and the other consuming it) that can make good use of the protocol. Outside of those unique pairings, there is no value at all. Thinking back over the code I ever seen, I cannot think of one case where the would have been helpful (except for the ill-fated adventure of trying to make iterators have more informative __repr__ methods). Before putting this in production, it would probably be worthwhile to search for code where it would have been helpful. In the case of __length_cue__, there was an immediate payoff. Value pre-fetching has more utility in an environment where the concept is used everywhere (such as your lightning demo at PyCon last year where you ran iterators forwards/backwards and do tricks with infinite iterators). Outside of such an environment, I think it is going to be use-case challenged. Raymond ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Help on choosing a PEP to volunteer on it : 308, 328 or 343
On 2/8/06, Thomas Wouters [EMAIL PROTECTED] wrote: On Wed, Feb 08, 2006 at 01:39:34PM -0800, Brett Cannon wrote: On 2/8/06, Joao Macaiba [EMAIL PROTECTED] wrote: 1. For a newbie in the Python core development, what is the best PEP to begin with ? Wild guess? 308, but that still requires changing the grammar and editing the AST compiler. 328 will need playing with the import code which is known to be hairy. 343 has the same needs as 308, but I bet would be more complicated. Joao brought up an interesting point on #python on freenode, though... Is there any documentation regarding the AST code? I started fiddling with it just to get to know it, adding some weird syntax just for the hell of it, and I *think* I understand how the AST is supposed to work. I haven't gotten around to actually coding it, though (just like I haven't gotten around to PEP 13 ;) so maybe I have it all wrong. A short description of the principles and design choices would be nice, maybe with a paragraph on how to add new syntax constructs. How tightly should the AST follow the grammar, for instance? There is a Python/compile.txt that was originally started by Jeremy that I subsequently picked up and heavily fleshed out at the last PyCon sprint. It didn't get checked in during the merge because Jeremy was not sure where to put it. But I just checked it in since I realized I can delete it once PEP 339 is updated. It is slightly out of date, though, because of the lack of info on the arena API. (I pointed Joao to the augmented assignment patch for 2.0, which doesn't say anything about the AST but should be helpful hints in his quest to understand Python's internals. Lord knows that's how I learned it... By the time he groks it all, hopefully someone can help him with the AST parts ;) Probably best way to read it is to follow how an 'if' statement gets compiled. That's how I picked it up. -Brett ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] email 3.1 for Python 2.5 using PEP 8 module names
I posted a message to the email-sig expressing my desire to change our module naming scheme to conform to PEP 8. This would entail a bump in the email version to 3.1, and would be included in Python 2.5. Of course, the old names would still work, for at least one Python release. All the responses so far have been favorable, and Fred Drake provided a nice hook for allow us to support both the old and new names. Code is now checked into the Python sandbox that implements this. Here's the top of the thread: http://mail.python.org/pipermail/email-sig/2006-February/000254.html I'd like to keep discussion on the email-sig, so please join us there if you care about this one way or the other. -Barry signature.asc Description: This is a digitally signed message part ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Linking with mscvrt
Martin v. Löwis wrote: I withdraw that idea. It appears that the platform SDK doesn't (any longer?) provide an import library for msvrt.dll, and Microsoft documents mscvrt as intended only for system components. Insofar as it forms a base on which other separately- compiled pieces of code run, it seems to me that Python itself deserves to be classed as a system component. Although I concede that's probably not quite what Microsoft mean by the term... -- Greg Ewing, Computer Science Dept, +--+ University of Canterbury, | Carpe post meridiam! | Christchurch, New Zealand | (I'm not a morning person.) | [EMAIL PROTECTED] +--+ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Linking with mscvrt
Neil Hodgson wrote: You don't need to drop the CRT, just encapsulate it so there is one copy controlled by Python that hands out wrapped objects (file handles, file pointers, memory blocks, others?). These wrappers can only be manipulated through calls back to that owning code that then calls the CRT. But that won't help when you need to deal with third-party code that knows nothing about Python or its wrapped file objects, and calls the CRT (or one of the myriad extant CRTs, chosen at random:-) directly. I can't see *any* solution to this that works in general. Even if Python itself and all its extensions completely avoid using the CRT, there's still the possibility that two different extensions will use two third-party libraries that were compiled with different CRTs. As far as I can see, Microsoft have created an intractable mess here. Their solution of compile your whole program with the same CRT completely misses the possibility that the whole program may consist of disparate separately- written and separately-compiled parts, and there may be no single person with the ability and/or legal right to compile and link the whole thing. -- Greg Ewing, Computer Science Dept, +--+ University of Canterbury, | Carpe post meridiam! | Christchurch, New Zealand | (I'm not a morning person.) | [EMAIL PROTECTED] +--+ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] _length_cue()
Armin Rigo wrote: This said, do we vote for __length_hint__ or __length_cue__? :-) I prefer something containing hint rather than cue because it more explicitly says what we mean. I feel that __length_hint__ is a bit long, though. We have __len__, not __length__, so maybe it should be __len_hint__ or __lenhint__. And does anyone objects about __getitem_hint__ or __getitem_cue__? I'm having trouble seeing widespread use cases for this. If an object is capable of computing arbitrary items on demand, seems to me it should be implemented as a lazily-evaluated sequence or mapping rather than an iterator. The iterator protocol is currently very simple and well-focused on a single task -- producing things one at a time, in sequence. Let's not clutter it up with too much more cruft. -- Greg Ewing, Computer Science Dept, +--+ University of Canterbury, | Carpe post meridiam! | Christchurch, New Zealand | (I'm not a morning person.) | [EMAIL PROTECTED] +--+ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Let's send lambda to the shearing shed (Re: Let's just *keep* lambda)
My thought on lambda at the moment is that it's too VERBOSE. If a syntax for anonymous functions is to pull its weight, it needs to be *very* concise. The only time I ever consider writing a function definition in-line is when the body is extremely short, otherwise it's clearer to use a def instead. Given that, I do *not* have the space to waste with 6 or 7 characters of geeky noise-word. So my vote for Py3k is to either 1) Replace lambda args: value with args - value or something equivalently concise, or 2) Remove lambda entirely. -- Greg Ewing, Computer Science Dept, +--+ University of Canterbury, | Carpe post meridiam! | Christchurch, New Zealand | (I'm not a morning person.) | [EMAIL PROTECTED] +--+ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Let's just *keep* lambda
On 2/8/06, Josiah Carlson [EMAIL PROTECTED] wrote: Jiwon Seo [EMAIL PROTECTED] wrote: On 2/8/06, Guido van Rossum [EMAIL PROTECTED] wrote: On 2/8/06, Patrick Collison [EMAIL PROTECTED] wrote: And to think that people thought that keeping lambda, but changing the name, would avoid all the heated discussion... :-) Note that I'm not participating in any attempts to improve lambda. Then, is there any chance anonymous function - or closure - is supported in python 3.0 ? Or at least have a discussion about it? or is there already discussion about it (and closed)? Closures already exist in Python. def foo(bar): ... return lambda: bar + 1 ... a = foo(5) a() 6 Not in that we don't have anonymous function (or closure) with multiple statements. Also, current limited closure does not capture programming context - or variables. -Jiwon ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [BULK] Python-Dev Digest, Vol 31, Issue 37
| From: Michael Hudson [EMAIL PROTECTED] | Guido van Rossum [EMAIL PROTECTED] writes: | || On 2/8/06, Patrick Collison [EMAIL PROTECTED] wrote: ||| And to think that people thought that keeping lambda, but changing ||| the name, would avoid all the heated discussion... :-) || || Note that I'm not participating in any attempts to improve lambda. || || Just about the only improvement I'd like to see is to add parentheses || around the arguments, so you'd write lambda(x, y): x**y instead of || lambda x, y: x**y. | | That would seem to be a bad idea, as it means something already: | f = lambda (x,y): x + y t = (1,2) f(t) | 3 | | Cheers, | mwh Hey! I didn't know you could do that. I'm happy. My lambdas just grew parenthesis on the arguments: f=lambda(x):x+1 f(2) 3 def go(f,x): ... print f(x) ... go(lambda(x):x+1,1) 2 go(lambda(x,y):x+y,(1,3)) 4 /c ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Let's just *keep* lambda
Jiwon Seo [EMAIL PROTECTED] wrote:
On 2/8/06, Josiah Carlson [EMAIL PROTECTED] wrote:
Closures already exist in Python.
def foo(bar):
... return lambda: bar + 1
...
a = foo(5)
a()
6
Not in that we don't have anonymous function (or closure) with
multiple statements.
As already said, lambdas (Python's anonymous functions) are limited to a
single expression. If you can't do what you want with a single
expression, then it probably SHOULD have a name, so you should use a
standard function definition.
Also, current limited closure does not capture
programming context - or variables.
You should clarify yourself. According to my experience, you can do
anything you want with Python closures, it just may take more work than
you are used to.
def environment():
env = {}
def get_variable(name):
return env[name]
def set_variable(name, value):
env[name] = value
def del_variable(name):
del env[name]
return get_variable, set_variable, del_variable
- Josiah
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] threadsafe patch for asynchat
Mark Edgington [EMAIL PROTECTED] wrote: Martin v. Löwis wrote: That patch looks wrong. What does it mean to run in a thread? All code runs in a thread, all the time: sometime, that thread is the main thread. Furthermore, I can't see any presumed thread-unsafety in asynchat. Ok, perhaps the notation could be improved, but the idea of the semaphore in the patch is Does it run inside of a multithreaded environment, and could its push() functions be called from a different thread? Asyncore is not threadsafe. The reason it is not threadsafe is because there was no effort made to make it threadsafe, because it is not uncommon for the idea of asynchronous sockets to be the antithesis of threaded socket servers. In any case, one must be very careful as (at least in older versions of Python on certain platforms), running sock.send(data) on two threads simultaneously for the same socket was a segfault. I understand that this is what you are trying to avoid, but have you considered just doing... q = Queue.Queue() def push(sock, data): q.put((sock, data)) def mainloop(): ... while not q.empty(): sock, data = q.get() sock.push(data) ... Wow, now we don't have to update the standard library to introduce a false sense of thread-safety into asyncore! - Josiah ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] _length_cue()
Raymond Hettinger wrote: [Andrew Koenig] Might I suggest that at least you consider using hint instead of cue? Personally, I prefer cue which my dictionary defines as a signal, hint, or suggestion. The alternate definition of a prompt for some action applies equally well. No, it doesn't, because it's in the wrong direction. The caller isn't prompting the callee to perform an action, it's asking for some information. I agree that hint is a more precise name. -- Greg Ewing, Computer Science Dept, +--+ University of Canterbury, | Carpe post meridiam! | Christchurch, New Zealand | (I'm not a morning person.) | [EMAIL PROTECTED] +--+ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Linking with mscvrt
Greg Ewing wrote: As far as I can see, Microsoft have created an intractable mess here. Their solution of compile your whole program with the same CRT completely misses the possibility that the whole program may consist of disparate separately- written and separately-compiled parts, and there may be no single person with the ability and/or legal right to compile and link the whole thing. Hence, Microsoft's suggesting is entirely different these days: use .NET, and you won't have these versioning problems anymore. I'm getting off-topic... Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Let's just *keep* lambda
Jiwon Seo wrote: Then, is there any chance anonymous function - or closure - is supported in python 3.0 ? Or at least have a discussion about it? That discussion appears to be closed (or, not really: everybody can discuss, but it likely won't change anything). (IMHO, closure is very handy for function like map, sort etc. And having to write a function for multiple statement is kind of good in that function name explains what it does. However, I sometimes feel that having no name at all is clearer. Also, having to define a function when it'll be used only once seemed inappropriate sometimes.) Hmm. Can you give real-world examples (of existing code) where you needed this? Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Help with Unicode arrays in NumPy
Thank you, Martin and Stephen, for the suggestions and comments. For your information: We decided that all NumPy arrays of unicode strings will use UCS4 for internal representation. When an element of the array is selected, a unicodescalar (which inherits directly from the unicode builtin type but has attributes and methods of arrays) will be returned. On wide builds, the scalar is a perfect match. On narrow builds, surrogate pairs will be used if they are necessary as the data is copied over to the scalar. Best regards, -Travis ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Linking with mscvrt
Martin v. Löwis: I don't think this would be good enough. I then also need a way to provide extension authors with an API that looks like the CRT, but isn't: they cannot realistically change all their code to use the wrapped objects. In a recent case, somebody tried to passed a FILE* to a postrgres DLL linked with a different CRT; he shouldn't need to change the entire postgres code to use the modified API. The postgres example is strange to me as I'd never consider passing a FILE* over a DLL boundary. Maybe this is a Unix/Windows cultural thing due to such practices being more dangerous on Windows. Also, there is still the redistribution issue: to redistribute msvcr71.dll, you need to own a MSVC license. People that want to use py2exe (or some such) are in trouble: they need to distribute both python25.dll, and msvcr71.dll. They are allowed to distribute the former, but (formally) not allowed to distribute the latter. Link statically. Neil ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Linking with mscvrt
Greg Ewing: But that won't help when you need to deal with third-party code that knows nothing about Python or its wrapped file objects, and calls the CRT (or one of the myriad extant CRTs, chosen at random:-) directly. Can you explain exactly why there is a problem here? Its fairly normal under Windows to build applications that provide a generic plugin interface (think Netscape plugins or COM) that allow the plugins to be built with any compiler and runtime. Neil ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
