[Python-Dev] Re: [Python-checkins] python/dist/src/Python thread_pthread.h, 2.53, 2.53.4.1
[EMAIL PROTECTED] wrote: Update of /cvsroot/python/python/dist/src/Python In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv25872 Modified Files: Tag: release24-maint thread_pthread.h Log Message: Patch #1163249 - Correctly handle _POSIX_SEMAPHORES == -1 to mean no support for posix semaphores. Index: thread_pthread.h === RCS file: /cvsroot/python/python/dist/src/Python/thread_pthread.h,v retrieving revision 2.53 retrieving revision 2.53.4.1 diff -u -d -r2.53 -r2.53.4.1 --- thread_pthread.h 7 Jul 2004 17:44:12 - 2.53 +++ thread_pthread.h 16 Mar 2005 04:13:29 - 2.53.4.1 @@ -16,9 +16,13 @@ family of functions must indicate this by defining _POSIX_SEMAPHORES. */ #ifdef _POSIX_SEMAPHORES +#if _POSIX_SEMAPHORES == -1 +#define HAVE_BROKEN_POSIX_SEMAPHORES +#else #include #include #endif +#endif #if !defined(pthread_attr_default) # define pthread_attr_default ((pthread_attr_t *)NULL) ___ Python-checkins mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/python-checkins This change has broken the build on FreeBSD 4.x for me: gcc -pthread -c -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes - I. -I./Include -DPy_BUILD_CORE -o Python/thread.o Python/thread.c In file included from Python/thread.c:101: Python/thread_pthread.h:19: syntax error *** Error code 1 Backing it out allows the build to proceed & there are no unexpected test failures. Compiler is gcc 2.95.4. Regards, Andrew. - Andrew I MacIntyre "These thoughts are mine alone..." E-mail: [EMAIL PROTECTED] (pref) | Snail: PO Box 370 [EMAIL PROTECTED] (alt) |Belconnen ACT 2616 Web:http://www.andymac.org/ |Australia ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Re: [Python-checkins] python/dist/src/Python thread_pthread.h, 2.53, 2.53.4.1
Andrew MacIntyre wrote: This change has broken the build on FreeBSD 4.x for me: gcc -pthread -c -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes - I. -I./Include -DPy_BUILD_CORE -o Python/thread.o Python/thread.c In file included from Python/thread.c:101: Python/thread_pthread.h:19: syntax error *** Error code 1 This should be fixed now, please try again and report whether it works. It would be really nice if you could try to analyse such problems deeper in the future. In this case, it would have helped if you had reported that _POSIX_SEMAPHORES is defined as #define _POSIX_SEMAPHORES so that the #if line expands to #if == -1 The standard solution in this case is to write #if (_POSIX_SEMAPHORES+0) == -1 so that it expands to a binary add if _POSIX_SEMAPHORES really is a number (as it should be, according to POSIX); if some system incorrectly defines _POSIX_SEMAPHORES to empty, you get #if (+0) == -1 which still should compile. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
RE: [Python-Dev] sum()
[Tim] > For contrast, here's one that doesn't use frexp(), and is probably > faster because of that; internally, len(sums) probably won't exceed 5 > in real life (but could get as large as 2K for pathological inputs, > spanning fp's full dynamic range): > > def summer4(iterable): > sums = [0.0] > for x in iterable: > sums.append(x) > for i in xrange(len(sums)-2, -1, -1): > y = sums[i] > if abs(x) < abs(y): > x, y = y, x > hi = x+y > lo = y - (hi - x) > if lo: > sums[i+1] = lo > else: > del sums[i+1] > x = hi > sums[0] = x > return sum(reversed(sums), 0.0) Here's a rewrite with the partial sums ordered by increasing magnitude. A cursor is used to write-out new, non-zero terms. That makes the list growth or shrinkage occur at the end of the list and it avoids reversed indexing. Those two changes made the code easier for me to follow. Leaving off the 0.0 makes the routine generic. It works equally well with int, long, Decimal, float, and complex. def summer5(iterable, start=0): "Binary or Decimal floating point summation accurate to full precision." partials = [] # sorted, non-overlapping partial sums for x in iterable: i = 0 # cursor for writing-out new partials sums for y in partials: if abs(x) < abs(y): x, y = y, x hi = x + y lo = y - (hi - x) if lo: partials[i] = lo i += 1 x = hi partials[i:] = [x] return sum(partials, start) The loop invariants for the list of partial sums are: assert partials == sorted(partials, key=abs) assert nonoverlapping(partials) where a rough check for overlaps is: def nonoverlapping(seqn,offset=100): """Verify that sequence elements have no overlapping bits. Set offset to -Emin to handle the full range of floats. """ cumv = 0L for elem in seqn: m, exp = frexp(abs(elem)) v = int(m * 2 ** 53) * 2L ** (exp + offset) if cumv & v: return False cumv |= v return True Raymond ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
RE: [Python-Dev] @decoration of classes
Josiah Carlson writes: [... stuff about reST and TeX ...] > While I have not used it often, I have done the equivalent of decorating > classes; it is as natural (though perhaps not quite as useful initially) > as decorating functions, [... stuff about ice cream and sprinkles ...] Hmm... the only bit that I found particularly interesting there was the bit where you mention that you've used class decorators (without the syntax) before. What did you use them for? After all, the current state of things is "don't bother implementing class decorators because there is no compelling use case". If you've got some sample use cases, what were they? For my own part, I observe the following. Because a function decorator acts after the function object is created, there are limits to what it can do to the function. It can add some markup (eg: set properties or doc strings). It can "hook" either before or after the function is called. Or it can "veto" the function call and do something else instead. In the case of function calls, these are pretty much the interesting things you would want to do. Similarly, because a class decorator acts after the class is created there are limits on what it can do. It can modify the class object (replacing methods and such). It can add markup. It can replace the class with another (perhaps a proxy or some such). But most of these are things which are more easily done by a metaclass... and all of them *can* be done by metaclasses. The only noticable advantage that I see to class decorators over metaclasses is that there's a more straightforward way to combine them. And I'm not sure that combining metaclasses (or class decorators) is something I want to encourage. So I'm inclined to use different tools for modifying functions and modifying classes because the ways you want to modify them are different, and decorators are "tuned" to what people normally want to do with functions (like simple wrapping) while metaclasses are "tuned" to what people normally want to do with classes (like support for inheritance. But a few *good* use cases would change my mind. -- Michael Chermside ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] @decoration of classes
Michael Chermside <[EMAIL PROTECTED]> wrote: > > Josiah Carlson writes: > > [... stuff about reST and TeX ...] > > While I have not used it often, I have done the equivalent of decorating > > classes; it is as natural (though perhaps not quite as useful initially) > > as decorating functions, > [... stuff about ice cream and sprinkles ...] > > Hmm... the only bit that I found particularly interesting there was the bit > where you mention that you've used class decorators (without the syntax) > before. > > What did you use them for? After all, the current state of things is "don't > bother implementing class decorators because there is no compelling use > case". If you've got some sample use cases, what were they? 99% of my use cases have been of the form of decorating all of the methods of a class at once (optionally excluding __init__ and __new__) using @sync or binding constants [1]. > For my own part, I observe the following. Because a function decorator > acts after the function object is created, there are limits to what it > can do to the function. It can add some markup (eg: set properties or > doc strings). It can "hook" either before or after the function is > called. Or it can "veto" the function call and do something else > instead. In the case of function calls, these are pretty much the > interesting things you would want to do. Unless one is willing to rewrite the bytecode; in which case things like Raymond's binding constants decorator or even the inline decorator (that I found and then lost) are possible and useful. > Similarly, because a class decorator acts after the class is created > there are limits on what it can do. It can modify the class object > (replacing methods and such). It can add markup. It can replace the > class with another (perhaps a proxy or some such). But most of these > are things which are more easily done by a metaclass... and all of > them *can* be done by metaclasses. The only noticable advantage that > I see to class decorators over metaclasses is that there's a more > straightforward way to combine them. And I'm not sure that combining > metaclasses (or class decorators) is something I want to encourage. Indeed, though people do combine metaclasses (or at least attempt to do so), often in strange, wonderful, and not so wonderful ways. I actually learned metaclasses because someone asked a question about combining them, and I wanted to understand the question (if not answer it). > So I'm inclined to use different tools for modifying functions and > modifying classes because the ways you want to modify them are > different, and decorators are "tuned" to what people normally want > to do with functions (like simple wrapping) while metaclasses are > "tuned" to what people normally want to do with classes (like support > for inheritance. While one can call what is being done with decorators "simple wrapping", I believe it goes a bit beyond that. With properly defined @accepts and @returns decorators, certainly one can perform runtime validation of call/return, but with a proper validation mechanism, one can do compile-time type inference and call type validation/verification (PyChecker with types, not just number of arguments). This kind of thing would give us the (desired by some) optional typing information for passed and returned arguments. Of course none of the above is a new idea, but I'm pointing it out so that we remember that there already exists a mechanism for doing this without further syntax changes to the language (someone once offered "def f(int:foo=3)" or some such, and this along with may other things are possible with decorators). As a side-note, I personally think of function/method decoration as a kind of subclassing of a function (as I have mentioned here before[2]); and if it were treated as such (with an attribute that references the previous function/method), one wouldn't need to copy __doc__, __name__, etc., attributes onto certain decorated functions. As for what most people use metaclasses for, I don't know, I try not to use metaclasses if possible (I haven't had a _compelling_ need so far), and don't use class decoration very often either. > But a few *good* use cases would change my mind. As I have said from the beginning, I don't believe any of my use cases are compelling, as I don't believe that sprinkles on a banana split are compelling. I also don't believe that someone is going to come forward with a compelling use case when compared against function/method decorators (like PyObjC wrapping, @accepts, @returns, @dispatch, @memoize, @synchronize, @classmethod, @staticmethod, ...), as I don't believe that even metaclasses are as compelling as function/method decoration. With that said; if it is there, people will use it. Someone will even post on their blog about how it is the best thing ever, or even how it ruined the language. So be it. In any case, I've spent more time writing emails about this
[Python-Dev] Re: @decoration of classes
Michael Chermside wrote:
Josiah Carlson writes:
...While I have not used it often, I have done the equivalent of decorating
classes; it is as natural (though perhaps not quite as useful initially)
as decorating functions,
But a few *good* use cases would change my mind.
Until this weekend, I really had no idea what a good use case for
class decorators would look like. However, I stumbled upon something
interesting. I was refactoring Kirby Urner's "hypertoons" code this
weekend and hit upon an interesting use for decorators. On reflection,
this might well be a candidate for class decorators. The unusual thing
is that it does nothing to the decorated function; it simply stores it
in a data structure. The "converter" decorator builder can be used for
data values, including classes, but there is an advantage to having
them at the top of the definition.
Using such decorators looks like:
@converter('inch', 'foot')
def someconversion(...
@converter('foot', 'yard')
def anotherconversion(...
@converter('yard', 'furlong')
def yetanotherconversion(...
Classes can be put into the data structures with:
converter('flour', 'bread')(BakingClass)
_But_ (at least for the app I was fiddling with) decorating at the top
of declaration helps show the purpose of the class.
Have a look at:
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/393010
and see what you think.
-- Scott David Daniels
[EMAIL PROTECTED]
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Re: webbrowser.py
| > On Thu, Mar 24, 2005 at 11:36:41AM -0300, Rodrigo Dias Arruda Senra wrote: | > > Edit libwebbrowser.tex as you see fit, then send it to me | > > and I'll TeXify it back to you. | > | >Uploaded to http://python.org/sf/754022 . I am not a native English | > speaker, and this is the first time I've edited a TeX file. Please | > correct my grammar, spelling, TeX, whatever... Outstanding work Oleg. I read it through and wouldn't change a bit. I have revised: libwebbrowser.tex.patch and webbrowser.py.patch. They are Ok regarding grammar, TeX and ... whatever . I recommend to apply both files. However, I would withdraw the third file -- webbrowser wrapper script, since the same functionality can be accomplished with: python -m webbrowser http://www.python.org best regards, Senra -- ,_ | ) Rodrigo Senra |(__ --- _((|__|] GPr Sistemas http://www.gpr.com.br _ |(|___|] IC - Unicamp http://www.ic.unicamp.br/~921234 ___(|__|] L___(|_|]--- ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] @decoration of classes
On Mon, Mar 28, 2005 at 09:25:18AM -0800, Michael Chermside wrote: > Josiah Carlson writes: > > [... stuff about reST and TeX ...] > > While I have not used it often, I have done the equivalent of decorating > > classes; it is as natural (though perhaps not quite as useful initially) > > as decorating functions, > [... stuff about ice cream and sprinkles ...] > > Hmm... the only bit that I found particularly interesting there was the bit > where you mention that you've used class decorators (without the syntax) > before. > > What did you use them for? After all, the current state of things is "don't > bother implementing class decorators because there is no compelling use > case". If you've got some sample use cases, what were they? > > For my own part, I observe the following. Because a function decorator > acts after the function object is created, there are limits to what it > can do to the function. It can add some markup (eg: set properties or > doc strings). It can "hook" either before or after the function is > called. Or it can "veto" the function call and do something else > instead. In the case of function calls, these are pretty much the > interesting things you would want to do. > > Similarly, because a class decorator acts after the class is created > there are limits on what it can do. It can modify the class object > (replacing methods and such). It can add markup. It can replace the > class with another (perhaps a proxy or some such). But most of these > are things which are more easily done by a metaclass... and all of > them *can* be done by metaclasses. The only noticable advantage that > I see to class decorators over metaclasses is that there's a more > straightforward way to combine them. And I'm not sure that combining > metaclasses (or class decorators) is something I want to encourage. > > So I'm inclined to use different tools for modifying functions and > modifying classes because the ways you want to modify them are > different, and decorators are "tuned" to what people normally want > to do with functions (like simple wrapping) while metaclasses are > "tuned" to what people normally want to do with classes (like support > for inheritance. > Metaclasses are a muddle because they can do everything a class can do and more, since metclasses are to classes as classes are to objects. >From the bottom up: objects: get magic methods from their class can manipulate non-magic methods and attributes on a per-instance basis classes: get magic methods from their metaclass can create magic methods and attributes used by objects. Plus anything objects can do metaclasses: can create magic methods of a class can define class methods and attributes Plus anything a class can do. Metaclasses are a muddle because we (the royal we) are used to doing most things at the class level. Defining class methods in a metaclass like this probably isn't your regular style >>> class MetaK(type): ... def foo(cls): pass ... >>> class K: ... __metaclass__ = MetaK ... def bar(cls): pass ... bar = classmethod(bar) ... >>> K.foo > >>> K.bar > I'm happy using classmethod instead of writing a metaclass everytime I need a classmethod. I think everyone is class-centric, or we could define static methods using class MetaK(type): def foo(): pass foo = metaclassmethod(foo) # class method of a type is a static method? Since I've never wanted to set a type's __repr__ I use metaclasses as a handy place to do mundane class-level manipulations. I don't actually need to do type level manipulations. So that's why I like class decorators, it lets me push type level manipulations (manipulating a class from its type's __init__ or __new__) down to the class level where my brain normally hangs out. I just want to change an object's behavior and I'd welcome a chance to do it by manipulating the class and not the class's class (which is the object's class's class, yikes!) -jackdied ps, I tried to raise a simliar point at PyCon during Alex Martelli's Q&A but got flustered and screwed it all up. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] @decoration of classes
On Sat, Mar 26, 2005 at 12:36:08PM -0800, Josiah Carlson wrote:
>
> Eric Nieuwland <[EMAIL PROTECTED]> wrote:
> >
> > Given the ideas so far, would it possible to:
> >
> > def meta(cls):
> > ...
> >
> > @meta
> > class X(...):
> > ...
>
> It is not implemented in Python 2.4. From what I understand, making it
> happen in Python 2.5 would not be terribly difficult. The question is
> about a "compelling use case". Is there a use where this syntax is
> significantly better, easier, etc., than an equivalent metaclass? Would
> people use the above syntax if it were available?
>
For compelling, I think the code smell put off by the "no conflict" metaclass
generator recipe (which also appeared in Alex Martelli's PyCon talk) is fairly
compelling from a duck typing point of view.
# would you rather
class K:
__metaclass__ = no_conflict(MetaA, MetaB)
# or
@decoA
@decoB
class K: pass
Unless you actually want a class two inherit magic methods from two different
types you don't need two metaclasses. You just need the class manipulations
that are done in two different metaclasses.
I get around this[1] by defining a function that calls things that manipulate
classes, the metaclass's init will make the 'register' function static if it
is defined in the __dict__ and then call it with (name, cls).
If I called that method 'decorate' instead and spelled it @decorate I'd be
a happy camper.
-jackdied
[1] "Register" metatype, define the register method to screw around with
your class definition or leave it out to let your parent class do its thing
class Register(type):
def __init__(cls, name, bases, dict):
if ('register' in dict):
setattr(cls, 'register', staticmethod(dict['register']))
cls.register(name, cls)
I call it Register because largely I just use it to check the __dict__ for
special methods and put classes in one or more global buckets. I have cron
jobs that operate on the different buckets.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] @decoration of classes
At 07:55 PM 3/28/05 -0500, Jack Diederich wrote: For compelling, I think the code smell put off by the "no conflict" metaclass generator recipe (which also appeared in Alex Martelli's PyCon talk) is fairly compelling from a duck typing point of view. # would you rather class K: __metaclass__ = no_conflict(MetaA, MetaB) # or @decoA @decoB class K: pass Actually, it's possible today with: class K: decoB() decoA() As long as decoA() and decoB() use the "class advisor" mechanism I built for Zope and PyProtocols. That mechanism basically sticks a custom __metaclass__ into the enclosing class, and implements a simple protocol for chaining subsequently-defined class advisors. See 'protocols.advice' in PyProtocols or 'zope.interface.advice' in Zope or Twisted for details. Anyway, I'm not certain that moving these functions up to decorator status will really do anything useful; you can already put them near the top of the class definition, such that they're relatively prominent. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Re: comprehension abbreviation (was: Adding any() and all())
Jim Jewett wrote: Gareth McCaughan wrote: Some bit of my brain is convinced that [x in stuff if condition] is the Right Syntax and keeps making me type it even though I know it doesn't work. (and I agree with Gareth) On Monday 2005-03-14 12:42, Eric Nieuwland wrote: The full syntax is: [ f(x) for x in seq if pred(x) ] being allowed to write 'x' instead of 'identity(x)' is already a shortcut, just as dropping the conditional part. I think this is the heart of the disagreement. Mentally, I'm not collecting some function of x (which happens to be identity). I am filtering an existing set. Being able to collect f(x) instead is just a useful but hackish shortcut. Have it your own way, but if you happen to need a list of transformed elements of a filtered list (and that isn't an uncommon requirement) then the idea of selecting the set members and then transforming the copies as a separate step seems a little ... unnecessary. Having to write [x for x in seq] to produce a copy of a list doesn't seem that outrageous to me, and I don't find the predicate-less case of your proposal that convincing: [x in seq] seems somehow too terse. [...] regards Steve -- Steve Holden+1 703 861 4237 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/ Python Web Programming http://pydish.holdenweb.com/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
