Re: Flat file, Python accessible database?
On Tue, 1 Nov 2005, Karlo Lozovina wrote: > [EMAIL PROTECTED] (=?utf-8?Q?Bj=C3=B6rn_Lindstr=C3=B6m?=) wrote in > news:[EMAIL PROTECTED]: > >> If you need it to be SQL-like, SQLite seems to be the right thing. > > Tried that one, but had some problems setting things up. That is strange. SQLite + PySQLite are IMHO no harder to install than BerkeleyDB + Pybsddb... > On the other > hand, BerkeleyDB + Pybsddb worked like a charm, with no setting up (under > Cygwin). Sincerely yours, Roman Suzi -- [EMAIL PROTECTED] =\= My AI powered by GNU/Linux RedHat 7.3 -- http://mail.python.org/mailman/listinfo/python-list
Re: reading internet data to generate random numbers.
On Wed, 2 Nov 2005, Grant Edwards wrote: > On 2005-11-02, Levi Campbell <[EMAIL PROTECTED]> wrote: > >> Hi, I'm working on a random number generator using the internet as a >> way to gather entropy, I have two questions. So far interesting. >> 1. is there a way to capture the internet stream? Most news sites provide RSS and/or ATOM feeds these days. Or maybe you mean video/audio stream from Internet stations? (not sure how much entropy such a stream could contain: probably depends on the genre ;-) Or perhaps you mean low-level Ethernet/TCP/IP "stream"? Then it is not original and I already saw answers with recomendations. Sincerely yours, Roman Suzi -- [EMAIL PROTECTED] =\= My AI powered by GNU/Linux RedHat 7.3 -- http://mail.python.org/mailman/listinfo/python-list
Re: XML DOM: XML/XHTML inside a text node
On Thu, 2 Nov 2005 [EMAIL PROTECTED] wrote:
> In my program, I get input from the user and insert it into an XHTML
> document. Sometimes, this input will contain XHTML, but since I'm
> inserting it as a text node, xml.dom.minidom escapes the angle brackets
> ('<' becomes '<', '>' becomes '>'). I want to be able to
> override this behavior cleanly. I know I could pipe the input through
> a SAX parser and create nodes to insert into the tree, but that seems
> kind of messy. Is there a better way?
What about parsing the input into XML first? Is there any point in including
unescaped code into XML document unless it is XML itself?
> Thanks.
>
>
Sincerely yours, Roman Suzi
--
[EMAIL PROTECTED] =\= My AI powered by GNU/Linux RedHat 7.3
--
http://mail.python.org/mailman/listinfo/python-list
Pychecker Re: Nested List Question
On Thu, 3 Nov 2005, Chris McCoy wrote: > Thank you! I've been banging my head against the wall! > > Chris M. >> gridSystemId = [[None]*columns]*rows > > You've made gridSystemID a list of `rows` references to the SAME "inner" > list, so the behavior you observe is the only possible one. > > If you want copies instead, ASK for copies...: > > gridSystemId = [ [None]*columns for x in xrange(rows) ] Interesting, could not pychecker recognize such situations in Python code and give warnings? Sincerely yours, Roman Suzi -- [EMAIL PROTECTED] =\= My AI powered by GNU/Linux RedHat 7.3 -- http://mail.python.org/mailman/listinfo/python-list
DB-API 2.0 in pysqlite and pgdb
Happy New Year to all Pythoneers!
I am playing with pysqlite and pgdb and their DB-API conformancy.
It was quite interesting to know:
- sqlite doesn't have mandatory helper-functions Date, Tim, etc.
(due to an error int it's __init__, but this is quite obvious to correct
or just to use mx.Date, mx.Time)
more serious mishaps with pgdb (postgresql-python):
it doesn't know how to quote date-time data for the objects
it has constructors itself.
>>> import pgdb
>>> c = pgdb.connect(database="template1")
>>> cu = c.cursor()
>>> o = pgdb.Time(10, 0, 0)
>>> cu.execute("select %(o);", vars())
Traceback (most recent call last):
File "", line 1, in ?
File "/usr/local/lib/python2.3/site-packages/pgdb.py", line 189, in execute
self.executemany(operation, (params,))
File "/usr/local/lib/python2.3/site-packages/pgdb.py", line 201, in
executemany
sql = _quoteparams(operation, params)
File "/usr/local/lib/python2.3/site-packages/pgdb.py", line 283, in
_quoteparams
x[k] = _quote(v)
File "/usr/local/lib/python2.3/site-packages/pgdb.py", line 275, in _quote
raise InterfaceError, 'do not know how to handle type %s' % type(x)
pgdb.InterfaceError: do not know how to handle type
This doesn't happen for strings or numbers:
>>> cu.execute("select %s;", ['s'])
>>> cu.execute("select %s;", [1])
>>> cu.execute("select %(k)s;", {'k': 123})
>>> o
Thus, pgdb doesn't know how to handle DateTimeDelta.
The same with
>>> cu.execute("select %(o)s;", {'o': pgdb.Date(2005,1,1)})
. . .
line 201, in executemany
sql = _quoteparams(operation, params)
File "/usr/local/lib/python2.3/site-packages/pgdb.py",
line 283, in _quoteparams
x[k] = _quote(v)
File "/usr/local/lib/python2.3/site-packages/pgdb.py",
line 275, in _quote
raise InterfaceError, 'do not know how to handle type
%s' % type(x)
pgdb.InterfaceError: do not know how to handle type
(It was after I commented out exception catch:
# except:
# raise OperationalError, "internal error in '%s'" % sql
in pgdb.py to see where the error occurs)
Am I missing something obvious or is it really a bug/feature of pgdb?
python2.3
postgresql-7.2.1
almost fresh mx.DateTime
Thank you!
Sincerely yours, Roman Suzi
--
[EMAIL PROTECTED] =\= My AI powered by GNU/Linux RedHat 7.3
--
http://mail.python.org/mailman/listinfo/python-list
Re: Lambda as declarative idiom (was RE: what is lambda used for in real code?)
Hi all, BTW, Alex Martelli and me have created a PEP 312 some time ago (when the debate of inline if was hot). I wish lambdas will not be deprecated in Python but the key to that is dropping the keyword (lambda). If anybody could think of a better syntax for lambdas _with_ arguments, we could develop PEP 312 further. I DO like the idea of support for universal declaratives in Python. (This way SQL, Prolog, grammar, DTD, lazy expressions, decision tables (advanced switch statements) etc things could be added in a Pythonic way.) We only need brief lambdas and lets (for closures), IMHO. Sincerely yours, Roman Suzi -- [EMAIL PROTECTED] =\= My AI powered by GNU/Linux RedHat 7.3 -- http://mail.python.org/mailman/listinfo/python-list
Re: Lambda as declarative idiom (was RE: what is lambda used for in real code?)
On Mon, 3 Jan 2005, Steven Bethard wrote: > Roman Suzi wrote: > > I wish lambdas will not be deprecated in Python but the key to that is > > dropping the keyword (lambda). If anybody could think of a better syntax for > > lambdas _with_ arguments, we could develop PEP 312 further. > > Some suggestions from recent lambda threads (I only considered the ones > that keep lambda as an expression): > > * Args Before Expression * > > Nick Coghlan: def-to syntax [1] > (def (a, b, c) to f(a) + o(b) - o(c)) > (def (x) to x * x) Wow! Is there any wiki-page these could be put on? By the way, I think to satisfy least-surprise principle, our declarative idiom must be compatible with type declarations GvR is planning for Python 3.0. This way Python will have ONE style for declarations, be it type declarations, logical declarations or database-queries, etc. This means, that there is a need for a LISP's quote, when code is only written and parsed but may be processed not only by Python interpreter itself but by any user-made interpreter. For example, type-checker, cursor.execute, lazy-Python-subinterpreter, DOM-manipulator etc. I do not know how it could be done syntactically, but it could be done if thought about long enough. Lambdas is one of the ways, arguably not the most pleasant one for a "quote". Maybe this is too outlandish, but I see lambdas as a "quote" mechanism, which presents a possibility to postpone (precisely control, delegate) evaluation. That is, an ovehead for lambda must be much lower but at the same time visible to the programmer: d = a + (lambda x, y: x+ y)(3, 4) if this expression is to be viewed in hypotetical syntax-highlighting editor, "(lambda x, y: x+ y)" need to be painted with another color than the rest of the expression, as it represents defining part of the expression, not the part which is being evaluated right away. What if we deprecate ` in it's repr() function and reserve it for inline lambdas (for Python 3.0, of course): d = a + (` x, y: x+y) (3, 4) Thus, implicit lambdas will be one more symbol, e.g. (`: None) instead of (: None) What does Guido think? ;) Sincerely yours, Roman A.Suzi -- - Petrozavodsk - Karelia - Russia - mailto:[EMAIL PROTECTED] - -- http://mail.python.org/mailman/listinfo/python-list
RE: Python evolution: Unease
On Tue, 4 Jan 2005, Batista, Facundo wrote: Maybe OP doesn't yet fully comprehend the ways of Python universe? As for his claims, I am quite surprised that Python lacks something in the docs. Concerning better hierarchy in the standard library, it is interesting that there are some movements in this direction: xml package, email package, etc. Probably Iwan thinks that letting more "hierachiesness" into std lib Python will be "cleaner". Yes, it will probably look "more organized" this way, but I do not like the idea: import time.time import time.calendar ... import web.url.openers import net.http ... import datatypes.string import textprocessing.re etc. > [Iwan van der Kleyn] > > #- need: a better standard ide, an integrated db interface with > #- a proper > #- set of db drivers (!!), a better debugger, a standard widget/windows > #- toolkit, something akin to a standard for web programming, better > #- documentation, a standard lib which is better organized, a > #- formalized > #- set of protocols and patterns for program construction. And an > #- interpreter which is fast enough to avoid using C or Pyrex in most > #- obvious cases. > > Let's take one by one: > > - IDE: Better than what? Than IDLE? Than Eclipse? Than SPE? Than Pythonwin? > > - Integrated DB interface with a proper set of db drivers (what means the > "!!"?): What do you mean with an integrated db interface? An standard API to > access different DB engines? Something like the Database API specification > (http://www.python.org/topics/database/DatabaseAPI-2.0.html)? There's a SIG > on DB at http://www.python.org/sigs/db-sig/ you may want to look at. > Regarding drivers, to what DB do you miss one? > > - Debugger: Again, better than what? I use the debugger in IDLE and it's > pretty ok. > > - Standard widget/windows toolkit: More standard than Tk? > > - Something akin to a standard for web programming: specifically? > > - Better documentation: Did you find *any* issue in the docs? And why you > didn't post a bug on that? > > - Better organization of the std lib: What do you propose (specifically)? > Please, in your proposal, take in consideration migration plans and how the > migration affect actual systems. And of course, why the new organization is > better than the old one. BTW, I also think that it should be better > organized, but don't know how. > > - a formalized set of protocols and patterns for program construction: a > what? > > - an interpreter which is fast enough to avoid using C or Pyrex in most > obvious cases: CPython is More Than Fast Enough. In which obvious cases it's > not enough for you? > > Don't misinterpret this response. I know it was a rambling. But *maybe* you > have something to contribute to Python development, even good ideas only and > no work. > > .Facundo Sincerely yours, Roman A.Suzi -- - Petrozavodsk - Karelia - Russia - mailto:[EMAIL PROTECTED] - -- http://mail.python.org/mailman/listinfo/python-list
Re: Lambda as declarative idiom (was RE: what is lambda used for in real code?)
On Tue, 4 Jan 2005, Steven Bethard wrote: >Roman Suzi wrote: >> On Mon, 3 Jan 2005, Steven Bethard wrote: >> >> >>>Roman Suzi wrote: >>> >>>>I wish lambdas will not be deprecated in Python but the key to that is >>>>dropping the keyword (lambda). If anybody could think of a better syntax for >>>>lambdas _with_ arguments, we could develop PEP 312 further. >>> >>>Some suggestions from recent lambda threads (I only considered the ones >>>that keep lambda as an expression): >> >> Wow! Is there any wiki-page these could be put on? > >It's now on: > >http://www.python.org/moin/AlternateLambdaSyntax > >and I added Bengt Richter's and your recent suggestions. Hmmm... what if we kill two rabbits in one blow: lambda will be even more implicit, if we just mark parameters by a back-quote while using PEP 312 convention: (:f(`a) + o(`b) - o(`c)) (:`x * `x) (:x) (:x.bar(*`a, **`k)) Not sure about default args: ((fun(x=x, a=a, k=k): x(*a, **k)) for x, a, k in funcs_and_args_list) Maybe this needs to be done with closures. Otherwise I think Python interpreter is quite capable to determine which parameters the function has... Only their order become a problem. Probably, ","-s could be used there: (`a,`b,`c : f(`a) + o(`b) - o(`c)) The whole expressions could be quoted: `(x, y, z) meaning a parameter with such structure. >Steve > Sincerely yours, Roman Suzi -- [EMAIL PROTECTED] =\= My AI powered by GNU/Linux RedHat 7.3 -- http://mail.python.org/mailman/listinfo/python-list
Re: Python evolution: Unease
On Tue, 4 Jan 2005, Dave Brueck wrote: >> It may be optional in the sense that the language will >> accept missing declarations but as soon as the feature >> is available it will become "mandatory" to use it >> (peer pressure, workplace practices). What about generic programming coming into fashion anytime soon? >That's my fear - type declarations could become one of the most abused language >features because they'd get used too often. > >-Dave > Sincerely yours, Roman Suzi -- [EMAIL PROTECTED] =\= My AI powered by GNU/Linux RedHat 7.3 -- http://mail.python.org/mailman/listinfo/python-list
Re: Optional Static Typing: Part II
On Tue, 4 Jan 2005, John Roth wrote: >Guido has posted a second blog entry on the optional static typing >initiative. >I like this a lot better than the first. Declarative approach is even more human-oriented than algorithmic one. If Python is to support declarations, let it support declarative programming paradigm with full-blown inference engine . So, why not add some logic approach to type declarations? I hope that "type" is understood in a generic programming way: it will be a big win for Python to provide grounds for GP 'concept' concept ;) Why not? Python program right now are nearer to GP than C++'s. 'Concept' is not mere "interface", but interface + semantic behaviour. And to describe that behaviour logic is needed (right now it could be done with asserts). I propose to skip 'interface' support with Python and go stright to GP concepts :> This way Python will be ahead with innovation and type/interface/concept declarations will not be seen as atavisms but a step forward from OOP. I hope GvR waited so long not implementing interfaces to implement something better, concepts for example ;-) Right now concepts are expressed informally in the docstrings. Sincerely yours, Roman Suzi -- [EMAIL PROTECTED] =\= My AI powered by GNU/Linux RedHat 7.3 -- http://mail.python.org/mailman/listinfo/python-list
Re: Python evolution: Unease
On Tue, 4 Jan 2005, Dave Brueck wrote: >Roman Suzi wrote: >>>>It may be optional in the sense that the language will >>>>accept missing declarations but as soon as the feature >>>>is available it will become "mandatory" to use it >>>>(peer pressure, workplace practices). >> >> >> What about generic programming coming into fashion anytime soon? > >Roman, I think I've read every single thread in the past year or three wherein >you've brought up generic programming, and I think you'd do well to choose a >new >term for the idea you're trying to convey. IIRC, I did it only once: at fall 2004. >The term "generic programming" is too... er... generic. :) Nope. It is not generic. It has it's definition made by the co-author of STL - A.Stepanov. And the Boost C++ library (many of us know it as Boost Python) standardise on the approach, AFAIK. >As you know, Python >already includes a _lot_ of support for generic programming (a function that >iterates over a sequence can easily process a list, or a string, or a tuple as >input; a function that takes a file-like object can often work just as will >with >a true file object or a cStringIO object; etc.). So when you bring up "generic >programming", it's too easy to dismiss the comment because (1) it's too vague >and (2) Python already does a lot of it. > >So, what is your term for the type of generic programming that Python doesn't >yet support? Interfaces? Protocols? Adapters? Metatype hierarchies? Python could have honest support of concepts. Everything else will be available with them. That is the whole point that Python supports GP. It is only one step to do concepts right (and GvR it seems want type-checking into Python 3.0 anyway), so support for concepts/concept checking is very logical, isn't it? Right now concepts in Python are things which experienced Python programmers know from practise. Sometimes, they feel them unconsciously. Concepts could be veryfied and this, for example, could prevent errors like DB-API-complient module doesn't have some small, but necessary to comply, attributes. Standard concepts could be part of standard concept "metalibrary", along with verification mechanisms (this could be done even on C++, why not in a candy like Python?). So every programmer could verify that his/her class, created to satisfy concept XYZ is (formally) such. Your example - cStringIO - does it really satisfy concept of STRING? It does. Partially. Those "partially" here and there could lead to madness. Unit testing will be simplified too, because structural tests will be built into concept-checking mechanism. And BTW, are we really disputing? What do you propose instead? Old-fashioned Pascal-like type definitions? Java-like interface/implementaion ...? IMHO it could be a big mistake to play catch-up. Sincerely yours, Roman Suzi -- [EMAIL PROTECTED] =\= My AI powered by GNU/Linux RedHat 7.3 -- http://mail.python.org/mailman/listinfo/python-list
Re: Python evolution: Unease
On Tue, 4 Jan 2005, Dave Brueck wrote: >> What about generic programming coming into fashion anytime soon? >Roman, I think I've read every single thread in the past year or three >wherein you've brought up generic programming, and I think you'd do well to >choose a new term for the idea you're trying to convey. Or, yes, and I forgot to mention that generic programming is much clearer idea than OO programming, as it is not so vague. At least for me: I still don't fully comprehend OOP (after N years of "studying" it!) and understanding of GP came after just one book on the topic. Sincerely yours, Roman Suzi -- [EMAIL PROTECTED] =\= My AI powered by GNU/Linux RedHat 7.3 -- http://mail.python.org/mailman/listinfo/python-list
Re: Python evolution: Unease
On Tue, 4 Jan 2005, Ian Bicking wrote: >Umm... this isn't helpful. "Generic" and "concept" are not terms that >belong to Boost or STL or whatever. They are just words. Coining the >term doesn't mean anyone else knows what it means, nor that anyone >*should* know what they mean -- personally I get very suspicious of >ideas that are based on redefined words, that tends to be a way of >hiding complexity or fuzziness. > >But anyway, if you use these terms, you really must provide references, >otherwise no one will know what you mean. "Python could have honest >support of concepts" is simply an incomplete sentence. "Python could >have honest support of Concepts (url)" would be more reasonable. Sorry. I use definitions from there sources: 1. http://www.cs.rpi.edu/~musser/gp/ 2. "A Formalization of Concepts for Generic Programming" (google could find PDF of that). If I am correct, this one: http://www.osl.iu.edu/publications/pubs/2004/willcock04:_formal_concep_gener_progr.pdf (it is safe to skip till example on Fig.1 to grasp the idea behind a concept. Relations between concepts are also very logical and remind of inheritance, association and aggregation) 3. "The Boost Graph Library" by Jeremy Siek, et al with A.Stepanov's foreword is a good way to see GP != STL. Probably Boost docs contain some knowledge on the topic, at least Boost Graph Library's ones (which I read). >"Python could have honest support of Concepts (url)" - of course, right now those sources are C++-specific. But I could see that Python has even greater potential to have concepts ahead of C++ and with greater usefulness at the same time. Sincerely yours, Roman Suzi -- [EMAIL PROTECTED] =\= My AI powered by GNU/Linux RedHat 7.3 -- http://mail.python.org/mailman/listinfo/python-list
Re: Python evolution: Unease
On Tue, 4 Jan 2005, Dave Brueck wrote: >Roman Suzi wrote: >>>The term "generic programming" is too... er... generic. :) >> Nope. It is not generic. It has it's definition made by the co-author >> of STL - A.Stepanov. And the Boost C++ library (many of us know it as >> Boost Python) standardise on the approach, AFAIK. > >Ok, "too broad" then; Python already supports at least some aspects of generic >programming (at least, in the sense that I think you mean it), so it'd be good >to spell out what specific features you're referring to. > >> Python could have honest support of concepts. Everything else will be >> available with them. > >"Concepts" is a pretty generic term too! ;-) Do you mean concepts as defined >here: http://www.boost.org/more/generic_programming.html >? Yes. >> And BTW, are we really disputing? > >No, not at all - I'm just trying to better understand what you mean. Words >like "generic" and "concepts" don't yet have a widely recognized, strict >definition in the context of programming. If somebody has assigned some >specific definition to them, that's great, it's just not universal yet so >references and additional explanations are helpful. I apologize for not providing URLs to the exact definitions in the first place! I really think there is ONE understanding of GP vs. multitudes of understandings of OOP. Sincerely yours, Roman Suzi -- [EMAIL PROTECTED] =\= My AI powered by GNU/Linux RedHat 7.3 -- http://mail.python.org/mailman/listinfo/python-list
Re: args (was Re: Lambda as declarative idiom (was RE: what is lambda used for in real code?))
On Tue, 4 Jan 2005, Michael Spencer wrote: >Roman Suzi wrote: > >> Maybe this is too outlandish, but I see lambdas as a "quote" mechanism, >> which presents a possibility to postpone (precisely control, delegate) >> evaluation. That is, an ovehead for lambda must be much lower but at the >> same time visible to the programmer: >> >> d = a + (lambda x, y: x+ y)(3, 4) >[...] > >I believe that this "possibility to postpone" divides into two related but >separate concepts: controlling the moment of evaluation, and assembling the >arguments required at that moment. Yes. I have the same understanding. >They are both species of 'eval', but >managing arguments is more specialized, because it includes possibly renaming >parameters, assigning default values, processing positional and keyword >arguments, and, perhaps in the future dealing with argument types. Very precise! >Meanwhile, GvR wrote (about defining Interfaces in the context of Optional >Static Type Checking) As for GvR's writing, I think he is exploring the ground. What he wrote is too complex for Python and he guesses it is. There i another thread in c.l.p where I propose generic programming approach for Python's "type checking": IMHO, a much simpler and more natural for Python than programming by contract, just interfaces and such. And the syntactic way to express concepts is going thru declarations. That is why lambdas are to be on steroids for this task. More than that, compile vs. evaluation/parameter dispetching must not muddy the waters for programmer. It must always be clear (syntactically too) for him what is going on in the expression at hand. (But I do not know how this could be elegantly done sytactically) Is declaration-chewing engine built into Python an overkill? There are at least 2 specialized ones in it: parser and re.compile + many for different formats, like xml.dom. Sincerely yours, Roman Suzi -- [EMAIL PROTECTED] =\= My AI powered by GNU/Linux RedHat 7.3 -- http://mail.python.org/mailman/listinfo/python-list
Concepts RE: Python evolution: Unease
On Wed, 5 Jan 2005, EP wrote: >Roman wrote: > >> Maybe OP doesn't yet fully comprehend the ways of Python universe? > > > >> > Don't misinterpret this response. I know it was a rambling. But >> *maybe* you >> > have something to contribute to Python development, even good ideas >> only and >> > no work. >> > >> > .Facundo > > >Am I selling Snake Oil? > >What I do have is a "forest" instead of an "in the trees" perspective, and >from a forest view I see a lot of defensiveness about Python's hypothetical >shortcomings. No one needs be defensive, Python is an amazing programming >language, and everyone involved with its development, evolution, support and >codebase ought to feel quite good about it. -skip- It's c.l.p and people are free to express their opinions. Even negative. This helps improve Python. As for concepts, they are from Generic Programming (by Musser and Stepanov) and I feel that Python is in position to implement them to the fullest extent. And IMHO it will be nicer than just Java-like interfaces or Eiffel's contract approach. I can try to write a PEP "Generic Programming Concepts". Sincerely yours, Roman Suzi -- [EMAIL PROTECTED] =\= My AI powered by GNU/Linux RedHat 7.3 -- http://mail.python.org/mailman/listinfo/python-list
Re: Python evolution: Unease
On Wed, 5 Jan 2005, Alex Martelli wrote: >Dave Brueck <[EMAIL PROTECTED]> wrote: > ... >> No, not at all - I'm just trying to better understand what you mean. Words >> like "generic" and "concepts" don't yet have a widely recognized, strict >> definition in the context of programming. If somebody has assigned some >> specific definition to them, that's great, it's just not universal yet so >> references and additional explanations are helpful. > >Googling for "generic programming" (with the quotes) gets 100,000 + >hits. The first couple pages of hits, at least, seem to all be speaking >about exactly the same thing. The terminology appears to be settled >enough that Oxford's St Anne College feels they can organize a "Summer >School on Generic Programming", Nottingham University a "Workshop on >Generic Programming", etc, etc, without fearing ambiguity. That is why I was pretty sure people undestand me. >Exactly what extra support Roman would want from Python for 'concepts', >beyond that offered by, say, C++, I'm not sure. Protocols, interfaces >and design-by-contract are other terms often used to try and capture >pretty similar issues. I just happen to like the term 'concept' more than Protocols, interfaces, and design-by-contract ;-) Alex, I think you are +10 for adding interfaces into Python. "Concept" is more compact word and I am sure it is not used as a name in existing projects, unlike other words. Also, Python concept collection could be used as a teaching example or templates for high quality code. Concepts need not appear in every script out there, but as a result of design. What else Python needs to support GP? A possibility to formally define a concept (and concept relations) with (optionally) checks of implementations. I do not even insist in making it all run-time! Perhaps concepts could be checked in PyChecker. And (perhaps) the whole type-checking could be done this way. However sweety it is, I also hope to have keystrokes saved when I use ready-maid concept in my program. Just imagine we have a concept for table and use (as adaptor) it for db-connectivity, CSV-readers/writers, XML/HTML parsers/writers, arrays, lists, ... Right now Python _almost_ has it. However, small differences in small details do not allow to interchange even different dbm-modules! I remember getting into trouble when I switched from bsddb to gdbm: some places needed 'r' to be explicitly specified! Same problems with db-api 2.0 "almost" conformant modules, datetime types and other small details which are similar but differ in small details at the same time. I think the same has place with XML-DOM implementations and such. I think concepts could be guards against such things and also make life easier for those who implement some standard protocols. That is, concepts could be internal (Python) standardizing and quality control technique. We can use constant publicId, systemId a-la XML for concepts, so upgrade path will be similar to HTMLs. This will make concept-changing visible between versions. Sincerely yours, Roman Suzi -- [EMAIL PROTECTED] =\= My AI powered by GNU/Linux RedHat 7.3 -- http://mail.python.org/mailman/listinfo/python-list
Re: Concepts RE: Python evolution: Unease
On Wed, 5 Jan 2005, Paul Rubin wrote: >Paul Rubin <http://[EMAIL PROTECTED]> writes: >> There is nothing in Wikipedia about [Generic programming]. > >Oops: http://en.wikipedia.org/wiki/Generic_programming > >This helps. But I don't see how it's different from what used to >be called polymorphism. I already posted these links. They seem to give more fundamental definitions than wikipedia: ''' 1. http://www.cs.rpi.edu/~musser/gp/ 2. "A Formalization of Concepts for Generic Programming" (google could find PDF of that). If I am correct, this one: http://www.osl.iu.edu/publications/pubs/2004/willcock04:_formal_concep_gener_progr.pdf (it is safe to skip till example on Fig.1 to grasp the idea behind a concept. Relations between concepts are also very logical and remind of inheritance, association and aggregation) 3. "The Boost Graph Library" by Jeremy Siek, et al with A.Stepanov's foreword is a good way to see GP != STL. ''' As for polymorphism, yes, polymorphism. But any decent language has some sort of polymorphism today. The essense of concepts is that they provide formalities for (call them) contracts, interfaces, etc. Concepts from GP gather all these together and call it a concept: a family of similar types. Python already uses concepts implicitly, by convention. And we know them well: file-like objects, sequences, maps, sets, queues, arrays, etc. My "marketing" of GP is directed to formalise on concepts instead of partial cases (design-by-contract, interfaces etc). Thus, concepts control polymorphism not only from liberation side, but from constraint side too. Right now concepts in Python are reused here and there without explicit mentioning. Concepts could help make code even more reusable. Sincerely yours, Roman Suzi -- [EMAIL PROTECTED] =\= My AI powered by GNU/Linux RedHat 7.3 -- http://mail.python.org/mailman/listinfo/python-list
Re: Python evolution: Unease
On Fri, 6 Jan 2005, Paul Rubin wrote: >software when I buy a new computer, or at least a new hard drive. I >don't try to migrate system or configuration files. I just install >the OS distro from scratch and migrate my user files. > >> There are several parts to those frustrations. But you are presuming >> that they would have been solved for you and put on a DVD with all >> dependency problems resolved. Ok, let's assume that. In that case, >> an installation stub module could just as well have the solution built >> into it as to what versions etc are needed to make the module work. I do not like the idea of having stubs. Once I had an experience working with CPAN (I tried to install SpamAssassin and it required some specific modules.) "Magic" install shell, provided by Perl, upgraded half the Perl distro, including newer version of Perl! So, I do like Python distutils better. it is not a major problem to install something even if it required something else. Of course, this depends on the package authors. >How can it work just as well, when it requires a high-speed internet >connection which I might not have? And why is "just as well" good >enough, given how inconvenient and error-prone it is, compared with >just installing from a DVD once and for all? To have any attraction >what ever, the installation stub scheme (for me at least) has to work >"an order of magnitude better", not "just as well", as a one-time >complete install. > >> To bring a large collection into version-alignment ISTM you need a version >> freeze across too many libraries of different kinds with different >> development schedules and resources to make it reliable. > >One part of the problem is excessive version dependence between >package X and package Y. That's why I think there should be more >integration within packages, i.e. the Python distro should include a >lot more modules that you currently have to download from other >places. > >> I realize this problem has been "solved" with various RPM and >> app-loading methods, but I think python could wrap its solution >> nicely. I don't think distutils and setup.py is easy enough to >> create (at least I have been somewhat frustrated in using it >> effectively), though it deals with a lot of what has to be done. > >Since all these schemes have failed whenever they've been tried, all I >can think is that it's a harder problem than it sounds. I have installed many packages with Distutils, and usually there were no problems. If there were, they were no greater than installing some devel library and/or adding an include directory. So, Distutils, IMHO, are successful. Yes, probably there could be a no-brainer script to run install directly from zip and/or tar.gz/bz2 file, but I usually check md5, pgp sigs and look inside anyway before running something. Sincerely yours, Roman Suzi -- [EMAIL PROTECTED] =\= My AI powered by GNU/Linux RedHat 7.3 -- http://mail.python.org/mailman/listinfo/python-list
interpreter Py_Initialize/Py_Finalize mem leak?
In pure curiosity I tried to compile loop.c from Demo/embed and started it with 'print 2+2'. It seems, that both 2.3 and 2.4 pythons have memory leaks in Py_Initialize/Py_Finalize calls. (That is, interpreter doesn't clean up well after itself). This is my setup: gcc -fpic loop.c -DHAVE_CONFIG_H -lm -lpython2.4 \ -lpthread -lutil -ldl \ -I/usr/local/include/python2.4 \ -L/usr/local/lib/python2.4/config \ -o looptest (It's on Linux RedHat 7.3) I do not know if this is of any importance though. Probably it is for embedded Python uses. Sincerely yours, Roman Suzi -- [EMAIL PROTECTED] =\= My AI powered by GNU/Linux RedHat 7.3 -- http://mail.python.org/mailman/listinfo/python-list
Re: Python3: on removing map, reduce, filter
On Sun, 9 Jan 2005, Paul Rubin wrote: >Andrey Tatarinov <[EMAIL PROTECTED]> writes: I hope there will be from __past__ import functional_paradigma in Python 3 ;-) And, also, what is the best way to replace reduce() ? Sincerely yours, Roman Suzi -- [EMAIL PROTECTED] =\= My AI powered by GNU/Linux RedHat 7.3 -- http://mail.python.org/mailman/listinfo/python-list
RE: interpreter Py_Initialize/Py_Finalize mem leak?
On Mon, 10 Jan 2005, Delaney, Timothy C (Timothy) wrote: >Roman Suzi wrote: > >> In pure curiosity I tried to compile loop.c from Demo/embed >> and started it with 'print 2+2'. It seems, that both 2.3 and 2.4 >> pythons have memory leaks in Py_Initialize/Py_Finalize calls. >> (That is, interpreter doesn't clean up well after itself). > >What's your evidence for this (i.e. what are the symptoms)? - memory usage grows over time. >If you have a repeatable test case, please raise a bug report on >SourceForge. I tested only under Linux. And it is 100% repeatable. >Tim Delaney > Sincerely yours, Roman Suzi -- [EMAIL PROTECTED] =\= My AI powered by GNU/Linux RedHat 7.3 -- http://mail.python.org/mailman/listinfo/python-list
Re: java 5 could like python?
On Wed, 12 Jan 2005, vegetax wrote:
>-No naming convention. The speech of "it fits in my head" is no longer valid
>when i use a lot of functionality,modules,classes in a large proyect.
>For example if i remember a function i want ie:get attribute, i dont
>remember if the module implementer coded it as
>getAttribute,GetAttribute,get_attribute, then i have to go and check the
>doc, every time,which is a waste of time.
Or yes, I hate those 'get' too. Why not to use just obj.attribute instead?
Otherwise, the pluralism present in Python, makes me feel more at home.
>-library Organization,we have modules that can have 20 classes(I imagine
>that is because of the commodity of having all in one file) which makes
>reading the doc horribly painfull and is very hard to find the stuff
>coupled with the "pool" of modules that is the python installation
>directory,all throwed away at the installation directory without a
>categorization.
Probably some Really Large Corporation could add Python Standard Library
Enterprise Edition and win big.
>-Is python library half object oriented? half functional oriented? I can
Right now it change its orientation to iterator/generators...
I image a nice box with Python 3 in it, where there will be no more
inconsistencies with naming, etc.
>understand that python allows some functional programing components when
>they are necesary,but there are libraries that totaly ignore object
>orientation which makes them problematic to use.for example,Whats with the
>os.path module and files? why do i have to say os.path.getfilesize(f.name)
>all the time? why cant i say f.size? Why does urlparse returns a tuple of 7
>items instead of an URL object? why there isnt an URL object? and so on..
This reminds me of attributes vs. tags debate of how to structure XML.
size(f) or f.size() - that is the question
>I havent figured out a way to overcome those factors,the delaying and lost
>of focus that is having to check the docs all the time,every 5 seconds and
>having to make object oriented wrapers for several libraries or having to
>go and read the source code to know what the heck a function returns or
>what are its arguments makes coding unpleasant an very slow , i often have
>15 pydocs windows open at the same time. What should i do?
Do not use windows. Sit for an evening add read all the docs.
Coding will becaome much faster.
>-Realying on ides is imposible due to python dinamic nature,very litle(next
>to nothing) assistance can be espected from them.
Class browsing and auto-completion are probably the only features
I sometime miss. But otherwise what IDEs are for?
>-Memorazing all the function names,parameters,return values,conventions of
>the modules i use doesnt look like a good solution.
But it is a must: how do you communicate if you do not nother to
remember words?
>Join it with poor and outdated documention and we have a very unpleasant
>standard library.
>class C{
> public void func(){
> print("hello world"); // instead of System.out.println("hello world");
Probably print statement will not make it into Python 3.0. Very sad.
> print(run("ls /tmp"));
> }
>}
>
>Same for almost all python builtin functions.
>
>Also there is the generics support and so on..
>
>But for some reason i dont know,the switch back feels wrong =( ,would it be
>posible to imitate python's behavior with the new java features and some
>hacks? would be worth the effort? If not what can i do to use efficiently
>python modules and libraries? I recall, i didnt had this problem when doing
>small applications with a small set of modules.
>
>Sorry for my bad english.
That is it. I hate English. It has sooo much exceptions to remember!
Esperanto is much cleaner language. UN should drop all it's
official languages and use Esperanto instead.
Sincerely yours, Roman Suzi
--
[EMAIL PROTECTED] =\= My AI powered by GNU/Linux RedHat 7.3
--
http://mail.python.org/mailman/listinfo/python-list
RuntimeError: dictionary changed size during iteration
I think, the behaviour below is misfeature: >>> [e for e in vars()] Traceback (most recent call last): File "", line 1, in ? RuntimeError: dictionary changed size during iteration >>> e = None >>> [e for e in vars()] ['e', '__builtins__', 'rlcompleter', '__file__', '_[1]', 'atexit', '__name__', 'readline', '__doc__'] Sincerely yours, Roman Suzi -- [EMAIL PROTECTED] =\= My AI powered by GNU/Linux RedHat 7.3 -- http://mail.python.org/mailman/listinfo/python-list
RE: RuntimeError: dictionary changed size during iteration
On Thu, 20 Jan 2005, Batista, Facundo wrote: >For me, the point is: vars() returns the local variables as a list or is a >generator? > >In the docs don't say nothing about this. > >If it returns a list, it should NOT raise an error; if it's a generator, the >error is fine. > >.Facundo > Probably, e need not appear in vars() at all... This is why generator closure works fine. Sincerely yours, Roman Suzi -- [EMAIL PROTECTED] =\= My AI powered by GNU/Linux RedHat 7.3 -- http://mail.python.org/mailman/listinfo/python-list
Is email package thread safe?
Hi! Just to be sure, is email package of Python 2.3 thread-safe or not (to use, for example, in python-milter?) Sincerely yours, Roman A.Souzi -- http://mail.python.org/mailman/listinfo/python-list
Is email package thread safe? (fwd)
(this is a repost with an addition - probably noone noticed my message first time) Hi! Just to be sure, is email package of Python 2.3 thread-safe or not (to use, for example, in python-milter?) P.S. And where can I find information on particular piece of standard library if it is thread-safe or need locking? I recall 'random' module is (was?) unsafe - which isexplicitly stated in the docs. Can I assume that everything else without such notice is thread-safe? Sincerely yours, Roman A.Souzi -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
Re: Is email package thread safe? (fwd)
On Wed, 9 Feb 2005, Antoon Pardon wrote: Op 2005-02-09, Roman Suzi schreef <[EMAIL PROTECTED]>: Just to be sure, is email package of Python 2.3 thread-safe or not (to use, for example, in python-milter?) Can I assume that everything else without such notice is thread-safe? I doubt it. There is no indication that the email package uses any kind of locking. So multiple thread working on the same message will probably screw things up. Of course, I do not let threads to work on the same message! I meant that the package doesn't pose other kinds of restrictions. Can it work in _any_ situation work on two different messages at the same time, without any interference? Sincerely yours, Roman Suzi -- [EMAIL PROTECTED] =\= My AI powered by GNU/Linux RedHat 7.3 -- http://mail.python.org/mailman/listinfo/python-list
Re: Is email package thread safe? (fwd)
On Thu, 10 Feb 2005, Antoon Pardon wrote: Op 2005-02-09, Roman Suzi schreef <[EMAIL PROTECTED]>: On Wed, 9 Feb 2005, Antoon Pardon wrote: Op 2005-02-09, Roman Suzi schreef <[EMAIL PROTECTED]>: Just to be sure, is email package of Python 2.3 thread-safe or not (to use, for example, in python-milter?) Can I assume that everything else without such notice is thread-safe? I doubt it. There is no indication that the email package uses any kind of locking. So multiple thread working on the same message will probably screw things up. Of course, I do not let threads to work on the same message! Why should that be: "off course"? The random module you spoke about was also only thread unsafe if you called the same random generator from various threads. Using a randon generator per thread shouldn't have been a problem. Since you mentioned that, I thought that was the kind of thread safety you were after. I meant that the package doesn't pose other kinds of restrictions. Can it work in _any_ situation work on two different messages at the same time, without any interference? I can't give a guarantee, but there are no global statements and there doesn't seem to be assignments to cross module variables I think it would be a safe bet. Thanks to all who discussed this. Really, I had the same thoughts about 1:1 object-thread relation being thread safe. I am doing further research and if it will give interesting results, I shall post [solved] here. Sincerely yours, Roman Suzi -- [EMAIL PROTECTED] =\= My AI powered by GNU/Linux RedHat 7.3 -- http://mail.python.org/mailman/listinfo/python-list
Recursive __cmp__ in different Python versions
#The following Python code: class X: def __cmp__(self, y): print "cmp", self, y return cmp(self, y) x = X() print x < 10 # gives interesting results under different Python version. The most common sense in the result in Python 2.4: recursion limit reached. Python 2.3 tries 20+ times and then give up. Python1.5 gives segmentation fault... Sincerely yours, Roman Suzi -- [EMAIL PROTECTED] =\= My AI powered by GNU/Linux RedHat 7.3 -- http://mail.python.org/mailman/listinfo/python-list
Bug in email package?
I was playing with email package and discovrered this strange kind of behaviour: import email.Message m = email.Message.Message() m['a'] = '123' print m From nobody Mon Feb 21 00:12:27 2005 a: 123 for i in m: print i ... Traceback (most recent call last): File "", line 1, in ? File "/usr/local/lib/python2.3/email/Message.py", line 304, in __getitem__ return self.get(name) File "/usr/local/lib/python2.3/email/Message.py", line 370, in get name = name.lower() AttributeError: 'int' object has no attribute 'lower' I think that if any object (from standard library at least) doesn't support iteration, it should clearly state so. My guess is that 'for' causes the use of 'm[0]', which is (rightfully) an error... Can this behaviour of email be considered a bug? Is there a good case to iterate over something useful in a message? P.S. rfc822 has the same behaviour, at least on Python 2.3 Sincerely yours, Roman Suzi -- [EMAIL PROTECTED] =\= My AI powered by GNU/Linux RedHat 7.3 -- http://mail.python.org/mailman/listinfo/python-list
Re: Bug in email package?
On Sun, 20 Feb 2005, Steven Bethard wrote: Erik Max Francis wrote: Roman Suzi wrote: I think that if any object (from standard library at least) doesn't support iteration, it should clearly state so. My guess is that 'for' causes the use of 'm[0]', which is (rightfully) an error... Can this behaviour of email be considered a bug? Is there a good case to iterate over something useful in a message Why would it be a bug if the documentation never stated that the object was iterable? I think the bug is not that an error is produced, but that the _wrong_ error is produced. Trying to iterate over something that is not iterable should Well, that was what I meant. produce a TypeError saying so (not an Attribute error): py> class C(object): ... pass ... py> iter(C()) Traceback (most recent call last): File "", line 1, in ? TypeError: iteration over non-sequence I've actually seen something like this come up before (I think with email.Message even...) I say call it a bug and submit a patch. Ok. A bug minute on the next bug day ;-) It's pretty easy to fix -- just add an __iter__ method to Message that raises a TypeError. That makes it clear that Message doesn't intend to support the getitem protocol -- it just does so accidentally because it provides __getitem__. STeVe Sincerely yours, Roman Suzi -- [EMAIL PROTECTED] =\= My AI powered by GNU/Linux RedHat 7.3 -- http://mail.python.org/mailman/listinfo/python-list
Decorators for multimethods
hi! I've found one more nice use case for decorators. I feel multimethods could be made even nicier by defining multimethods inside special class. But I have not figured out how to do it yet. #!/bin/env python2.4 if "We have Neel Krishnaswami module Multimethod.py": import Multimethod class Foo: pass class Bar(Foo): pass def multimethod(g, *args): def make_multimethod(func): mm = Multimethod.Method(tuple(args), func) g.add_method(mm) return mm return make_multimethod g = Multimethod.Generic() @multimethod(g, Foo, Foo) def m1(a, b): return 'foofoo' @multimethod(g, Foo, Bar) def m2(a, b): return 'foobar' @multimethod(g, Bar, Foo) def m3(a, b): return 'barfoo' try: print 'Argtypes ', 'Result' print 'Foo, Foo:', g(Foo(), Foo()) print 'Foo, Bar:', g(Foo(), Bar()) print 'Bar, Foo:', g(Bar(), Foo()) print 'Bar, Bar:', g(Bar(), Bar()) except Multimethod.AmbiguousMethodError: print 'Failed due to AmbiguousMethodError' Sincerely yours, Roman Suzi -- [EMAIL PROTECTED] =\= My AI powered by GNU/Linux RedHat 7.3 -- http://mail.python.org/mailman/listinfo/python-list
A puzzle Re: Decorators for multimethods
For those who want to exercize Python skills, there is a problem below for defining multimethod g with as simple syntax as possible: @MULTIMETHOD def g(x, y): @PART(Foo, Foo) def m1(a, b): return 'foofoo' @PART(Foo, Bar) def m2(a, b): return 'foobar' @PART(Bar, Foo) def m3(a, b): return 'barfoo' What are definitions of MULTIMETHOD and PART in this case? (if such are at all possible). My best result was with class G(MMCLASS): def define(self): @self.PART(Foo, Foo) def m1(a, b): return 'foofoo' @self.PART(Foo, Bar) def m2(a, b): return 'foobar' @self.PART(Bar, Foo) def m3(a, b): return 'barfoo' g = G() where class MMCLASS(Multimethod.Generic): def __init__(self): Multimethod.Generic.__init__(self) def PART(*args): def make_multimethod(func): mm = Multimethod.Method(tuple(args), func) print func self.add_method(mm) return mm return make_multimethod self.PART = PART self.define() On Fri, 10 Dec 2004, Roman Suzi wrote: > >hi! > >I've found one more nice use case for decorators. I feel multimethods >could be made even nicier by defining multimethods inside special >class. But I have not figured out how to do it yet. > >#!/bin/env python2.4 >if "We have Neel Krishnaswami module Multimethod.py": > >import Multimethod > >class Foo: pass > >class Bar(Foo): pass > >def multimethod(g, *args): > def make_multimethod(func): >mm = Multimethod.Method(tuple(args), func) >g.add_method(mm) >return mm > return make_multimethod > >g = Multimethod.Generic() > >@multimethod(g, Foo, Foo) >def m1(a, b): return 'foofoo' > >@multimethod(g, Foo, Bar) >def m2(a, b): return 'foobar' > >@multimethod(g, Bar, Foo) >def m3(a, b): return 'barfoo' > >try: >print 'Argtypes ', 'Result' >print 'Foo, Foo:', g(Foo(), Foo()) > print 'Foo, Bar:', g(Foo(), Bar()) >print 'Bar, Foo:', g(Bar(), Foo()) >print 'Bar, Bar:', g(Bar(), Bar()) >except Multimethod.AmbiguousMethodError: >print 'Failed due to AmbiguousMethodError' > > >Sincerely yours, Roman Suzi > Sincerely yours, Roman Suzi -- [EMAIL PROTECTED] =\= My AI powered by GNU/Linux RedHat 7.3 -- http://mail.python.org/mailman/listinfo/python-list
