Re: Python Operating System???
What exactly do you mean by an operating system? If you don't want to program in C/C++ then you're going to have a hard time. I don't want to be too discouraging, but with that attitude I doubt you would get very far. It sounds like you want to make more of an OS shell -- no? You can implement a shell on top of any OS and probably do it in a language like Python. But if it is going to be a complete OS in pure Python, uh, it won't be! You'll have to do a lot of stuff in C, at the least interface with the hardware. "David Brown" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Hello. I recently came across a free operating system called Unununium (or > something like that) and it was developed in Python and Assembly. > > Now, I have been looking for a way to make an operating system for a long > long time and the only possibilities I could find were C++ and assembly. I > don't mind assembly so much if I don't have to use it very often. But C++ is > so complicated and errors are pretty much impossible to find in the code for > me. > > So, I was wondering if it would be possible to find a bootloader that loads > a python file at startup or something... > > Is there an example somewhere of a Python OS? > > Thanks! > > -- http://mail.python.org/mailman/listinfo/python-list
Re: Python Operating System???
"Michael Hobbs" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > David Brown <[EMAIL PROTECTED]> wrote: > > Hello. I recently came across a free operating system called Unununium (or > > something like that) and it was developed in Python and Assembly. > > > > Now, I have been looking for a way to make an operating system for a long > > long time and the only possibilities I could find were C++ and assembly. > > The problem when using Python instead of C for OS development is that > C was *specifically designed* to create an OS, while Python was designed > for completely different purposes. If you want to write an OS, it would > be wise to use a language that is suited for that purpose. If you > dislike C so much and prefer Python so much more, your first step should > be to design a Python dialect that is more appropriate for writing OS's. Yes, that sounds pretty realistic : ) For someone who is choosing the wrong language to write an OS, and who I would guess doesn't understand interrupt programming and the like -- their first task should be to redesign Python!! -- http://mail.python.org/mailman/listinfo/python-list
Re: Python Operating System???
> But I thought Python was an all-purpose language. After all, OS's > have been written in Lisp before too. It is a general purpose APPLICATION language. I am surprised that this hasn't been mentioned on this thread. An OS is NOT an application. It is a completely different kind of program. Do you guys understand the difference between user and kernel mode? Do you know what address spaces and hardware interrupts are? Python is not equipped to handle these things. You would end up doing so much in C extensions that it could barely be called Python. I am not trying to be insulting... but unless someone would like to educate me otherwise, the idea of an OS written in Python is almost ludicrous. As I said, I think you might mean an OS SHELL, which would be a reasonable (although maybe unconventional) thing to write in python. Also I am no threading expert, but I would imagine it would be very hard to write a task scheduler in Python given that it has the whole GIL thing. (As I said that isn't my domain of expertise but I'm sure someone here could expound on that.) -- http://mail.python.org/mailman/listinfo/python-list
Re: Python Operating System???
> Is an OS written in Lisp also ludicrous? Because it's been done. Can you point me to this? I'd like to see how "truly" Lisp it is. My first guess would be -- not very. And I'd like to install it on my PC. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python Operating System???
Well can you describe what kind of things you want to do exactly? My guess is you are not out to develop a new algorithm for virtual memory or task scheduling. There are many parts to an OS shell. An example is the command line, i.e. bash and the like in Unix, and cmd.exe in Windows. In Windows, Windows Explorer could be considered part of the shell, as well as the start menu and all that user-specific stuff. Basically you need to pick your OS, and then find out what the API to program the shell to would be. e.g. in Windows you would do it with the Win32 API. This will let you do things like delete and create files, interact with user structures, the registry, etc. OR, as a first stab -- I would just write a prototype. i.e., don't tie it to a real OS. Just pretend you have your own "users", your own "file system", your own display space, etc. This will help you get a much better idea of what you want to do. "David Brown" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > So how would I make an OS Shell? > > -- http://mail.python.org/mailman/listinfo/python-list
Re: Python Operating System???
OK I've heard of that. But the original poster didn't ask to make a Python machine and then a Python OS. My point was that you can't do a lot of hardware interface programming in pure Python -- there would be so much non-trivial code in C that it would be hard to call it a Python OS. So this basically proves my point -- that you need different hardware altogether in order to make an OS in a high level language like Lisp or Python. And if that Lisp OS on a PC simulator works... that still wouldn't disprove what I'm saying. What does the PC simulator run on? An OS? or it part of the OS? Either way you've got tons of non-trivial code in C/C++/assembly. "Paul Rubin" <http://[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > "Roose" <[EMAIL PROTECTED]> writes: > > > Is an OS written in Lisp also ludicrous? Because it's been done. > > > > Can you point me to this? I'd like to see how "truly" Lisp it is. > > http://en.wikipedia.org/wiki/Lisp_machine > > > My first guess would be -- not very. And I'd like to install it on my PC. > > Although written with federal funds at a university, it was never > released to the public, but was instead offered for sale from some > companies. The conflicts over this led to the birth of the free > software movement. > > Also, it was never intended to run on PC's (which didn't exist at that > time). It needed special hardware that was built for the purpose of > running Lisp. Lately there are people trying to program PC's to > simulate the Lisp hardware and to get the Lisp Machine software > released (now that the commercial market for it has long since dried > up). However, both of those projects have a ways to go. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python Operating System???
"Paul Rubin" <http://[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > "Roose" <[EMAIL PROTECTED]> writes: > > My point was that you can't do a lot of hardware interface programming in > > pure Python -- there would be so much non-trivial code in C that it would be > > hard to call it a Python OS. > > Why do you say that? Is the same thing not true of C, where you need > some assembly code at the lowest levels? Because Linux has some > assembly code, would you say that it's not written in C? It's a difference of degree, but an important difference. I haven't looked at Linux or Windows NT source, but my guess is the assembly used is just small functions for accessing special CPU instructions for atomicity, context switching, and the like. I KNOW they don't have huge amounts of assembly simply because they run on different architectures. But are you really going to write a virtual memory system in Python? Are you going to write a file system, and a task scheduler in Python? Are you going to have people write device drivers in Python? I'm not saying it can't be done, but it would be a poor engineering decision, and the rationale thus far seems to be "Python is cool, I like OSes, let's write a whole OS in Python". If that's not the case then let me know what your rationale is. The right tool for the right job. I love Python probably more than any other language. But it's not the right tool for every job. I don't know why people would think it is, just as C is not the right tool for every job (which is one of the reasons I learned Python, being a C programmer first). > > > So this basically proves my point -- that you need different hardware > > altogether in order to make an OS in a high level language like Lisp or > > Python. > > It doesn't prove anything of the sort. The Lisp hardware was needed > for performance reasons, back in the day. OK, then give me an example of Lisp OS that runs on a PC. I would like to install it on my PC tomorrow. Or maybe my Mac. That was your whole point, originally, that since it could be done in Lisp, why not Python? -- http://mail.python.org/mailman/listinfo/python-list
Re: Python Operating System???
> I've written file systems in Python, and task schedulers in > Javascript, and they were fine for their purposes Uh, not to be rude, but what are you talking about? If I'm not mistaken Javascript is that scripting language that runs inside a browser, an application. How are you going to save and restore CPU state in Javascript, or even call assembly that does it in Javascript? How do you switch into kernel mode in Javascript? We are on completely different pages apparently. > Huh? That's a non-sequitur, nothing prevents you from running Lisp on > your PC or Mac. The same issues issues that apply to OS code, also > apply to user code. The Lisp machine hardware wasn't needed only to > make the OS run fast. The Lisp machine was developed so that people > could deploy large user-level applications written in Lisp, and the > hardware was there to support those applications. And given such a > good Lisp environment, there was no reason to think of writing the OS > in anything other than Lisp. Upon reading back in the thread I see that you mean compiled Lisp, no? I was thinking that there would be a Lisp interpreter in a kernel, which afaik doesn't exist. In any case, as I said before I don't think it is impossible, just a poor engineering decision and I don't see the rationale behind it. Sure you can do anything for intellectual purposes and you'd probably learn a lot, but the OP is looking for an easier way to write an OS -- and that is not to write it in Python. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python Operating System???
"Paul Rubin" <http://[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > "Roose" <[EMAIL PROTECTED]> writes: > > > I've written file systems in Python, and task schedulers in > > > Javascript, and they were fine for their purposes > > > > Uh, not to be rude, but what are you talking about? If I'm not mistaken > > Javascript is that scripting language that runs inside a browser, > > Correct. > > > an application. How are you going to save and restore CPU state in > > Javascript, or even call assembly that does it in Javascript? How > > do you switch into kernel mode in Javascript? We are on completely > > different pages apparently. > > Correct. Are you actually going to answer any of my questions? Let's see this "JavaScript task scheduler" you have written! I'm calling bullshit on that, seeing as you declined to say anything useful about it. But I'm open to learn anything. Let's see it. Until then I'm not sure I want to spend a lot of energy arguing with you, because you're either pulling my leg or just profoundly mistaken. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python Operating System???
"Paul Rubin" <http://[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > "Roose" <[EMAIL PROTECTED]> writes: > > Are you actually going to answer any of my questions? Let's see > > this "JavaScript task scheduler" you have written! > > I wrote it at a company and can't release it. It ran inside a > browser. There was nothing terribly amazing about it. Obviously the > tasks it scheduled were not kernel tasks. Do you know how Stackless > Python (with continuations) used to work? That had task switching, > but those were not kernel tasks either. Well, then of course you know I have to say: An OS does not run inside a browser. There's a sentence I never thought I'd utter in my lifetime. So that is an irrelevant example, since it obviously isn't a task scheduler in the context of this thread. Anyway, this argument is going nowhere... I will admit that people have pointed out things here that are interesting like the attempts to embed Python in a kernel. But the point was that the OP was looking for an easier way to write an OS, and thought that might be to do it in Python, and I think I gave some good guidance away from that direction. That is mostly what I care about. These other arguments are academic, and of course I am not trying to stop anyone from trying anything. When I we see real working example, then we will all have a better idea of what the problems are, and how much of it can realistically be implemented in an interpreted language. Frankly I don't think that will come for about 10 years if ever, but hey prove me wrong. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python Operating System???
> Huh? I'm just baffled why you think writing a scheduler in an OS is > harder than writing one in an application. You have some means of > doing a coroutine switch in one situation, and some means of doing a > hardware context switch in the other. Aside from that the methods are > about the same. Because of performance. Task schedulers and device drivers tend to be timing sensitive. Go look up "task schedular latency". The longer your scheduler spends trying to figure out which thread to run, the longer the latency will be. I mean in the worst case, if you are interpreting everything, what if you change the task scheduler code? Then an interrupt happens, and oh shit we have to parse and recompile all the scheduling code. Oh wait now we ran out of kernel memory -- now we have to run the garbage collector! Let your interrupt wait, no? It just seems nonsensical. Maybe not impossible, as I've already said. I haven't tried it. But go ahead and try it -- I would honestly be interested in the results, all kidding aside. It shouldn't be too time-consuming to try, I suppose. Get Python running in the Linux kernel, and then replace the task scheduling algorithm with some Python code. See how it works. I suspect you will degrade the performance of an average system significantly or unacceptably. But who knows, I could be wrong. Of course, hardware is getting faster as you say. But multitasking performance is still an active and important area of OS research, and I doubt that any designer of an OS (that is actually meant to be used) would spend any cycles to have their task scheduler in Python -- and that will be probably be true for a very long time. Or maybe I'm wrong -- go bring it up on comp.os.linux or whatever the relevant newsgroup is. I'd like to hear what they have to say. > > Why do you think there's anything difficult about doing this stuff in > Python, given the ability to call low level routines for some hardware > operations as needed? -- http://mail.python.org/mailman/listinfo/python-list
builtin functions for and and or?
I need this a lot: a one line way to do a n-ary and or 'or'. e.g., result = True for x in L: if not boolean_function(x): result = False or >>> reduce(operator.__and__, [boolean_function(x) for x in L) So usually I just write a little function any( L, boolean_function = identity ) or all( ... ). But I am kind of sick of doing that all the time -- does it exist anywhere in the Python libraries? It seems really common to me. The first way isn't satisfactory because it takes so many lines for what is essentially one "primitive" operation. The second way isn't great because it is not as readable and many readers don't like to see reduce, even if it is a common idiom like that. Also I don't believe it short circuits. -- http://mail.python.org/mailman/listinfo/python-list
Re: builtin functions for and and or?
"Diez B. Roggisch" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > > So usually I just write a little function any( L, boolean_function = > > identity ) or all( ... ). But I am kind of sick of doing that all the > > time -- does it exist anywhere in the Python libraries? It seems really > > common to me. > > Put things into your own module and add it to your python path. Then you > only have to write it once. Well it's not as convenient as having it built in. The thing is I'm not just writing for myself. I used it at my old job, and now I'm using it at my new job. There's a requirement that the user shouldn't have to modify his setup beyond installing Python to run any scripts. At my first job we had one way of dealing with this. Now there is another way. And then I need a way to deal with it at home with my personal stuff. Also the stuff typically doesn't go under the Python dir, because that is not mapped to source control. And anyway people don't like mixing in our code with 3rd party code. The result that the path of least resistance is just to copy in a 4 line function or two into the program and be done with it, even though it goes against my sense of aesthetics. It would be a lot simpler if it was included in the distribution. I would be willing to add it (even though it is completely trivial). I think it would go fine in itertools (I would even put them as builtins, but I'm not going to go there because probably not everyone uses it as often as I do). What do people think? I have never done this, would I just write up a PEP? > > > The first way isn't satisfactory because it takes so many lines for what > > is > > essentially one "primitive" operation. The second way isn't great because > > it is not as readable and many readers don't like to see reduce, even if > > it > > is a common idiom like that. Also I don't believe it short circuits. > > It doesn't but so doesn't your loop example. Put a break in there once > Result is False. > > -- > Regards, > > Diez B. Roggisch -- http://mail.python.org/mailman/listinfo/python-list
Re: builtin functions for and and or?
Yeah, as we can see there are a million ways to do it. But none of them are as desirable as just having a library function to do the same thing. I'd argue that since there are so many different ways, we should just collapse them into one: any() and all(). That is more in keeping with the python philosophy I suppose -- having one canonical way to do things. Otherwise you could see any of these several ways of doing it in any program, and each time you have to make sure it's doing what you think. Each of them requies more examination than is justified for such a trivial operation. And this definitely hurts the readability of the program. <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > In Python there are so many ways to do things... > This looks like another one, I haven't tested it: > > not False in imap(pred, iterable) > > As usual tests are required to measure the faster one. > I agree with Roose, there are are some "primitive" operations (like > this, and flatten, partition, mass removal of keys from a dictionary, > and few others) that can be added to the language (but I'm still not > capabable of doing it myself, and Python is free, so it's not right to > ask people to work for free for us). > > Bear hugs, > Bearophile > -- http://mail.python.org/mailman/listinfo/python-list
Re: builtin functions for and and or?
> Previous discussion on this topic: > http://groups-beta.google.com/group/comp.lang.python/msg/a76b4c2caf6c435c > > Michael > OK, well then. That's really the exact same thing, down to the names of the functions. So what ever happened to that? That was over a year ago! I don't see any mention of it in PEP 289? http://www.python.org/peps/pep-0289.html It would be hard to imagine such a trivial change being rejected, if it were in its own namespace. Did it just happen that no one implemented it? Or it looks like no one could agree on the names? From that thread, I see any/all, anytrue/alltrue, forall/exists. Either of the first two is fine with me. -- http://mail.python.org/mailman/listinfo/python-list
Re: Pre-PEP: Dictionary accumulator methods
I like this, it is short, low impact, and makes things more readable. I
tend to go with just the literal way of doing it instead of using get and
setdefault, which I find awkward.
But alas I had a my short, low impact, useful suggestion and I think it
died. It was for any() and all() for lists. Actually Google just released
their "functional.py" module on code.google.com with the exact same thing.
Except they are missing the identity as a default which is very useful, i.e.
any(lst, f=lambda x: x) instead of any(lst, f).
Maybe you can tack that onto your PEP :)
That is kind of related, they are accumulators as well. They could probably
be generalized for dictionaries, but I don't know how useful that would be.
"Raymond Hettinger" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> I would like to get everyone's thoughts on two new dictionary methods:
>
> def count(self, value, qty=1):
> try:
> self[key] += qty
> except KeyError:
> self[key] = qty
>
> def appendlist(self, key, *values):
> try:
> self[key].extend(values)
> except KeyError:
> self[key] = list(values)
>
> The rationale is to replace the awkward and slow existing idioms for
dictionary
> based accumulation:
>
> d[key] = d.get(key, 0) + qty
> d.setdefault(key, []).extend(values)
>
> In simplest form, those two statements would now be coded more readably
as:
>
>d.count(key)
>d.appendlist(key, value)
>
> In their multi-value forms, they would now be coded as:
>
> d.count(key, qty)
> d.appendlist(key, *values)
>
> The error messages returned by the new methods are the same as those
returned by
> the existing idioms.
>
> The get() method would continue to exist because it is useful for
applications
> other than accumulation.
>
> The setdefault() method would continue to exist but would likely not make
it
> into Py3.0.
>
>
> PROBLEMS BEING SOLVED
> -
>
> The readability issues with the existing constructs are:
>
> * They are awkward to teach, create, read, and review.
> * Their wording tends to hide the real meaning (accumulation).
> * The meaning of setdefault() 's method name is not self-evident.
>
> The performance issues with the existing constructs are:
>
> * They translate into many opcodes which slows them considerably.
> * The get() idiom requires two dictionary lookups of the same key.
> * The setdefault() idiom instantiates a new, empty list prior to every
call.
> * That new list is often not needed and is immediately discarded.
> * The setdefault() idiom requires an attribute lookup for extend/append.
> * The setdefault() idiom makes two function calls.
>
> The latter issues are evident from a disassembly:
>
> >>> dis(compile('d[key] = d.get(key, 0) + qty', '', 'exec'))
> 1 0 LOAD_NAME0 (d)
> 3 LOAD_ATTR1 (get)
> 6 LOAD_NAME2 (key)
> 9 LOAD_CONST 0 (0)
> 12 CALL_FUNCTION2
> 15 LOAD_NAME3 (qty)
> 18 BINARY_ADD
> 19 LOAD_NAME0 (d)
> 22 LOAD_NAME2 (key)
> 25 STORE_SUBSCR
> 26 LOAD_CONST 1 (None)
> 29 RETURN_VALUE
>
> >>> dis(compile('d.setdefault(key, []).extend(values)', '', 'exec'))
> 1 0 LOAD_NAME0 (d)
> 3 LOAD_ATTR1 (setdefault)
> 6 LOAD_NAME2 (key)
> 9 BUILD_LIST 0
> 12 CALL_FUNCTION2
> 15 LOAD_ATTR3 (extend)
> 18 LOAD_NAME4 (values)
> 21 CALL_FUNCTION1
> 24 POP_TOP
> 25 LOAD_CONST 0 (None)
> 28 RETURN_VALUE
>
> In contrast, the proposed methods use only a single attribute lookup and
> function call, they use only one dictionary lookup, they use very few
opcodes,
> and they directly access the accumulation functions, PyNumber_Add() or
> PyList_Append(). IOW, the performance improvement matches the readability
> improvement.
>
>
> ISSUES
> --
>
> The proposed names could possibly be improved (perhaps tally() is more
active
> and clear than count()).
>
> The appendlist() method is not as versatile as setdefault() which can be
used
> with other object types (perhaps for creating dictionaries of
dictionaries).
> However, most uses I've seen are with lists. For other uses, plain Python
code
> suffices in terms of speed, clarity, and avoiding unnecessary
instantiation of
> empty containers:
>
> if key not in d:
> d.key = {subkey:value}
> else:
> d[key][subkey] = value
>
>
>
> Raymond Hettinger
>
>
--
http://mail.python.org/mailman/listinfo/python-list
Re: Pre-PEP: Dictionary accumulator methods
> +1 for inc instead of count. > appendlist seems a bit too specific (I do not use dictionaries of lists > that often). No way, I use that all the time. I use that more than count, I would say. Roose -- http://mail.python.org/mailman/listinfo/python-list
Re: Pre-PEP: Dictionary accumulator methods
> Py2.5 is already going to include any() and all() as builtins. The signature > does not include a function, identity or otherwise. Instead, the caller can > write a listcomp or genexp that evaluates to True or False: > > any(x >= 42 for x in data) > > If you wanted an identify function, that simplifies to just: > > any(data) Oh great, I just saw that. I was referring to this, which didn't get much discussion: http://mail.python.org/pipermail/python-dev/2005-February/051556.html but it looks like it went much further, to builtins! I'm surprised. But I wish it could be included in Python 2.4.x. I really hope it won't have any bugs in it. :) At my job we are probably going to upgrade to 2.4, and that takes a long time, so it'll probably be a year or 18 months after that happens (which itself might be months from now) that we would consider upgrading again. Oh well... -- http://mail.python.org/mailman/listinfo/python-list
Re: Pre-PEP: Dictionary accumulator methods
> Py2.5 is already going to include any() and all() as builtins. The signature > does not include a function, identity or otherwise. Instead, the caller can > write a listcomp or genexp that evaluates to True or False: Actually I was just looking at Python 2.5 docs since you mentioned this. http://www.python.org/dev/doc/devel/whatsnew/node3.html It says min() and max() will gain a key function parameter, and sort() gained one in Python 2.4 (news to me). And they do indeed default to the identity in all 3 cases, so this seems very inconsistent. If one of them has it, and sort gained the argument even in Python 2.4 with generator expressions, then they all should have it. > any(x >= 42 for x in data) Not to belabor the point, but in the example on that page, max(L, key=len) could be written max(len(x) for x in L). Now I know why Guido said he didn't want a PEP for this... such a trivial thing can produce a lot of opinions. : ) Roose -- http://mail.python.org/mailman/listinfo/python-list
Re: any() and all() Was: Pre-PEP: Dictionary accumulator methods
Ah OK, I stand corrected. Whoops. I just read the web page and thought the wrong thing, that makes sense. > Think about it. A key= function is quite a different thing. It provides a > *temporary* comparison key while retaining the original value. IOW, your > re-write is incorrect: > > >>> L = ['the', 'quick', 'brownish', 'toad'] > >>> max(L, key=len) > 'brownish' > >>> max(len(x) for x in L) > 8 > > > Remain calm. Keep the faith. Guido's design works fine. > > No important use cases were left unserved by any() and all(). > > > > Raymond Hettinger > > -- http://mail.python.org/mailman/listinfo/python-list
Re: Pre-PEP: Dictionary accumulator methods
> How about the alternative approach of allowing the user to override the > action to be taken when accessing a non-existent key? > >d.defaultValue(0) I like this a lot. It makes it more clear from the code what is going on, rather than having to figure out what the name appendlist, count, tally, whatever, is supposed to mean. When you see the value you'll know. It's more general, because you can support dictionaries and sets then as well. I think someone mentioned that it might be a problem to add another piece of state to all dicts though. I don't know enough about the internals to say anything about this. setdefault gets around this by having you pass in the value every time, so it doesn't have to store it. It's very similar, but somehow many times more awkward. -- http://mail.python.org/mailman/listinfo/python-list
simple GUI question
I have been writing only command line programs in python, and I need a way to simply pop up a GUI dialog box, with an "OK" box. Simple huh? I have used tkMessageBox.showwarning. This works OK but it also pops up an empty frame -- i.e. it pops up 2 things. Is there a way to disable this, or is there an alternate way of doing things? OK call me anal, but it bothers me. Another thing I would *like* but is not strictly necessary would be to change the font size and color of the text within the box. Is there a good way of doing that? I have googled around but can't find any decent example code for some reason. I can use Python 2.3 only, and only stuff that is included in the standard install. For something so trivial I can't roll out a new version of Python or any additional software. So I assume Tkinter is pretty much my only option, or is that not the case? Thanks for any help. Roose -- http://mail.python.org/mailman/listinfo/python-list
Re: simple GUI question
> You want somthing like:
>
> root = Tkinter.Tk()
> root.withdraw()
> msg = tkMessageBox.showwarning("Ooops", "Some warning")
Awesome thanks! Any chance you know about the font thing : )
Nah I'll stop being lazy and hack it... but for some reason Tkinter doesn't
jive with the way I think at all. It seems very different from the rest of
Python, which makes sense obviously since it was around before Python...
--
http://mail.python.org/mailman/listinfo/python-list
Re: Pre-PEP: Dictionary accumulator methods
> Another option with no storage overhead which goes part way to reducing
> the awkwardness would be to provide a decorator class accessible through
> dict. The decorator class would take a value or function to be used as
> the default, but apart from __getitem__ would simply forward all other
> methods through to the underlying dictionary.
I'm not sure I like the decorator -- I would never use that flexibility to
have more than one default. I can't come up with any reason to ever use
that.
I think it works best as a simple subclass:
class DefaultDict(dict):
def __init__(self, default, *args, **kwargs):
dict.__init__(self, *args, **kwargs)
self.default = default
def __getitem__(self, key):
return self.setdefault(key, copy.copy(self.default))
d = DefaultDict(0)
for x in [1, 3, 1, 2, 2, 3, 3, 3, 3]:
d[x] += 1
pprint(d)
d = DefaultDict([])
for i, x in enumerate([1, 3, 1, 2, 2, 3, 3, 3, 3]):
d[x].append(i)
pprint(d)
Output:
{1: 2, 2: 2, 3: 5}
{1: [0, 2], 2: [3, 4], 3: [1, 5, 6, 7, 8]}
--
http://mail.python.org/mailman/listinfo/python-list
Re: Pre-PEP: Dictionary accumulator methods
I agree -- I find myself NEEDING sets more and more. I use them with this idiom quite often. Once they become more widely available (i.e. Python 2.3 is installed everywhere), I will use them almost as much as lists I bet. So any solution IMO needs to at least encompass sets. But preferably something like the Dict with Default approach which encompasses all possibilities. Roose > I am more than sure you are right about this. But, please keep in mind > that you and we all have come very, very accustomed to using lists for > everything and the kitchen sink in Python. > > Lists where there from the beginning of Python, and even before the > birth of Python; very powerfull, well implemented and theoretically > well founded datastructures - I heared there is a whole language based > on list processing. *pun intended* > > sets on the other hand --- I know, in mathematics they have a deep, > long history. But in programming? Yeah, in SQL and ABAP/4 basically > you are doing set operations on every join. But its rather uncommon to > call it set. > > With 2.3 Python grew a set module. And, in ONLY ONE revision it got > promoted to a buildin type - a honour only those who read c.l.p.d. > regualary can value correctly. > > And sets are SO NATURALLY for a lot of problems ... I never thought of > replacing my "list in dict" constructs with sets before, BUT > there are 90% of problem domains where order is not important, AND > fast membership testing is a unique sales point. > > So please for best impressions: let us have a look at our code, where > we use the > dict.setdefault(key,[]).append() idiom, where it could be replaced to > a better effectivity with dict.setdefault(key,set()).add() > > If it is less than 60%, forget it. If it is more > > Harald -- http://mail.python.org/mailman/listinfo/python-list
Re: Getting the word to conventional programmers
> Except from a the standard, powerful, > looks-good-everywhere-and-has-a-tree-widget GUI toolkit? :) > > Seriously, I think this is *very* important. Yes, and a modern toolset/IDE. Generators and decorators and all that are nice, but their usefulness pales in comparison to having a decent IDE or GUI toolkit. Though I might disagree that Java has a good GUI toolkit, it has better tools than any language out there IMO. And I don't really like Java personally. -- http://mail.python.org/mailman/listinfo/python-list
random module question
Can I rely on the random.py module to produce the same series of numbers for future/past versions of Python, given the same seed? Can I rely on it across different architectures and operating systems? I looked at the docs and couldn't find this stated anywhere. My feeling is yes, but it's a fairly big claim so I want to make sure. R -- http://mail.python.org/mailman/listinfo/python-list
Re: Destructive Windows Script
My guess would be: extremely, extremely easy. Since you're only writing 30
bytes for each file, the vast majority of the data will still be present on
disk, just temporarily inaccessible because of the del command. And more
than likely it will be possible to recover 100% if they are using a
journaling file system like NTFS, which Windows XP does.
If you are honestly trying to destroy your own data, go out and download a
free program that will do it right. If you're trying to write some kind of
trojan, well you've got a lot of learning to do. :)
R
rbt wrote:
> How easy or difficult would it be for a computer forensics expert to
> recover data that is overwritten in this manner? This is a bit
> off-topic for comp.lang.python, but I thought some here would have
> some insight into this.
>
> Warning: **This code is destructive**. Do not run it unless you fully
> understand what you're doing!!!
>
> os.chdir('/temp')
> for root, dirs, files in os.walk('.'):
> for f in files:
> try:
> print f
>
> data = ['0', 'a', '1', 'b', '2', 'c',\
> '3', 'd', '4', 'e', '5', 'f',\
> '6', 'g', '7', 'h', '8', 'i',\
> '9', 'j', '~', '!', '@', '#',\
> '$', '%', '^', '&', '*', ';']
>
> fp = file(os.path.join(root,f), 'w')
> random.shuffle(data)
> garble = ''.join(data)
> fp.write(garble)
> fp.close()
>
> fs = os.popen("del /f /q /s *")
> fs.read()
> fs.close()
>
> except Exception, e:
> print e
> time.sleep(1)
> continue
--
http://mail.python.org/mailman/listinfo/python-list
Re: random module question
Raymond Hettinger wrote: > The answer is a qualified Yes. While the core generator (currently Thanks! That is the answer I'm looking for. And to Paul Rubin, it is a good point that Jython might not support it, but at this point it doesn't interest me. The program is only for myself anyway. R -- http://mail.python.org/mailman/listinfo/python-list
Re: What language to manipulate text files
Why do people keep asking what language to use for certain things in the Python newsgroup? Obviously the answer is going to biased. Not that it's a bad thing because I love Python, but it doesn't make sense if you honestly want an objective opinion. R ross wrote: > I want to do some tricky text file manipulation on many files, but > have only a little programming knowledge. > > What are the ideal languages for the following examples? > > 1. Starting from a certain folder, look in the subfolders for all > filenames matching *FOOD*.txt Any files matching in each folder should > be copied to a new subfolder within the current folder called EATING > with a new name of *FOOD*COPY.txt > > 2. Process each file as follows: > Here is a simplified example of what I want as input and output. > > - input > . 'several unknown lines of text file > Get apples from apples shop > Get oranges from oranges shop > Get plums from plums shop > Get pears from pears shop > Eat from apples, oranges, > plums, pears'whitespace at start of line is unimportant > . 'more unknown lines of text file > Chapter 1 > Several lines of text about apples in here > Chapter 2 > Several lines of text about oranges in here > Chapter 3 > Several lines of text about plums in here > Chapter 4 > Several lines of text about pears in here > > - output > . 'several unknown lines of text file > Get apples from apples shop > Get oranges from oranges shop > Get plums from plums shop > Get pears from pears shop > Get bagels from bagels shop 'the Get lines... > Get donuts from donuts shop 'can be in any order > Eat from apples, bagels, oranges, > plums, donuts, pears'whitespace at start of line is unimportant > . 'more unknown lines of text file > Chapter 1 > Several lines of text about apples in here > Chapter 2 > Several lines of text about bagels in here > Chapter 3 > Several lines of text about oranges in here > Chapter 4 > Several lines of text about plums in here > Chapter 5 > Several lines of text about donuts in here > Chapter 6 > Several lines of text about pears in here > > Summary: > I have added two new items to Get; > I have put them into the comma-delimited list after searching for a > particular fruit to put each one after; > The Chapters are renumbered to match their position in the > comma-delimited list. > The "several lines of text" about each new item can be pulled from a > new_foods.txt file (or a bagels.txt and a donuts.txt file). > > My first objective is to process the files as described. > My second objective is to learn the best language for this sort of > text manipulation. The language should run on Windows 98, XP and > Linux. > > Would Python be best, or would a macro-scripting thing like AutoHotKey > work? > I thought about Perl, but think I would learn bad habits and have hard > to read code. > > Thanks, Ross -- http://mail.python.org/mailman/listinfo/python-list
Re: How to test if an object IS another object?
This isn't a good example to test with, since 3 is an immutable object, as is 300 and all ints. It's more meaningful if the objects are mutable. Why do you want to test identity in the first place? Roose <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Sorry about removing my message, I posted with the wrong google > account, I don't really want my email where those irritating spam bots > can find it. > >>The most obvious way (as usual ?): >> >>if obj1 is obj2: >> // your code here > > I immediately thought of is, and tested it in the console, but it > didn't work quite like I expected: > >>foo = 3 >>bar = 3 >>zoo = foo >>foo is zoo > True >>foo is bar > True >>zoo is bar > True > > clearly foo and bar have the same value but they are different objects > aren't they? Yet applying the is operator yields True. > > Thanks, > -Dan > -- http://mail.python.org/mailman/listinfo/python-list
