Re: object.enable() anti-pattern
Steven D'Aprano wrote: There is no sensible use-case for creating a file without opening it. What would be the point? Early unix systems often used this as a form of locking. -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: object.enable() anti-pattern
Wayne Werner wrote:
You don't ever want a class that has functions that need to be called in
a certain order to *not* crash.
That seems like an overly broad statement. What
do you think the following should do?
f = open("myfile.dat")
f.close()
data = f.read()
--
Greg
--
http://mail.python.org/mailman/listinfo/python-list
Re: Making safe file names
Roy Smith wrote: In article <518b133b$0$29997$c3e8da3$54964...@news.astraweb.com>, Steven D'Aprano wrote: I suspect that the only way to be completely ungoogleable would be to name yourself something common, not something obscure. http://en.wikipedia.org/wiki/The_band Nope... googling for "the band" brings that up as the very first result. The Google knows all. You cannot escape The Google... -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: Message passing syntax for objects | OOPv2
Dennis Lee Bieber wrote: I also believe in a path of endless exponential growth. Challenge: Create more information than can be stored in one teaspoon of matter. Go ahead. Try! If that's your argument, then you don't really believe in *endless* exponential growth. You only believe in "exponential growth for long enough that I won't be around to suffer the consequences when it runs out". -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: Message passing syntax for objects | OOPv2
Chris Angelico wrote: On Sun, May 12, 2013 at 5:32 AM, Dennis Lee Bieber wrote: The coordinates of each particle storing the information in that teaspoon of matter. Which is probably more data than any of us will keyboard in a lifetime. Hence my point. My 1TB hard disk *already* contains more information than I could keyboard in my lifetime. The fact that it all got there is due to two things: (1) I didn't have to enter it all myself, and (2) most of it was auto-generated from other information, using compilers and other such tools. Our disk capacities are increasing exponentially, but so is the rate at which we have the ability to create information. I wouldn't be surprised if, at some point before the human race becomes extinct, we build computers whose operating system requires more than a teaspoonful of atoms to store. Especially if Microsoft still exists by then. :-) -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: Python for philosophers
Citizen Kant wrote: I roughly came to the idea that Python could be considered as an *economic mirror for data*, one that mainly *mirrors* the data the programmer types on its black surface, not exactly as the programmer originally typed it, but expressed in the most economic way possible. At best, this would be true only for a very small subset of things that you can enter into the interactive interpreter. Even confining yourself to arithmetic expressions, there are problems. Consider: >>> 12**34 4922235242952026704037113243122008064L The input is 6 characters long, and the output is 37 characters long. Is that more "economical"? -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: Python for philosophers
Citizen Kant wrote: What I do here is to try to "understand". That's different from just knowing. Knowledge growth must be consequence of understanding's increasing. As the scope of my understanding increases, the more I look for increasing my knowledge. Never vice versa, because, knowing isn't like to be right, it's just knowing. It doesn't always work that way. With some facts plus a theory, you can deduce more facts. But it's always possible for there to be more facts that you can't deduce from what you already know. But take in account that with "shortening" I refer to "according to Python's axiomatic parameters". I think what you're trying to say is that it takes an expression and reduces it to a canonical form, such as a single number or single string. That's true as far as it goes, but it barely scratches the surface of what the Python interpreter is capable of doing. In the most general terms, the Python interpeter (or any other computer system, for that matter) can be thought of as something with an internal state, and a transition function that takes the state together with some input and produces another state together with some output: F(S1, I) --> (S2, O) (Computer scientists call this a "finite state machine", because there is a limited number of possible internal states -- the computer only has so much RAM, disk space, etc.) This seems to be what you're trying to get at with your game-of-chess analogy. What distinguishes one computer system from another is the transition function. The transition function of the Python interpreter is rather complicated, and it's unlikely that you would be able to figure out all its details just by poking in inputs and observing the outputs. If you really want to understand it, you're going to have to learn some facts, I'm sorry to say. :-) -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: in need of some help...
Dennis Lee Bieber wrote: Is that the accepted group noun? I'd think a "crisis of Chrises" is more alliterative... A "confusion of Chrises" might be more appropriate in this case. -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: Harmonic distortion of a input signal
killybear...@gmail.com wrote: One more question. Function np.argmax returns max of non-complex numbers ? Because FFT array of my signal is complex. You'll want the magnitudes of the complex numbers. Actually the squares of the magnitudes (assuming the data from the oscilloscope represents voltages), because you're after a ratio of powers. -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: mutable ints: I think I have painted myself into a corner
Cameron Simpson wrote: It's an int _subclass_ so that it is no bigger than an int. If you use __slots__ to eliminate the overhead of an instance dict, you'll get an object consisting of a header plus one reference, which is probably about the size of an int. But you'll also need an int to put in that slot, so the total size will be about twice that of an int. Another approach would be to subclass array.array and give instances of it type integer and size 1. Together with empty __slots__, it will probably be a bit bigger than an int, but it might still be smaller than a custom object plus an int. If all of these are still too big, you might need to find some way of packing multiple instances into a single array.array. -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: A computer programmer, web developer and network admin resume
Tim Chase wrote: So a pirate programmer walks into a bar with a bird on his shoulder. The bird repeatedly squawks "pieces of nine! pieces of nine!". The bartender looks at him and asks "what's up with the bird?" to which the pirate says "Arrr, he's got a parroty error." No, he's just using half-open ranges. -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: grimace: a fluent regular expression generator in Python
Ben Last wrote:
north_american_number_re = (RE().start
.literal('(').followed_by.__exactly(3).digits.then.__literal(')')
.then.one.literal("-").then.__exactly(3).digits
.then.one.dash.followed_by.__exactly(4).digits.then.end
.as_string())
Is 'dash' the same as 'literal("-")'?
Is there any difference between 'then' and 'followed_by'?
Why do some things have __ in front of them? Is there a
difference between 'literal' and '__literal'?
--
Greg
--
http://mail.python.org/mailman/listinfo/python-list
Re: how: embed + extend to control my running app?
David M. Cotter wrote: For Mac, I understand i need to "create" (?) a python.dylib, If your Python was installed as a framework, you should already have one. Just link your application with "-framework Python". Now for Windows: same thing, i think i must create a .dll, right? Again, you should already have a python.dll in your installation somewhere. -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: Multi-dimensional list initialization
Roy Smith wrote: Call by social network? The called function likes the object. Depending on how it feels, it can also comment on some of the object's attributes. And then finds that it has inadvertently shared all its private data with other functions accessing the object. -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: Multi-dimensional list initialization
If anything is to be done in this area, it would be better as an extension of list comprehensions, e.g. [[None times 5] times 10] which would be equivalent to [[None for _i in xrange(5)] for _j in xrange(10)] -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: Coordination between developers in the Python project
Ian Kelly wrote: Although I find it a bit easier to just use something like unshorten.com, which is the first Google hit for "url unshortener". Assuming that you trust that site to not be hosting malware itself. :-) Ah yes, beware the Hungarian unshortening service that redirects every request to a random porn page. They will plead incompetence, of course. -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: Obnoxious postings from Google Groups
Steven D'Aprano wrote: The downside is that if spaces are not argument separators, then you need something else to be an argument separator. Or you need argument delimiters. Or strings need to be quoted. Programming languages do these things because they are designed to be correct. Shell do not because they are designed for lazy users and merely aim to be "good enough". That's overly judgemental. In the environment where shells originated, not being able to easily put spaces in file names wasn't considered a problem. File names weren't thought of as names in the natural language sense, but as identifiers in the programming sense. You don't complain that you can't put spaces in identifiers in a Python program, do you? No, because that would require all identifiers to be quoted somehow, which would drive you crazy. In the same way, requiring all filenames to be quoted would drive shell users crazy. -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: How to pass class instance to a method?
ALeX inSide wrote: I suppose there shall be some kind of method decorator to treat an argument as an > instance of class? You can do this: xxx = MyClass.some_method and then i = MyClass() xxx(i, foo, bar) Does that help? -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: The Zen of Zope, by Alex Clark
Steven D'Aprano wrote: On Sun, 09 Dec 2012 20:13:43 -0500, Alex Clark wrote: > The Zen of Zope, by Alex Clark I expect that I would find that hilarious if I knew anything about Zope :) It's probably a good thing I don't know much about Zope, because I'm already finding it hilarious. If I knew more, the hilarity level might become physically dangerous. -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: float("nan") in set or as key
Steven D'Aprano wrote: def kronecker(x, y): if x == y: return 1 return 0 This will correctly consume NAN arguments. If either x or y is a NAN, it will return 0. I'm far from convinced that this result is "correct". For one thing, the Kronecker delta is defined on integers, not reals, so expecting it to deal with NaNs at all is nonsensical. For another, this function as written is numerically suspect, since it relies on comparing floats for exact equality. But the most serious problem is, given that NAN is a sentinel for an invalid operation. NAN + NAN returns a NAN because it is an invalid operation, if kronecker(NaN, x) or kronecker(x, Nan) returns anything other than NaN or some other sentinel value, then you've *lost* the information that an invalid operation occurred somewhere earlier in the computation. You can't get a valid result from data produced by an invalid computation. Garbage in, garbage out. not because NANs are magical goop that spoil everything they touch. But that's exactly how the *have* to behave if they truly indicate an invalid operation. SQL has been mentioned in relation to all this. It's worth noting that the result of comparing something to NULL in SQL is *not* true or false -- it's NULL! -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: Something is rotten in Denmark...
Alain Ketterlin wrote: But going against generally accepted semantics should at least be clearly indicated. Lambda is one of the oldest computing abstraction, and they are at the core of any functional programming language. Yes, and Python's lambdas behave exactly the *same* way as every other language's lambdas in this area. Changing it to do early binding would be "going against generally accepted semantics". It's not the lambda that's different from other languages, it's the for-loop. In languages that encourage a functional style of programming, the moral equivalent of a for-loop is usually some construct that results in a new binding of the control variable each time round, so the problem doesn't arise very often. If anything should be changed here, it's the for-loop, not lambda. -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: float("nan") in set or as key
Steven D'Aprano wrote: Fair point. Call it an extension of the Kronecker Delta to the reals then. That's called the Dirac delta function, and it's a bit different -- instead of a value of 1, it has an infinitely high spike of zero width at the origin, whose integral is 1. (Which means it's not strictly a function, because it's impossible for a true function on the reals to have those properties.) You don't normally use it on its own; usually it turns up as part of an integral. I find it difficult to imagine a numerical algorithm that relies on directly evaluating it. Such an algorithm would be numerically unreliable. You just wouldn't do it that way; you'd find some other way to calculate the integral that avoids evaluating the delta. y = 2.1e12 if abs(x - y) <= 1e-9: # x is equal to y, within exact tolerance ... If you expect your numbers to be on the order of 1e12, then 1e-9 is obviously not a sensible choice of tolerance. You don't just pull tolerances out of thin air, you justify them based on knowledge of the problem at hand. In practice, either the function needs some sort of "how to decide equality" parameter, If it's general purpose library code, then yes, that's exactly what it needs. or you use exact floating point equality and leave it up to the caller to make sure the arguments are correctly rounded Not really a good idea. Trying to deal with this kind of thing by rounding is fraught with difficulties and pitfalls. It can only work when you're not really using floats as approximations of reals, but as some set of discrete values, in which case it's probably safer to use appropriately-scaled integers. - from William Kahan, and the C99 standard: hypot(INF, x) is always INF regardless of the value of x, hence hypot(INF, NAN) returns INF. - since pow(x, 0) is always 1 regardless of the value of x, pow(NAN, 0) is also 1. These are different from your kronecker(), because the result *never* depends on the value of x, whether it's NaN or not. But kronecker() clearly does depend on the value of x sometimes. The reasoning appears to be based on the idea that NaN means "some value, we just don't know what it is". Accepting that interpretation, the argument doesn't apply to kronecker(). You can't say that the NaN in kronecker(NaN, 42) doesn't matter, because if you don't know what value it represents, you can't be sure that it *isn't* meant to be 42. Another standard example where NANs get thrown away is the max and min functions. The latest revision of IEEE-754 (2008) allows for max and min to ignore NANs. Do they provide a justification for that? I'm having trouble seeing how it makes sense. -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: Something is rotten in Denmark...
Alain Ketterlin wrote: You must be kidding. Like many others, you seem to think that Scheme is a typical functional language, which it is not. I never said that Scheme is a functional language -- I'd be the first to acknowledge that it's not. I do know what real functional languages are like. However, Scheme is more relevant to this discussion than Haskell, precisely because it's *not* purely functional -- it does allow existing bindings to be changed. Yet its lambdas are late-binding, and nobody seems to get tripped up by that they way they do in Python. Why not? It's because Scheme encourages a style of programming which favours creation of new bindings rather than changing existing ones, so most of the time the bindings captured by a lambda don't change later. -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: how to avoid leading white spaces
Chris Torek wrote: Python might be penalized by its use of Unicode here, since a Boyer-Moore table for a full 16-bit Unicode string would need 65536 entries But is there any need for the Boyer-Moore algorithm to operate on characters? Seems to me you could just as well chop the UTF-16 up into bytes and apply Boyer-Moore to them, and it would work about as well. -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: Generator Frustration
Steven D'Aprano wrote: A nice piece of syntax that has been proposed for Python is "yield from", which will do the same thing, but you can't use that yet. Unless you're impatient enough to compile your own Python with my patch applied: http://www.cosc.canterbury.ac.nz/greg.ewing/python/yield-from/yield_from.html -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: how to inherit docstrings?
IMO, it shouldn't be necessary to explicitly copy docstrings around like this in the first place. Either it should happen automatically, or help() should be smart enough to look up the inheritance hierarchy when given a method that doesn't have a docstring of its own. Unfortunately, since unbound methods were ditched, help(Foo.blarg) no longer has an easy way to find the base classes, so help from the compiler may be needed. -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: Any Better logic for this problem..
Chris Angelico wrote: Rather than find all prime numbers up to num, stop at sqrt(num) - it's not possible to have any prime factors larger than that. That's not quite true -- the prime factors of 26 are 2 and 13, and 13 is clearly greater than sqrt(26). However, once you've divided out all the primes up to sqrt(n), whatever is left, if greater than 1, must itself be prime, so you can add it to your prime factors and stop. -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: how to inherit docstrings?
Carl Banks wrote: Presumably, the reason you are overriding a method in a subclass is to change its behavior; Not always true by any means, and maybe not even usually true. Consider overriding for the purpose of implementing an abstract method, or because something about the internal operation of a method needs to be modified to suit the requirements of the subclass. I have a lot of situations like this in PyGUI, where there is a bunch of generic classes defining the public API, and subclasses of them for each implementation (Cocoa, Gtk and Windows). There are heaps and heaps of overridden methods in the implementation classes, and very few of them need or should have a docstring different from the generic one. Not automatically inheriting the docstrings puts a big burden on the maintainer to keep all of them in sync. -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: how to inherit docstrings?
Carl Banks wrote: x = random.choice([Triange(),Square()]) print x.draw.__doc__ # prints "Draws a shape" Quick, what shape is x.draw() going to draw? Your debugging code is insufficient. It should include print type(x) and then it will be obvious what shape is going to get drawn. -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: __doc__ immutable for classes (was: Re: how to inherit docstrings?)
Eric Snow wrote: But for "method" objects (really a wrapper for bound functions) would it change the __doc__ of the wrapper or of the bound function? You probably wouldn't want to change the __doc__ of a method wrapper; instead you'd make sure you got hold of the underlying function first. So __doc__ on method wrappers should probably remain read-only to avoid surprises. -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: Function declarations ?
Steven D'Aprano wrote: "Hoisting" in computing refers to the idea of "lifting" variables or code outside of one block into another. I'm not sure it's the right term for what's happening here, though. Nothing is being lifted to a higher level -- the functions remain at the same level they were written at. Here's another model: Pascal. Because Pascal does type checking at compile time, it will reject the function ham() and raise a compiler error, It's more that Pascal is designed to make single-pass compilation easy. It's possible to support out-of-order declarations with compile-time type checking using two passes; Pyrex does this, for example. -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: Keyboard Layout: Dvorak vs Colemak: is it Worthwhile to Improve the Dvorak Layout?
Chris Angelico wrote: And did any of the studies take into account the fact that a lot of computer users - in all but the purest data entry tasks - will use a mouse as well as a keyboard? What I think's really stupid is designing keyboards with two big blocks of keys between the alphabetic keys and the mouse. Back when standard-grade keyboards didn't usually have a built-in numeric keypad, it was much easier to move one's right hand back and forth between the keyboard and mouse. Nowadays I find myself perpetually prone to off-by-one errors when moving back to the keyboard. :-( -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: Function declarations ?
Tim Roberts wrote: Andre Majorel wrote: Anyway, it seems the Python way to declare a function is def f (): pass No, that DEFINES a function. Actually, it's more illuminating to say that it *creates* a function. The 'def' statement in Python is an executable statement. Executing it has the effect of creating a function object and binding it to the indicated name. Before that has happened, attempting to execute any code referring to that name will fail. Conversely, the function name doesn't need to be bound until the code referring to it is actually executed. So... def g(): return f() def f(): return 3 print g() works because by the time g is *called*, both def statements have been executed, and both function names have therefore been bound. -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: How do you copy files from one location to another?
John Salerno wrote: I want it to copy a set of files/directories from a location on my C:\ drive to another directory on my E:\ drive. I don't want to rename or delete the originals, It sounds like shutil.copy() is what you want, or one of the other related functions in the shutil module. -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: ANN: PyGUI 2.5
Wolfgang Keller wrote: Any chance to see a hierarchical multi-column TreeListView anytime soon? There may be a table view, but I can't promise anything about a tree view, sorry. -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: ANN: PyGUI 2.5
Terry Reedy wrote: Greg left out the most important to me: "Now works with Python 3 on MacOSX and Windows!" I'm not making too much of that at the moment, because it *doesn't* work on Linux yet, and I've no idea how long it will be before it does. The issue is that there will apparently not be any Python 3 version of pygtk, on the grounds that gobject introspection can be used instead. Unfortunately, Gtk 3 and related libraries don't quite handle gobject introspection well enough to support PyGUI at the moment. -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: Strategy to Verify Python Program is POST'ing to a web server.
Michael Hrivnak wrote: Besides, it seems that all you've accomplished is verifying that the client can execute python code and you've made it a bit less convenient to attack. And that only if the attacker isn't a Python programmer. If he is, he's probably writing his attack program in Python anyway. :-) Although if you were devious, and you detected that such an attack was in progress, you could lull him into a sense of security and then send him some Python code to pwn his machine... -- Greg -- http://mail.python.org/mailman/listinfo/python-list
ANN: PyGUI 2.5.1
PyGUI 2.5.1 is available: http://www.cosc.canterbury.ac.nz/greg.ewing/python_gui/ Minor update to fix missing distutils_extensions.py file. What is PyGUI? -- PyGUI is a cross-platform GUI toolkit designed to be lightweight and have a highly Pythonic API. -- Gregory Ewing greg.ew...@canterbury.ac.nz http://www.cosc.canterbury.ac.nz/greg.ewing/ -- http://mail.python.org/mailman/listinfo/python-list
Re: those darn exceptions
Chris Torek wrote: Oops! It turns out that os.kill() can raise OverflowError (at least in this version of Python, not sure what Python 3.x does). Seems to me that if this happens it indicates a bug in your code. It only makes sense to pass kill() something that you know to be the pid of an existing process, presumably one returned by some other system call. So if kill() raises OverflowError, you *don't* want to catch and ignore it. You want to find out about it, just as much as you want to find out about a TypeError, so you can track down the cause and fix it. Generally I think some people worry far too much about anticipating and catching exceptions. Don't do that, just let them happen. If you come across a *specific* exception that it makes sense to catch, then catch just that particular one. Let *everything* else propagate. -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: those darn exceptions
Chris Torek wrote: I can then check the now-valid pid via os.kill(). However, it turns out that one form of "trash" is a pid that does not fit within sys.maxint. This was a surprise that turned up only in testing, and even then, only because I happened to try a ridiculously large value as one of my test cases. It appears that this situation is not unique to os.kill(), for example, >>> import os >>> os.read(, 42) Traceback (most recent call last): File "", line 1, in OverflowError: Python int too large to convert to C long In fact I'd expect it to happen any time you pass a very large int to something that's wrapping a C function. You can't really blame the wrappers for this -- it's not reasonable to expect all of them to catch out-of-range ints and do whatever the underlying function would have done if it were given an invalid argument. I think the lesson to take from this is that you should probably add OverflowError to the list of things to catch whenever you're calling a function with input that's not fully validated. -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: The end to all language wars and the great unity API to come!
The place where this "Unity API" idea of yours falls down is that an API is only truly easy to use when it's designed to closely match the characteristics of the language it's being used from. For example, Python has a very powerful feature that most other languages don't have anything remotely like: very flexible keyword arguments. A truly Pythonic API will take advantage of them wherever it makes sense. An extreme example is PyGUI, where you can write things like win = Window(title = "Fred", width = 300, height = 100, position = (30, 50), movable = True, resizable = True) In fact, almost *any* attribute of any PyGUI object can be specified using keyword arguments in the constructor. In your typical C or C++ based API, either you have a constructor taking a zillion positional parameters that all have to be in the right order, or you have to set all the attributes individually afterwards: win = Window() win.title = "Fred" win.width = 300 win.height = 100 win.position = (30, 50) win.movable = True win.resizable = True Either way you end up with an API that feels very awkward when used from Python. -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: The end to all language wars and the great unity API to come!
rantingrick wrote: Ruby: for x in blah: blah_blah_blah Python: for x in blah: blah_blah_blah Here you're making the mistake of thinking that surface syntax is all that matters. Although the 'for' statements in Python and Ruby look very similar, underneath they're based on quite different mechanisms. They're not equivalent: the Python way leads to various powerful things such as generators; the Ruby way lends itself more to user-defined control structures. -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: The end to all language wars and the great unity API to come!
Chris Angelico wrote: Your proposed "Unity API" (which I assume has nothing to do with Natty Narwhal's preferred interface) already exists. It's the C language. Or maybe GObject Introspection is closer to what you have in mind? A library that supports GI advertises enough information about itself for dynamic languages such as Python and Ruby to automatically construct fairly object-oriented interfaces. It's not perfect, though; for example, the old PyGtk module used to let you access most of what Gtk calls "properties" using Python attribute access, but with GI you have to call the get_property and set_property functions. Also you often can't just call a class to construct an object, but have to call a separate constructor function instead. -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: Why won't this decorator work?
Ian Kelly wrote: If it's not a callable, then the result will just be that something non-callable is bound to the "roll_die" name -- which could be useful, but is probably a bad idea in general. There are legitimate uses -- for example, the following is a convenient way of creating a read-only property: @property def foo(self): return self.calculate_value_of_foo() -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: The end to all language wars and the great unity API to come!
rantingrick wrote: I agree however i see merit in both approaches. But why must we have completely different languages just for that those two approaches? We have different languages because different people have different ideas about what a language should be like. Ruby people like user defined control structures; Python people regard user defined control structures as an anti-feature. It's fundamentally impossible for one language to satisfy both sets of people. -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: Why won't this decorator work?
OKB (not okblacke) wrote: A decorator basically modifies a function/method, so that ALL subsequent calls to it will behave differently. Furthermore, usually a decorator is used when for some reason you *can't* achieve the same effect with code inside the function itself. For example, the classmethod() and staticmethod() decorators return descriptors that have different magical effects from a standard function object when looked up in a class or instance. Since that magic happens *before* the function is called, you can't do the same thing using an ordinary function. In this case, an ordinary function is quite sufficient, and there is no need to involve a decorator. -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: Implicit initialization is EVIL!
rantingrick wrote: Unlike most GUI libraries the Tkinter developers thought is would "just wonderful" if the root GUI window just sprang into existence if the programmer "somehow" forgot to create one. IMO the real problem here is the existence of a privileged "root" window at all. No GUI platform I know of has any such concept (except for a "desktop" window that represents the whole screen, which is not the same thing). All top-level windows should have equal status. -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: Virtual functions are virtually invisible!
rantingrick wrote: what concerns me is the fact that virtual methods in derived classes just blend in to the crowd. I think we really need some sort of visual cue in the form of forced syntactical notation (just like the special method underscores). If you're suggesting that it should be impossible to override a method unless it is specially marked somehow in the base class, I think that would be a bad idea. One of the principles behind the design of Eiffel is that classes should *always* be open to modification in any way by a subclass. The reason is that the author of a class library can't anticipate all the ways people might want to use it. Consequently Eiffel has no equivalent of C++'s "private" declaration -- everything is at most "protected". It also has no equivalent of Java's "final". I like the fact that Python doesn't have these either. -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: Problem!!
TheSaint wrote: On 4-7-2011 1:41, amir chaouki wrote: No, I misplaced my crystal ball. I'm waiting mine, brand new in HD :D, with remote control :D :D The new digital models are great. But there's a distressing tendency for visions to come with DRM protection these days, so you can only share them with at most 5 other users. :-( -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: Implicit initialization is EVIL!
rantingrick wrote: You say "root" windows are bad however any parent-child relationship has to BEGIN somewhere. There's no need for *toplevel* windows to be children of anything, though. HOWEVER any of the windows ARE in fact instances of Tk.Toplevel[1]. So they ARE all equal because they all have the same methods available to them. No, they're not -- the root window is special, because if you kill it, the whole application exits. Often that is inconvenient. -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: Implicit initialization is EVIL!
rantingrick wrote: Most applications consist of one main window (a Tkinter.Tk instance). You've obviously never used a Macintosh. On the Mac, it's perfectly normal for an application to open multiple documents, each in its own window, with no one window being the "main" window. Any of them can be closed (or even *all* of them) and the application continues to run until you explicitly quit it. -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: Implicit initialization is EVIL!
rantingrick wrote: What he means is that On Mac, if you close "all" windows, the application is still running. Then that is NOT closing windows that is only ICONIFIYING/HIDING them. No, the windows really are closed. They no longer exist in any way. The application is still running, though, and its menu bar will appear if you bring it to the front (in MacOSX this is done by clicking on its dock icon; in classic MacOS it was done by selecting from the menu of running applications that was available in the top right corner of the screen). -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: Implicit initialization is EVIL!
rantingrick wrote: And how do you EXPLICITY quit the application? Using its "Quit" menu command. But that's Mac-specific, and not central to the discussion. On Linux and Windows, an application will usually exit when its last window is closed. Either way, there is no need for a privileged main window. -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: The end to all language wars and the great unity API to come!
rantingrick wrote: I was thinking more about this comment and it occurred to me that Python does have user controlled data structures. Just because there is no "top level syntax" like ruby does not mean these do not exists. Syntax is what it's really about, though. There's no clear dividing line, but when Guido says he's opposed to "user defined syntax" he's talking about things like Lisp macros, which let you effectively extend the grammar with new keywords and syntactic structures. Compared to that, Python's grammar is very much fixed. Anything you want to do has to be done within the existing framework of function calls, attribute references etc. If Python truly had user-defined syntax, it wouldn't have been necessary to modify the compiler to implement features such as list comprehensions and with-statements -- those features could have been implemented, with the *same syntax* or something close to it, in the base language. -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: The end to all language wars and the great unity API to come!
rantingrick wrote: Something to replace Python, Ruby, Perl, JavaScript, etc, etc not some "pie-in-the-sky", "single-answer-to-all- our-problems" pipe dream language. So it's just a "single-answer-to-all-our-glue-programming" pipe dream language, then? :-) -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: Implicit initialization is EVIL!
rantingrick wrote:
Yes but what benefit does that gain over say, Tkinter's design
(because that has been your argument).
Like I said, it's a tangential issue.
The important thing is that it's okay for an app to stay
alive until its *last* top level window is closed. There
doesn't have to be a special "main" window that kills the
whole app when you close it.
However, I think what the original complaint was really
about is that when you create a non-toplevel widget in Tkinter
you have to specify its parent (and if you don't, it assumes
you want it to be a child of the main window). You can't
create the widget first and specify its parent later.
This is another API flaw that is seen distressingly often
in GUI libraries. It's a nuisance, because it means you can't
write code that creates a widget hierarchy bottom-up. For
example, in PyGUI you can write things like
dialog_contents = Column([
Label("Caution: Your underpants are on fire."),
Row([Button("OK"), Button("Cancel")])
])
There's no way you could write Row and Column functions for
Tkinter that work like that -- they would have to take parent
widgets as arguments, and you wouldn't be able to nest the
calls.
--
Greg
--
http://mail.python.org/mailman/listinfo/python-list
Re: wx MenuItem - icon is missing
Philip Semanchuk wrote: I can understand why it's frustrating but a menu items with icons on them aren't exactly common... Now that I think about it, I don't know that I've ever seen one under OSX, and I don't even know if it's supported at all. It's supported -- I've got FruitMenu running at the moment and it makes fairly heavy use of them. I agree that they don't seem to be used much anywhere else these days, though. -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: Implicit initialization is EVIL!
rantingrick wrote: So you prefer to close a gazillion windows one by one? If I want to close all the windows, I can use the application's "Quit" or "Exit" command, or whatever the platform calls it. (Note that if there is a separate instance of the application for each window -- as was suggested earlier -- then you don't have that option, and you have to close them one by one anyway.) There's no way you could write Row and Column functions for Tkinter that work like that -- they would have to take parent widgets as arguments, and you wouldn't be able to nest the calls. WRONG! A function or class structure can handle this just fine. class DumbDialog(tk.Toplevel): def __init__(self, master, **kw): w=tk.Label(master, text="Caution: Your underpants are on fire.") w.pack() w=tk.Button(master, text="OK").pack() w=tk.Button(master, text="Cancel").pack() Which is *exactly* what I said you would have to do in Tkinter! Each widget creation requires a separate statement, with the parent passed in at each step. This is nowhere near as convenient as the nested function call style. -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: Wgy isn't there a good RAD Gui tool fo python
Chris Angelico wrote: either brain something'd (keeping this G-rated) or an orangutan, There's a certain librarian who might take issue with your lumping orangutans in with the brain-something'd... -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: Lisp refactoring puzzle
Xah Lee wrote: they don't provide even simple list manipulation functions such as union, intersection, and the like. Not in perl, not in python, not in lisps. Since 2.5 or so, Python has a built-in set type that provides these (which is arguably a better place for them than lists). -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: Lisp refactoring puzzle
Teemu Likonen wrote: Please don't forget that the whole point of Lisps' (f x) syntax is that code is also Lisp data. It's possible to design other syntaxes that have a similar property. Prolog, for example -- a Prolog program is expressed in terms of Prolog data structures, yet it manages to have things that look like fairly normal function calls and infix expressions. -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: Functional style programming in python: what will you talk about if you have an hour on this topic?
Anthony Kong wrote: So I have picked this topic for one of my presentation. It is because functional programming technique is one of my favorite in my bag of python trick. I'm not sure it's a good idea to emphasise functional programming too much. Python doesn't really lend itself to a heavily functional style. While you *can* write Python code that way, it's not idiomatic, and you're likely to give beginners a distorted idea of how Python is normally written. -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: None versus MISSING sentinel -- request for design feedback
Ethan Furman wrote: some of the return values (Logical, Date, DateTime, and probably Character) will have their own dedicated singletons (Null, NullDate, NullDateTime, NullChar -- which will all compare equal to None) That doesn't seem like a good idea to me. It's common practice to use 'is' rather than '==' when comparing things to None. Why do you want to use special null values for these types? -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs -vs- Spaces: Tabs should have won.
Anders J. Munch wrote: > Cameron Simpson wrote: >> Personally, I like to use the tab _key_ as an input device, but to have >> my editor write real spaces to the file in consequence. Just like in the old days:) Most editors can be configured to do that. Where they fall down, in my experience, is that having inserted those spaces, if you want to delete them you typically have to backspace over them one at a time. I don't enjoy that experience, which is why I have BBEdit Lite set up to use tab-only indentation. If I'm feeling conscientious, I convert to spaces before sharing the code with others. But tabs work better for me given the tools I use and the way I like to work. -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs -vs- Spaces: Tabs should have won.
Steven D'Aprano wrote: Why 78? Because it's one less than 79, as mandated by PEP 8, and two less than 80, the hoary old standard. There's another possible reason for the number 78, although hopefully it doesn't still apply today. There's an application I work with that stores free text in database records of 78 chars each. I suspect it's because early versions go back to the MS-DOS era, when it was common to make windows out of box-drawing characters. 80 columns minus two border chars equals 78! -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: I am fed up with Python GUI toolkits...
sturlamolden wrote: Or should modern deskop apps be written with something completely different, such as HTML5? I hope not! HTML is great for web pages, but not everything should be a web page. -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: I am fed up with Python GUI toolkits...
Andrew Berg wrote: It has quite a few external dependencies, though (different dependencies for each platform, so it requires a lot to be cross-platform). I think that's a bit of an exaggeration -- there's only one major dependency on each platform, and it's a very widely used one (currently PyObjC/PyGTK/PyWin32). And I'm thinking about ways to reduce the dependencies further, -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: I am fed up with Python GUI toolkits...
Tim Roberts wrote: Gregory Ewing wrote: sturlamolden wrote: Or should modern deskop apps be written with something completely different, such as HTML5? I hope not! HTML is great for web pages, but not everything should be a web page. I don't think your glibness is justified. There is a legitimate appeal to this notion. The fact is that MANY APIs can be completely and adequately described by HTML. My brain raises a TypeError on that statement. According to my understanding of the world, describing APIs is not something that HTML does. (Or did you mean GUI rather than API?) There might be some sense in using something HTML-like to describe the layout of widgets in a GUI. But laying out widgets is only a tiny part of what's involved in creating an application with a GUI. You still need a GUI toolkit to provide the widgets being laid out, and application code behind that to provide the desired functionality. With style sheets, you can get very complete control over the look and feel. CSS is designed for graphic artists who want complete control over every aspect of appearance. Again, this is (arguably) okay for web pages, but I don't think it applies to GUI applications. You *don't* want every application looking completely different from every other on the whim of the author -- quite the opposite. -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: I am fed up with Python GUI toolkits...
John Nagle wrote: There's PyGUI, which, at a glance, fits whit what you want. Looks like it uses OpenGL and native GUI facilities. http://www.cosc.canterbury.ac.nz/greg.ewing/python_gui/ It still uses Tcl/Tk stuff, which is un-Pythonic. You must be thinking of something else. My PyGUI has nothing to do with Tcl/Tk at all. -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: Convert '165.0' to int
Frank Millman wrote: I know I am flogging a dead horse here, but IMHO, '165', '165.', '165.0', and '165.00' are all valid string representations of the integer 165.[1] Therefore, for practical purposes, it would not be wrong for python's 'int' function to accept these without complaining. How far would you go with that? Would you also accept '1.65e2' as a valid representation of the integer 165? -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: NoneType and new instances
Steven D'Aprano wrote: As for True and False, bool has to be able to return them, because the whole purpose of exposing bool is so people can call it: if bool(some_value) was an error, that would defeat the purpose of having bool! Bool is different, because it doubles as a function for coercing things to bool. There's no corresponding concept of coercing something to None, or Ellipsis, etc. -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: What is xrange?
Brian Blais wrote: On Jul 29, 2011, at 9:22 PM, Steven D'Aprano wrote: Billy Mays wrote: Is xrange not a generator? I know it doesn't return a tuple or list, so what exactly is it? It's an iterable object. There are advantages in having xrange (or range in python3) return an iterable object, rather than creating an iterator directly. One of them is that you can iterate over the same object more than once. This can be useful if you're iterating over a multi-dimensional space of some kind. Some efficiency can be gained by pre-creating an xrange object for each of the inner loops and re-using them. -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: PEP 8 and extraneous whitespace
OKB (not okblacke) wrote: You don't need to include extraneous whitespice to get it to line up ^^ +1 on Python 4 providing whitespice. Should liven things up nicely. :-) -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: What's in a name?
Andrew Berg wrote: Well of course. All the good names are taken. :P I even came up with cavelib and it was taken ( http://www.mechdyne.com/cavelib.aspx ). A couple of ideas that don't seem to turn up anything software-related: Flummux Flavius -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: Deeply nested dictionaries - should I look into a database or am I just doing it wrong?
Andrew Berg wrote: I have a method that writes the data to disk, but at this point, I don't see any problems with just pickling the class instance. Just keep in mind that if you're not careful, pickles can end up being tied more closely that you would like to various internal details of your program, such as the precise names of the classes involved and which modules they live in. -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: Spam
Chris Rebert wrote: On Sun, Jul 31, 2011 at 9:56 PM, Ghodmode wrote: I'm wondering how the list is managed. Can anyone post, or only members? Since we're gatewayed to USENET's comp.lang.python anyway, I'd strongly suspect the former. You may get a better experience by reading the usenet group instead, and doing it through a good news site. I'm using news.individual.de, and seeing near enough to zero spam on comp.lang.python, so they must be doing a good job of filtering. -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: os.path.dirname(sys.argv[0]) always returns nothing
Thijs Engels wrote: argv[0] returns the name of the current file (string), but no path information if I recall correct. It's the path that was used to specify the script by whatever launched it, so it could be either absolute or relative to the current directory. -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: Syntactic sugar for assignment statements: one value to multiple targets?
gc wrote: Alternatively, is there a version of iterable multiplication that creates new objects rather than just copying the reference? You can use a list comprehension: a, b, c, d, e = [dict() for i in xrange(5)] or a generator expression: a, b, c, d, e = (dict() for i in xrange(5)) -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: WxPython and TK
azrael wrote: If I would have gotten a dollar for every time I talked to someone in a company about why they dont use python for their products and I was served the answer "Well it kind of sucks in GUI development", I would be a millionaire. Even assuming that Python + wxPython sucks less than Python + Tkinter (which is a matter of opinion), putting wxPython in the standard library would change very little. Anyone who wants to is already free to use wxPython now. -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: allow line break at operators
Chris Angelico wrote: But both of these violate XKCD 859. For the benefit of all those who just went off to read that strip, here's something to help you unwind: ) There, you can relax now. -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: Ten rules to becoming a Python community member.
rantingrick wrote: "Used to" and "supposed to" is the verbiage of children and idiots. So when we reach a certain age we're meant to abandon short, concise and idomatic ways of speaking, and substitute long words and phrases to make ourselves sound adult and educated? -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: allow line break at operators
Steven D'Aprano wrote: I'm reminded of this quote from John Baez: "...But the octonions are the crazy old uncle nobody lets out of the attic: they are nonassociative." (And don't even ask about the sedenions...) Aren't they the ones that mutilate cattle and abduct people? -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: Ten rules to becoming a Python community member.
I don't mind people using e.g. and i.e. as long as they use them *correctly*. Many times people use i.e. when they really mean e.g. -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: surprising interaction between function scope and class namespace
Peter Otten wrote: LOAD_NAME is pretty dumb, it looks into the local namespace and if that lookup fails falls back to the global namespace. Someone probably thought "I can do better", and reused the static name lookup for nested functions for names that occur only on the right-hand side of assignments in a class. I doubt that it was a conscious decision -- it just falls out of the way the compiler looks up names in its symbol table. In case 1, the compiler finds the name 'a' in the function's local namespace and generates a LOAD_FAST opcode, because that's what it does for all function-local names. In case 2, it finds it in the local namespace of the class and generates LOAD_NAME, because that's what it does for all class-local names. The weirdness arises because classes make use of vestiges of the old two-namespace system, which bypasses lexical scoping at run time. -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: Replacement for the shelve module?
Robert Kern wrote: That's just incorrect. You shouldn't use (binary) floats for many *accounting* purposes, but for many financial/econometric analyses, floats are de rigeur and work much better than decimals There's a certain accounting package I work with that *does* use floats -- binary ones -- for accounting purposes, and somehow manages to get away with it. Not something I would recommend trying at home, though. -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: PC locks up with list operations
Steven D'Aprano wrote:
As far as I know, ulimit ("user limit") won't help. It can limit the amount
of RAM available to a process, but that just makes the process start using
virtual memory more quickly.
ulimit -v is supposed to set the maximum amount of virtual
memory the process can use.
It can also limit the amount of virtual memory
used by the shell, but not of other processes.
That doesn't sound right. Not sure about Linux, but the
man page for sh on Darwin says:
Provides control over the resources available to the shell and
to processes started by it, on systems that allow such control.
The Python process should also be able to set its own
limits using resource.setrlimit().
--
Greg
--
http://mail.python.org/mailman/listinfo/python-list
Re: Handling 2.7 and 3.0 Versions of Dict
Ian Kelly wrote:
if sys.version_info < (3,):
getDictValues = dict.itervalues
else:
getDictValues = dict.values
(which is basically what the OP was doing in the first place).
And which he seemed to think didn't work for some
reason, but it seems fine as far as I can tell:
Python 2.7 (r27:82500, Oct 15 2010, 21:14:33)
[GCC 4.2.1 (Apple Inc. build 5664)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> gv = dict.itervalues
>>> d = {1:'a', 2:'b'}
>>> gv(d)
% python3.1
Python 3.1.2 (r312:79147, Mar 2 2011, 17:43:12)
[GCC 4.2.1 (Apple Inc. build 5664)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> gv = dict.values
>>> d = {1:'a', 2:'b'}
>>> gv(d)
dict_values(['a', 'b'])
--
Greg
--
http://mail.python.org/mailman/listinfo/python-list
Re: Detecting Ctrl-Alt-Del in Windows
On Thu, 01 Sep 2011 08:52:49 -0700, Den wrote: Also, is there a corresponding key-sequence in Mac and Linux? The nearest equivalent in MacOSX is Command-Option-Escape, which brings up the force-quit dialog. I don't know how deep down in the system it's implemented. It's possible to use SetSystemUIMode to put an app into a "kiosk mode" where force-quitting is disabled, but I don't know whether the app can intercept Command-Option-Escape in that situation and do something else with it. -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: Detecting Ctrl-Alt-Del in Windows
Chris Angelico wrote: Although I heard somewhere that that's more gimmick than guarantee, and that it IS possible for an app to hook CAD - just that it's a lot harder than building a simple window that looks like the login... And of course it's possible that someone has snuck in during the night and installed Linux on the machine, with a program that fakes a Windows login screen, with Ctrl-Alt-Delete and everything... -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter: The good, the bad, and the ugly!
[Sorry to revive an old thread, but I was away when it occurred and I'd like to make a comment...] Kevin Walzer wrote: This library isn't much different from other Python GUI toolkits--it's dependent on underlying, rather large, platform-specific implementations--but it provides an even higher level of abstraction. On the Mac, it is dependent on PyObjC; on Windows, pywin32; and on X11, pygtk. In short, it's a wrapper over other wrappers. PyGUI differs from the likes of wxPython and PyQT in that the things it depends on are mainly just Python bindings for native facilities already present on the platform. This is an issue because of the number of API translations involved. WxWidgets and Qt are themselves cross-platform libraries that present quite a different API from the platform. The Python bindings for them just expose that API to Python, resulting in something that is not very Pythonic. To fix that, you would need another layer on top, resulting in *two* API translations. Each time such a translation occurs, something gets lost. PyGUI is designed to minimise the loss by building a Pythonic API directly on the platform API. To me, this is the most important thing. Minimising the size of third-party dependencies is also a goal, but it's secondary, and can be addressed in various ways later, such as by using ctypes or custom extension modules. Getting the API right, and proving that it can be implemented with acceptable quality on all the target platforms, are the first priorities. -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: move to end, in Python 3.2 Really?
Raymond Hettinger wrote: The existing list.pop() API is similar (though it takes an index value instead of a boolean): mylist.pop() # default case: pop from last mylist.pop(0) # other case:pop from first pop() is somewhat different, because there is an infinite range of possible values for the index parameter. Here there are only two possibilites, though, and it's unlikely that code will want to dynamically select between them -- so the "no constant parameters" guideline would seem to apply. -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: WxPython versus Tkinter.
rantingrick wrote: All we have to do is create an abstraction API that calls wxPython until we can create OUR OWN wxPython from WxWidgets. There seems to be at least one other project around like that: http://dabodev.com/ -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Problem compiling Python 3.2 in 32bit on Snow Leopard
Attempting to compile Python 3.2 in 32-bit mode on MacOSX 10.6.4 I get: Undefined symbols: "___moddi3", referenced from: _PyThread_acquire_lock_timed in libpython3.2m.a(thread.o) _acquire_timed in libpython3.2m.a(_threadmodule.o) "___divdi3", referenced from: _PyThread_acquire_lock_timed in libpython3.2m.a(thread.o) _acquire_timed in libpython3.2m.a(_threadmodule.o) ld: symbol(s) not found /usr/bin/libtool: internal link edit command failed Any suggestions? -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: WxPython versus Tkinter.
Terry Reedy wrote: PyGui seems to be purely a gui package, but it appear to be aimed only at 2.x with no interest in 3.x. I'm working on 3.x conversion right now and should have something ready soon. -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: WxPython versus Tkinter.
Octavian Rasnita wrote: How complete is this GUI lib compared with others that can be used in Python apps? It has most of the basic things you would want. There are one or two gaps, and I'm working on filling them. "Get the library and its documentation included in the core Python distribution, so that truly cross-platform GUI applications may be written that will run on any Python installation, anywhere." I'm not sure at this point whether stdlib inclusion is really a desirable goal or not. In any case, it's a very long-term issue. The first priority is to develop it to the point where it's a viable alternative to Tkinter. -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: WxPython versus Tkinter.
Corey Richardson wrote: What are those gaps? That depends on what you consider to be essential. Things I would like to add include: * Combo box * Group box * Tab panel (aka "notebook") * Table view * Tree view * Rich text editor -- Greg -- http://mail.python.org/mailman/listinfo/python-list
2to3 and maketrans
What is the recommended way to write code for 2.7 using maketrans() on text strings in such a way that it will convert correctly using 2to3? There seems to be two versions of maketrans in 3.x, one for text and one for bytes. Code that references string.maketrans ends up with the one for bytes, which is not what I want. But I can't write str.maketrans, because that doesn't exist in 2.x. So what am I supposed to do? -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: 2to3 and maketrans
Martin v. Löwis wrote: Whether a GUI library is application programming or systems programming, I don't know. Neither do I, but it doesn't really matter. In my case the string is definitely text (although it will always be ascii) and therefore unicode is the right representation to use in 3.x. I just wondered whether there was a recommended idiom for using maketrans() on text in 2.7 that 2to3 would translate into str.maketrans(), but it seems not. Instead the solution seems to be to convert to unicode and use its translation method instead. I've since adopted a different solution, but I'll keep this in mind for the future. Thanks, everyone. -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: having both dynamic and static variables
BartC wrote: I got the impression the OP was talking about simply pinning down certain variables, so that a runtime name lookup (if that's in fact what Python does) was not necessary. A problem with this is that lexical name lookups are a relatively small proportion of the looking up that goes on in a typical Python program. Much more often you're looking up attributes of objects, which is much harder to turn into an indexed access, because the compiler has next to no knowledge of what type the object will be at run time. -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: having both dynamic and static variables
John Nagle wrote: "let" allows the usual optimizations - constant folding, hoisting out of loops, compile time arithmetic, unboxing, etc. Only if the compiler knows the value of the constant, which it won't if it's defined in a different module. -- Greg -- http://mail.python.org/mailman/listinfo/python-list
