Re: Font management under win32
On 9/30/05, Roger Upole [EMAIL PROTECTED] wrote: Here's an example of how to use EnumFontFamilies: I'm trying the code you just posted, which works (thanks a lot), but I'm having another problem now. As I stated in my first post, the reason why I need to know the list of installed fonts is that I have to decide whether to further install some additional missing ones. The problem I have now, is that I don't know before hand the name of the missing fonts, I just have their .ttf or .otf files. So I'd have to somehow go inside and look for their names. Do you think that is possible with win32 extensions? thanks, stefano -- http://mail.python.org/mailman/listinfo/python-list
Font management under win32
Hi, I have a simple need, running under windows: 1) retrieve the list of installed system fonts 2) maybe install missing fonts Surprisingly for me, there seems to be no support for such a thing in python. I really hope I'm mistaken, so _please_ correct me if I'm wrong. I found out that it all boils down to a couple of win32 syscalls: EnumFontFamiliesEx and AddFontResourceEx. Unfortunately I'm no expert of win32 programming whatsoever. I asked Mark Hammond about this. While I wait for him to receive my email, I thought I'd post on the list in case someone else was interested, or had found a different solution. Indeed, win32gui does contain an EnumFontFamilies (without the trailing Ex) function, but I found no usage example, and I couldn't figure out how to use LOGFONT handles (since such a thing is required as the first parameter to the call). So I decided to punt on it and ask for wiser support. If I could get this EnumFontFamilies to work, it could already be enough, because I found a command line tool that allows me to do font installation. It's got to be some no-brainer 10 lines of C code simply calling AddFontResourceEx, but it works! So, does anybody ever had the same problem? thanks, stefano -- http://mail.python.org/mailman/listinfo/python-list
Re: Why do Pythoneers reinvent the wheel?
On 10 Sep 2005 02:10:59 EDT, Tim Daneliuk [EMAIL PROTECTED] wrote: As someone who implemented their own configuration mini-language with validation, blah, blah, blah (http://www.tundraware.com/Software/tconfpy/) Well, a configuration mini language with validation and blahs is not exactly what I would call _simple_... :) so maybe it doesn't even fit into my idea of testing-stdlib, or quick and dirty section of the manual (see my other post). But certainly it would be worth mentioning in the list of available solutions under the subsection Configuration files handling. 1) The existing tool is inadequate for the task at hand and OO subclassing is overrated/overhyped to fix this problem. Even when you override base classes with your own stuff, you're still stuck with the larger *architecture* of the original design. You really can't subclass your way out of that, hence new tools to do old things spring into being. That's true, but usually only when the original design if too simple comparing to the complexity of the problem. Instead a very general solution can usually be subclassed to easily handle a simpler problem. You still have to actually understand the general and complex design in order to be able to write subclasses, so maybe one can be tempted to punt on it, and write its own simple solution. But in this case it would just be enough to propose a few solutions in the testing-stdlib: a) one simple implementation for simple problems, easy to understand, but limited. b) one complex implementation for complex problems, c) one simplified implementation for simple problems, easy to understand, but subclassed from a complex model, that leaves room for more understanding and extension just in case one needs more power. I fully understand the difficulty of reusing code, as it always forces you to a learning curve and coming to compromises. But I've also wasted a lot of time reinventing the wheel and later found stuff I could have happily lived with if I only had known. 2) It's a learning exercise. Well, so we might as well learn a little more and rewrite os.path, the time module and pickle. Right? :) 3) You don't trust the quality of the code for existing modules. (Not that *I* have this problem :-p but some people might.) That's a good point, but it really boils down to being a wise programmer on one side, being able to discern the Good from the Bad, and an active community on the other side, able to provide good solutions and improve them. If either one is missing, then a lot of bad stuff can happen, and we can't really take community decisions basing on the assumption that programmers won't be able to understand, or that the community won't be able to provide. So we might as well assume that we have good programmers and an active community. Which I think is true, by the way! So, let's talk about a way to more effectively present available solutions to our good programmers! :) cheers, stefano -- http://mail.python.org/mailman/listinfo/python-list
Re: Why do Pythoneers reinvent the wheel?
On 10 Sep 2005 03:16:02 EDT, Tim Daneliuk [EMAIL PROTECTED] wrote: frameworks are unlikely to serve them well as written. I realize this is all at a level of complexity above what you had in mind, but it's easy to forget that a significant portion of the world likes/needs/benefits from things that are *not* particularly generic. This is thus reflected in the software they write. In my opinion this has got more to deal with the open source vs. proprietary debate, that I wouldn't like to talk about, since it's somewhat marginal. What I was pointing out is well summarized in the subject: Why do Pythoneers reinvent the wheel? Reinventing the wheel (too much) is Bad for both the open source community and industry. It's bad for development in general. I got the feeling that in the specific case of Python the ultimate reason for this tendency in also the same reason why this language is so much better that others for, say, fast prototyping and exploration of new ideas: it's simple. So, without taking anything out of python, I'm wondering if a richer and less formal alternative standard library would help forming a common grounds where programmers could start from in order to build better and reinvent less. If such an aid to _general_ problem solving is indeed missing (I might be wrong) from the current state of python, I don't really think the reason is related to industry. I would look for reasons elsewhere, like it beeing difficult to come out with effective decisional support in an open source community, or something like this. I can certainly see the challenge of who and how should decide what goes in the library, and what not. stefano -- http://mail.python.org/mailman/listinfo/python-list
Why do Pythoneers reinvent the wheel?
On 8 Sep 2005 08:24:50 -0700, Fuzzyman [EMAIL PROTECTED] wrote: What is pythonutils ? = ConfigObj - simple config file handling validate - validation and type conversion system listquote - string to list conversion StandOut - simple logging and output control object pathutils - for working with paths and files cgiutils - cgi helpers urlpath - functions for handling URLs odict - Ordered Dictionary Class Fuzzyman, your post reminded me of something I can't stop thinking about. Please don't take this as a critique on your work. I place myself on the same side of yours. I just wanted to share this thought with everybody had an opinion about it. I wonder how many people (including myself) have implemented their own versions of such modules, at least once in their pythonic life. I indeed have my own odict (even same name! :). My own pathutils (different name, but same stuff). My own validate... and so forth. This is just too bad. There are a few ares where everybody seems to be implementing their own stuff over and over: logging, file handling, ordered dictionaries, data serialization, and maybe a few more. I don't know what's the ultimate problem, but I think there are 3 main reasons: 1) poor communication inside the community (mhm... arguable) 2) lack of a rich standard library (I heard this more than once) 3) python is such an easy language that the I'll do it myself evil side lying hidden inside each one of us comes up a little too often, and prevents from spending more time on research of what's available. It seems to me that this tendency is hurting python, and I wonder if there is something that could be done about it. I once followed a discussion about placing one of the available third party modules for file handling inside the standard library. I can't remember its name right now, but the discussion quickly became hot with considerations about the module not being right enough to fit the standard library. The points were right, but in some sense it's a pity because by being in the stdlib it could have had a lot more visibility and maybe people would have stopped writing their own, and would have begun using it. Then maybe, if it was not perfect, people would have begun improving it, and by now we would have a solid feature available to everybody. mhm... could it be a good idea to have two versions of the stdlib? One stable, and one testing, where stuff could be thrown in without being too picky, in order to let the community decide and improve? Again, Fuzzyman, your post was just the excuse to get me started. I understand and respect your work, also because you put the remarkable effort to make it publicly available. That's my two cents, stefano -- http://mail.python.org/mailman/listinfo/python-list
Re: Why do Pythoneers reinvent the wheel?
On 9/9/05, Michael Amrhein [EMAIL PROTECTED] wrote: Did you take a look at pyPI (http://www.python.org/pypi) ? At least you'd find another odict ... Oh, yeah. And another filesystem abstraction layer... and another xml serialization methodology... :) PyPI is actually pretty cool. If I had to vote for something going into a testing stdlib, I'd vote for PyPI. You see, that's my point, we have too many! :) stefano -- http://mail.python.org/mailman/listinfo/python-list
Re: Why do Pythoneers reinvent the wheel?
On 9/9/05, djw [EMAIL PROTECTED] wrote: I think, for me, this most important reason is that the stdlib version of a module doesn't always completely fill the requirements of the project being worked on. That's certainly why I wrote my own, much simpler, logging module. In this case, its obvious that the original author of the stdlib logging module had different ideas about how straightforward and simple a logging module should be. To me, this just demonstrates how difficult it is to write good library code - it has to try and be everything to everybody without becoming overly general, abstract, or bloated. That's very true. But... ...there are languages (ahem... did I hear somebody say Java? :) that make it so hard to write code, that one usually prefers using whatever is already available even if this means adopting a style that doesn't quite match his expectations. To me, it is not clear which is best: a very comfortable programmer with a longer todo list, or an unfomfortable programmer with a short todo list. So far, I've always struggled to be in the first category, but I'm amazed when I look back and see how many wheels I reinvented. But maybe it's just lack of wisdom. :) stefano -- http://mail.python.org/mailman/listinfo/python-list
Re: Why do Pythoneers reinvent the wheel?
On 9/9/05, Dave Brueck [EMAIL PROTECTED] wrote: shot). The cost of developing _exactly_ what you need often is (or at least *appears* to be) the same as or lower than bending to use what somebody else has already built. That's right. But as you say, this is _often_ the case, not always. One doesn't necessarily need to bend too much in order to use something that's available out there. If we're talking about simple stuff, like ordered dictionaries, file system management, ini files roundtripping, xml serialization (this one maybe is not that trivial...), I don't think you would have to come to big compromises. I myself reinvented these wheels a few times in different projects, because I wasn't happy with the way I reinvented the first time, then I eventually found some code written by someone else that was _exactly_ the same as my last attempt, my most evolved and perfect, my presciou :), if it wasn't even better. Separate paths of evolution that converged to the same solution, because the problem was simple to begin with. Under this light, it seems to me that I wasted a lot of time. If odict was in the stdlib I wouldn't have bothered writing it. And yet, this code is not available in the stdlib. Sometimes it's not even trivial to be googled for. Plus, if you think of a python beginner, what's the chance that he's gonna say: naa, this code in the library sucks. I'm gonna search google for another ini file round tripper. Whatever is available there, he's gonna use, at least in the beginning. Then he will soon figure out that it indeed sucks, and at that point there's a chance that he'll say: man... _python_ sucks! I cannot even round trip an ini file with the same module! That's why I say this lack of a centralized, officially recommended code repository maybe is hurting python. I agree that building library code is hard because it has to be both correct and simple. But, again, there's a lot of useful stuff not the library, that's simple in the start so it's just a matter of writing it correctly. If the semantics can be different, just provide a couple of alternatives, and history will judge. It would be great if there was a section in the Python manual like this: Quick and Dirty: Commonly needed tricks for real applications 1. odict 2. file system management 3. xml (de)serialization 4. ... Each section would describe the problem and list one or a few recommended implementations. All available under __testing_stdlib__. Appoint somebody as the BDFL and make the process of updating the testing stdlib democratic enough to allow for more evolution freedom than the stable stdlib. If such a quick and dirty section existed, I think it would also become a natural randevouz point for innovators. If one invented a new cool, simple and useful module, rather than just publishing it in his own public svn repository, he would feel comfortable to start a discussion on the python-testing-stdlib mailing list suggesting to include it in the quick and dirty section of the manual. The manual is the primary resource that every python programmer makes use of, expecially beginners. But it is so official that no one would ever dare suggesting to include something in it. If the Vaults of Parnassus were listed in there (maybe a bit trimmed and evaluated first ;) a beginner would have immediate access to the most common tricks that one soon faces when it comes to writing real applications. I'm talking wildly here... I'm quite aware of how simplistic I made it. Just throwing an idea. What do you think? stefano -- http://mail.python.org/mailman/listinfo/python-list
