Re: Alternative to multi-line lambdas: Assign-anywhere def statements
On Wednesday, February 11, 2015 at 8:04:33 AM UTC-5, Albert van der Horst wrote:
> In article ,
> Ethan Furman wrote:
> >-=-=-=-=-=-
> >
> >On 01/24/2015 11:55 AM, Chris Angelico wrote:
> >> On Sun, Jan 25, 2015 at 5:56 AM, Ethan Furman wrote:
> >>> If the non-generic is what you're concerned about:
> >>>
> >>> # not tested
> >>> dispatch_table_a = {}
> >>> dispatch_table_b = {}
> >>> dispatch_table_c = {}
> >>>
> >>> class dispatch:
> >>> def __init__(self, dispatch_table):
> >>> self.dispatch = dispatch_table
> >>> def __call__(self, func):
> >>> self.dispatch[func.__name__] = func
> >>> return func
> >>>
> >>> @dispatch(dispatch_table_a)
> >>> def foo(...):
> >>>pass
> >>
> >> That's still only able to assign to a key of a dictionary, using the
> >> function name.
> >
> >This is a Good Thing. The def statement populates a few items, __name__
> >being one of them. One
> >of the reasons lambda
> >is not encouraged is because its name is always '', which just ain't
> >helpful when the
> >smelly becomes air borne! ;)
>
> That's the reason why my ideal Python doesn't attach a name to a lambda
> denotation:
>
> x -> x**2
>
> is a function object, not something that has a name.
>
> It is not until we assign the object to a name (which becomes thereby a
> function)
> that the __name__ thingy comes into play, like so.
>
> f = x->x**2
> or
> f = x-> return x**2
> for those who don't like Algol68
>
> I've heard arguments that with -> the __name__ is not filled in correctly.
> I can't see why the parser would understand more easily
>
> def f(x):
> return x**2
>
> than
>
> f = x->
> return x**2
>
> [I'm striving for simplification, doing away with both the lambda and
> the def keywords. This is not a proposal for a language change, I'm
> trying to explore possibilities here. ]
>
> >
> >--
> >~Ethan~
>
> Groetjes Albert
> --
> Albert van der Horst, UTRECHT,THE NETHERLANDS
> Economic growth -- being exponential -- ultimately falters.
> albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
And then you do
g = f
And what then? Or even
g = f = x -> x ** 2
Of course, you can say that problem already exists
def f(x): return x ** 2
g = f
But that goes to the heart of the issue: part of the purpose of def is to give
a function a name.
--
https://mail.python.org/mailman/listinfo/python-list
Tortoise, Hare, Hell, None
Five and a half years ago, Tim Peters (glory be to his name) made the following statement: > In that respect, None is unique among non-keyword names, and for that reason > alone it should be a keyword instead of a global. I expect that will happen > someday, too. But it's a race between that and hell freezing over . We now know who won. -- http://mail.python.org/mailman/listinfo/python-list
-W: Python bug? Documentation bug?
It appears that the -W option on starting python doesn't work the same as the warnings module. In particular, the "message" parameter is not treated as a regular expression, but rather a string literal which must appear at the beginning of a warning message in order to match. The treatment of -W in "python -h" makes no mention of the warnings module (and I actually couldn't find any definitive documentation on command line switches), though the documentation for the warnings module does say: The interpreter saves the arguments for all -W options without interpretation in sys.warnoptions; the warnings module parses these when it is first imported That also kind of maybe implies that warnings is automatically imported by the interpreter, but it doesn't actually say so. How should this be treated? = Here's an example of the problem. (I've reproduced it in version 2.5 also) $ python -W ignore:whenThreaded Python 2.4.2 (#2, Mar 10 2006, 15:10:56) [GCC 3.4.2 [FreeBSD] 20040728] on freebsd5 Type "help", "copyright", "credits" or "license" for more information. >>> from twisted.internet import reactor /usr/local/lib/python2.4/site-packages/twisted/internet/base.py:245: DeprecationWarning: threadable.whenThreaded is deprecated. Use application-level logic instead. threadable.whenThreaded(self.initThreads) >>> $ python -W ignore:'threadable.whenThreaded is deprecated. Use application-level logic instead.' Python 2.4.2 (#2, Mar 10 2006, 15:10:56) [GCC 3.4.2 [FreeBSD] 20040728] on freebsd5 Type "help", "copyright", "credits" or "license" for more information. >>> from twisted.internet import reactor >>> $ python -W ignore:threadable.whenThreaded Python 2.4.2 (#2, Mar 10 2006, 15:10:56) [GCC 3.4.2 [FreeBSD] 20040728] on freebsd5 Type "help", "copyright", "credits" or "license" for more information. >>> from twisted.internet import reactor >>> -- http://mail.python.org/mailman/listinfo/python-list
Re: -W: Python bug? Documentation bug?
Clarence wrote: > It appears that the -W option on starting python doesn't work the same > as the warnings module. In particular, the "message" parameter is not > treated as a regular expression, but rather a string literal which must > appear at the beginning of a warning message in order to match. The I must have gotten confused during my testing. The behavior is the same whether coming from the command line or from within the program. However, I see that the regular expression is being tested using re.match rather than re.search. Does that seem correct to people? At the least, that should be mentioned in the documentation. -- http://mail.python.org/mailman/listinfo/python-list
Ten years on....
I've been waiting for a month to post this (yesterday), and then I missed it. Oh, well, it's funny and deserves to be republished on its ten-year-and-one-day anniversary. BTW, a member of the ANSI C committee once told me that the only thing rand is used for in C code is to decide whether to pick up the axe or throw the dwarf, and if that's true I guess "the typical libc rand" is adequate for all but the most fanatic of gamers . -- Tim Peters, 21 June 1997. "Belated-but-still-sincerely-admiring-of-Tim-Peters"-ly yrs, Clarence -- http://mail.python.org/mailman/listinfo/python-list
Mysterious argument count error to __new__
I'm having problems with JPype and am trying to change the way it creates Python classes as proxies for Java classes and interfaces. I'm trying to get around "inconsistent mro" problems, but in doing so, I've run into a real mystery. Here's the original code. It first makes a metaclass, then makes a class using that metaclass. ## metaclass = type.__new__(type, name+"$$Static", tuple(meta_bases), static_fields) members['__metaclass__'] = metaclass result = type.__new__(metaclass, name, tuple(bases), members) ## I'm getting an error on the first call to __new__, but I want to see if my "bases" list is acceptable, putting aside for the moment that "meta_bases" is having a problem. So I put this line directly ahead of the three quoted above: ## type.__new__(type, 'aoeu', tuple(bases), members) ## You can see that this is essentially exactly the same as the first of the three, just using a different name, a diffent bases tuple, and a different dictionary. Whereas the first of the three gets an mro kind of error, when I insert this new line, it gets: type.__new__(type, 'aoeu', tuple(bases), members) TypeError: __new__() takes exactly 2 arguments (4 given) How is it possible that I get a number-of-arguments error when the following line, with the same number of arguments, does not? (This can't even be relevant, really, but I also printed out the value of "type" before the line, and got as it should be.) Thanks for any help. Clarence -- http://mail.python.org/mailman/listinfo/python-list
MRO theory
I'm having problems creating classes because of "can't create a consistent mro" problems. I noticed, in a test program, that if the base class list that I pass to type.__new__ is sorted (using default keys, so presumably sorting by the id's of the class objects), that the problem goes away. Now in this test, the id's (memory addresses) of the class objects are presumably in the same order as the chronological order that the classes were created in (since the program is simple and doesn't delete any objects or make any temporaries). This may sound weird, but I don't actually care what order the base classes appear in as long as they're all there. This makes me wonder, since I can't say I understand the theory (I read the paper referenced in typeobject.c source, my brain didn't _quite_ melt) behind mro creation, if it is the case that there cannot be a consistency problem if each class in the base list was created after all classes that precede it in the base list. Can any genius weigh in on this question? -- http://mail.python.org/mailman/listinfo/python-list
Re: MRO theory
On Apr 11, 12:09 pm, Steve Holden <[EMAIL PROTECTED]> wrote: > Without wishing to lay claim to genius, I'd suggest that you don;'t > write programs relying on multiple inheritance until you have a thorough > understanding of its principles. > > The inability of the interpreter to create a consistent mro has nothing > to do with the order in which the base classes were created or where > they appear in memory. It's probably because you have introduced a > circularity: you are trying to define something based on A, which is > based on B, which is based on A or something similar. > No, there is no circularity. The problem is coming about in the JPype application. It creates a Python class to proxy any Java class or Java interface that the program uses (directly or indirectly). As far as the Java proxies go, when it creates a class it can have at most one superclass that is a proxy of a Java class, and arbitrarily many superclasses which are proxies of Java interfaces. The problem basically comes about because interfaces are not classes, but a class is being created to stand in for each one. There is real Java code that is causing a class construction failure because of an inability to construct a consistent mro. I've tried several approaches to make it work, and by accident, sorting the list of interface proxy classes, using the default comparison, make it work. That made me wonder if the theory had something to say. Obviously, if class A is created before class B, then B cannot be a base class of A, hence the chronological order of class creation _might_ have something to do with creating acceptable or unacceptable mro's. -- http://mail.python.org/mailman/listinfo/python-list
Re: MRO theory
On Apr 11, 5:21 pm, "Carl Banks" <[EMAIL PROTECTED]> wrote: > > There is real Java code that is causing a class construction failure > > because of an inability to construct a consistent mro. I've tried > > several > > approaches to make it work, and by accident, sorting the list of > > interface > > proxy classes, using the default comparison, make it work. > > It *might* not be an accident. Actually, what I meant to write was that my sorting was done by accident, but the heart of my question is, *was* it an accident? I don't have enough theory to answer that question. > > Because Java interfaces can be listed in any order, it's quite > possible that some interface hierarchies in Java violate Python's MRO > restrictions right out of the box. I would guess that JPype deals > with this situation by applying a consistent ordering to of bases when > it creates a proxy class. And it just might turn out that "order of > creation" is the sort key. Or something else could be the key > (alphabetical by name?). Regardless, sorted order just *might* be the > proper order to list bases to ensure MRO consistency. > > I'd suggest that this is probably a question better answered on the > JPype mailing list, since they would have answers and not just > speculations. It's a theoretical question, and Python implements the theory. And no, JPype does not deal with it at all; that's what I'm trying to fix. I know sorting by name does not work because that's one of the things I tried. You can start out with sorted base class lists, but the merging involved in creating the mro of a new class destroys that ordering. I find it very reasonable, however, to think that the creation order of the classes (implying constraints on the possible superclass relationships) may well be a property that the merge will always leave untouched. Hence my question. -- http://mail.python.org/mailman/listinfo/python-list
Changing intobject to use int rather than long
Does anyone think (or know) that it might cause any internal problems if the ival member of the struct defining an intobject were to be changed from its current "long int" to just "int"? When you move your application to a 64-bit system in order to get a bigger address space to store your millions/billions of integers in RAM, but they get twice as big, you don't gain very much. Thanks. -- http://mail.python.org/mailman/listinfo/python-list
Re: Changing intobject to use int rather than long
On Dec 18, 6:24 pm, "Chris Mellon" <[EMAIL PROTECTED]> wrote: > > Your int objects get twice as large, but you get 4294967296 times more > address space. > > (They don't always get twice as large, and you don't actually get that > much address space, and there's lots of other things wrong with this > answer, but the core truth - that your available address space grows > at a greater rate than the size of your ints - is correct). Technically true, but in my real world, I deal with physical RAM in the machine. I went from a 2GB machine that was using half its memory to an 8GB machine that is using one quarter its memory. Yes, it's better, but I still want that factor of two! -- http://mail.python.org/mailman/listinfo/python-list
Re: Changing intobject to use int rather than long
On Dec 18, 6:58 pm, Hrvoje Niksic <[EMAIL PROTECTED]> wrote:
> I don't think changing the underlying type will help at all. The
>
> On a 64-bit machine, that's 16 bytes for PyObject_HEAD and 8 more
> bytes for the value, 24 bytes total. Changing long to int won't
> decrease the struct size to 20 because the compiler will pad it to 24,
> the nearest multiple of 8. (Forcing the compiler to pack the struct
> won't help because malloc will still pad it for you.)
That's an excellent point. And true, too. Thanks, that will lay the
issue
to rest.
> If you need to store millions of integers compactly, maybe
> array.array('i') can help.
--
http://mail.python.org/mailman/listinfo/python-list
IDLE Python won't run or open, neither will it state the error for behaving this way
HI, I downloaded python 3.7.0 from your python website and it was installed successfully and I was able to run/open python but when I try to run/open IDLE python, it just wont open or run, it wont even state the error causing this... Please help me, how do I fix this? -- https://mail.python.org/mailman/listinfo/python-list
