Re: Social problems of Python doc [was Re: Python docs disappointing]
On Aug 12, 12:15 pm, Raymond Hettinger wrote: > [Xah Lee] > > > i've wrote several articles about this issue, total time spend on this > > is probably more than 2 months full-time work. See: > > > ⢠Python Documentation Problems > > http://xahlee.org/perl-python/python_doc_index.html > > I just read you post. You did devote a substantial amount of time > to the project. Some of your criticisms are valid. Wish you had > posted patches, I think many of them would have been accepted. > > Since you wrote this a few years ago, many examples have > been added to the docs and more are forthcoming. > > > I often receive thank you emails for 2 particular articles, which are > > most frequently google searched as indicated by my weblog: > > > ⢠Python Doc Problem Example: gzip > > http://xahlee.org/perl-python/python_doc_gzip.html > > > ⢠Python Doc Problem Example: sort() > > http://xahlee.org/perl-python/python_doc_sort.html > > > ⢠Sorting in Python and Perl > > http://xahlee.org/perl-python/sort_list.html > > Some are the criticisms are valid; others seem off-base. > > Here are a few thoughts on list.sort() for those who are interested: > > * The key= and reversed= parameters are not intended for special > cases, leaving cmp= for the general case. They were intended to > be full replacements. In Python3.x, the cmp function is gone. > > * The interaction of the key= and cmp= functions can be made to > interact (the key function is first applied to every element and > the cmp function then gets applied to the results of the key > function). This isn't a normal or intended use case, so the docs > don't delve into the subject. > > * The reversed parameter does more than list.sort() followed by > list.reverse(). It also preserves stability in the event of equal > keys: > >>>> sorted([(1,2), (1,3)], key=itemgetter(0), reverse=True) >[(1,2), (1,3)] > > So it was not correct to say that the following are equivalent: > > li.sort(lambda x, y: cmp(x[1],y[1]), reverse=True) > li.sort(lambda x, y: cmp(y[1],x[1])) > > * We should link the sorted() and list.sort() docs to the > sorting how-to (with a fuller discussion on the art of sorting > including a discussion of operator.itemgetter() and > operator.attrgetter() which were designed to work with the key= > parameter. > > Here are a few thoughts on list.sort() for those who are interested: > > After one more reading of Xah Lee's posts on the documentation for > sort, > here are couple more thoughts: > > * The reason that list.sort() allows None for the cmp parameter is not > so that you can write list.sort(None). It was put there to make it > easier for people writing function definitions where the cmp function > is a possible argument: > >def sort_and_chop(seq, maxlen, cmp=None): >s = seq[:] >s.sort(cmp) # needs to accept None as a possible > argument >return s[:maxlen] > > * The reason for implementing the key= parameter had nothing to do > with limitations of Python's compiler. Instead, it was inspired by > the > decorate-sort-undecorate pattern. Hi Raymond, thanks for the many points. They are informative, some i disagree, but it's getting into detail. I don't know python 3.0, will have to look into its sort in the future. This part i don't particular agree: > * The reason for implementing the key= parameter had nothing to do > with limitations of Python's compiler. Instead, it was inspired by > the > decorate-sort-undecorate pattern. The decorate-sort-undecorate pattern is a compiler limitation, for most of today's langs. I'm not sure, but i think some of the fancy functional langs automatically detect such and optimize it away, to various degrees. ... my criticism is usually written in a style catered to irritate a particular class of coder i call tech geekers (they think of themselfs with their idiotic term âhackersâ). So, parts are exaggerated. It'd be more clear to say, that the reason for python's âkeyâ, and as a âsolutionâ or need of the decorate-sort-undecorate issue, can be attributed to the current state of the art of popular imperative language's compilers (induced by such lang's semantics). again, i haven't studied python 3.0 to see what it has changed with sort, and thanks for the informative post. I find it intriguing that it doesn't have âcmpâ anymore as you say maybe when i actually study it and i'll come away with rage and rants. LOL. Xah â http://xahlee.org/ â -- http://mail.python.org/mailman/listinfo/python-list
Re: Xah's Edu Corner: The importance of syntax & notations.
["Followup-To:" header set to comp.lang.lisp.] On 2009-08-17, Peter Keller wrote: > In comp.lang.scheme Peter Keller wrote: >> The distance() function in this new model is the centroid of the syntactic >> datum which represent the semantic object. > > Oops. > > I meant to say: > > "The distance() function in this new model uses the centroid of each > individual syntactic datum (which represents the semantic object) as > the location for each semantic object." Don't sweat it; either way it makes no sense. The rewrite does have a more journal-publishable feel to it, though: the centroid of the whole aromatic diffusion seems to hover more precisely above the site of the bovine waste from which it apparently emanates. -- http://mail.python.org/mailman/listinfo/python-list
Re: GUI interface builder for python
On Aug 17, 10:59 am, "l...@d@n" wrote: > Which is the best GUI interface builder with drag and drop > capabilities. > I am using Ubuntu GNU/Linux. > Please help me. > Thank you. There are many GUI builders for python. (Have to deal with the licensing issues.) Qt has a GUI builder. Glade (GTK+) for python is also good. Boa constructor is also nice. -- http://mail.python.org/mailman/listinfo/python-list
GUI interface builder for python
Which is the best GUI interface builder with drag and drop capabilities. I am using Ubuntu GNU/Linux. Please help me. Thank you. -- http://mail.python.org/mailman/listinfo/python-list
Re: Xah's Edu Corner: The importance of syntax & notations.
In comp.lang.scheme Peter Keller wrote: > The distance() function in this new model is the centroid of the syntactic > datum which represent the semantic object. Oops. I meant to say: "The distance() function in this new model uses the centroid of each individual syntactic datum (which represents the semantic object) as the location for each semantic object." Sorry. -pete -- http://mail.python.org/mailman/listinfo/python-list
Re: Xah's Edu Corner: The importance of syntax & notations.
Personally, particular interesting info i've learned is that, for all my trouble in the past decade expressing problems of traditional math notation, i learned from his article this single-phrase summary: “traditional math notation lacks a grammar”. The article is somewhat disappointing though. I was expecting he'd go into some details about the science of math notations, or, as he put it aptly: “linguistics of math notations”. However, he didn't touch the subject, except saying that it haven't been studied. Xah On Aug 15, 10:54 pm, Xah Lee wrote: > Xah's Edu Corner: The importance of syntax & notations. > > http://www.stephenwolfram.com/publications/recent/mathml/mathml_abstr... > > this article should teach the coding sophomorons and computer > “science” idiotic authors who harbor the notion that syntax is not > important, picked up by all the elite i-reddit & twittering & hacker > news am-hip dunces. > > Further readings: > > • The TeX Pestilence > http://xahlee.org/cmaci/notation/TeX_pestilence.html > > • A Notation for Plane Geometry > http://xahlee.org/cmaci/notation/plane_geometry_notation.html > > • The Concepts and Confusions of Prefix, Infix, Postfix and Fully > Nested Notations > http://xahlee.org/UnixResource_dir/writ/notations.html > > • The Problems of Traditional Math Notation > http://xahlee.org/cmaci/notation/trad_math_notation.html > > Xah > ∑http://xahlee.org/ > > ☄ -- http://mail.python.org/mailman/listinfo/python-list
Re: Xah's Edu Corner: The importance of syntax & notations.
In comp.lang.scheme toby wrote: > In my opinion Knuth believed in the value of literate programming for > similar reasons: To try to exploit existing cognitive training. If > your user base is familiar with English, or mathematical notation, or > some other lexicography, try to exploit the pre-wired associations. > Clearly this involves some intuition. I've dabbled in the linguistics field a little bit and this thread made me remember a certain topic delineated in this paper: http://complex.upf.es/~ricard/SWPRS.pdf This paper uses a concept that I would say needs more investigation: The mapping of syntax onto metric spaces. In fact, the paper literally makes a statement about how physically close two words are when mapped onto a line of text and language networks build graph topologies based upon the distance of words from each other as they relate in syntactical form. It seems the foundations for being able to construct a metric to "measure" syntax is somewhat available. If you squint at the math in the above paper, you can see how it can apply to multidimensional metric spaces and syntax in different modalities (like the comparison between reading written words and hearing spoken words). For example, here the same semantic idea in a regex defined three ways: english-like: Match the letter "a" followed by one or more letter "p"s followed by the letter "l" then optionaly the letter "e". scheme-like: (regex (char-class \#a) (re+ (char-class \#p)) (char-class \#l) (re? (char-class \#e))) perl-like: /ap+le?/ The perl-like one would be the one chosen by most programmers, but the various reasons why it is chosen will fluctuate. Can we do better? Can we give a predictable measurement of some syntactic quantities that we can optimize and get a predictable answer? Most people would say the perl-like form has the least amount of "syntactic garbage" and is "short". How do we meaningfully define those two terms? One might say "syntactic garbage" is syntax which doesn't relate *at all* to the actual semantic objects, and "short" might mean elimination of redundant syntax and/or transformation of explicit syntax into implicit syntax already available in the metric space. What do I mean by explicit versus implicit? In the scheme-like form, we explicitly denote the evaluation and class of the various semantic objects of the regex before applying the "regex" function across the evaluated arguments. Whitespace is used to separate the morphemes of only the scheme syntax. The embedding metric space of the syntax (meaning the line of text indexed by character position) does nothing to help or hinder the expression of the semantic objects. In the perl-like form, we implicitly denote the evaluation of the regex by using a prototyping-based syntax, meaning the inherent qualities of the embedding metric space are utilized. This specifically means that evaluation happens left to right in reading order and semantic objects evaluate directly to themselves and take as arguments semantic objects as related directly in the embedding metric space. For example, the ? takes as an argument the semantic object at location index[?]-1. Grouping parenthsis act as a VERY simple tokenization system to group multiple objects into one syntactical datum. Given the analysis, it seems the perl-like regex generally auto-quote themselves as an advantageous use of the embeded metric space in which they reside (aka the line of text). The english-like form is the worst for explicit modeling because it abstracts the semantic objects into a meta-space that is then referenced by the syntax in the embedding space of the line itself. In human reasoning, that is what the quotes mean. Out of the three syntax models, only the perl one has no redundant syntax and takes up the smallest amount of the metric space into which it is embedded--clearly seen by observation. Consider if we have quantities "syntactic datums" versus "semantic objects", then one might make an equation like this: semantic objects expressiveness = syntactic datums And of course, expressiveness rises as semantic objects begin to outweigh syntactic objects. This seems a very reasonable, although simplistic, model to me and would be a good start in my estimation. I say simplistic because the semantic objects are not taken in relation to themselves on the metric space the syntactic datums are embeded, I'll get to this in a bit. Now, what do we do with the above equation, well, we define what we can, and then optimize the hell out of it. "semantic objects" for a computer language is probably a fixed quantity, there are only so many operators and grouping constructs, and usually very few, meaning one, function description semantic objects. So, we are left with a free variable of "syntactic datums" that we should minimize to be as small as possible. If we don't take into consideration the topological mapping of the
python doc available in emacs info format?
btw, is there still info format for python doc? i feel kinda sad that emacs info format has pretty much been deprecated over the past decade. About a decade ago, you still will see now and then people asking for emacs info format of docs (was the days of perl). Today, one don't hear of it. Part of this is due to emacs cult problem. See: • Emacs Modernization http://xahlee.org/emacs/emacs_modernization.html • Emacs Should Adopt HTML To Replace Texinfo http://xahlee.org/emacs/modernization_html_vs_info.html • Language, Purity, Cult, and Deception http://xahlee.org/UnixResource_dir/writ/lang_purity_cult_deception.html Xah ∑ http://xahlee.org/ ☄ On Dec 11 2008, 6:56 am, Matthias wrote: > Xah Lee writes: > > in programing elisp in emacs, i can press “Ctrl+h f” to lookup > > the doc for the function under cursor. is there such facility > > when coding in perl, python, php? > > Yes, try C-h S (or similarly S): > > (info-lookup-symbol SYMBOL &optional MODE) Display the > definition of SYMBOL, as found in the relevant manual. When this > command is called interactively, it reads SYMBOL from the > minibuffer. > > Note that `the relevant manual' means an info file. With recent > emacsen on an Ubuntu distro, python arrives with info files and > everything is well configured. It also works with bash, latex, perl, > scheme, elisp, awk, texinfo, makefile, libc, or any info file with an > index. > -- > Matthias -- http://mail.python.org/mailman/listinfo/python-list
Re: wxFormBuilder finally supports wxPython
On Sun, 16 Aug 2009 03:19:51 -0700, sturlamolden wrote: > Version 3.1 of wxFormBuilder can generate wxPython code. I have > previously used wxFormBuilder to generate XRC files for my wxPython > projects. Though still in beta, this might be even better. :-) Is there a reason to prefer code over XRC? -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 'for' loop is memory inefficient
On Sun, 16 Aug 2009 11:41:21 -0400, Benjamin Kaplan wrote: > It's not that the code is bad, but too many people coming from Java > and C keep thinking of for loops like they're using Java or C and > therefore that "for i in range(a,b)" is identical to "for(int i = a; i > < b; i++)". It's not and, for the most part, you shouldn't code like > that. Since you're using numbers, range/xrange is the appropriate > idiom but you still have to remember that a for loop in python doesn't > loop until a condition is met, it loops through an iterator until the > interator says it's done. Java also has iterators; it's more a case of people coming from C and BASIC. Although, some of those may have come *through* Java without abandoning old habits. You see the same thing with people coming from BASIC to C and writing: #define NUM_DATES 50 int day[NUM_DATES], month[NUM_DATES], year[NUM_DATES]; rather than defining a "struct". Sometimes referred to as "I know ten languages and can write in BASIC in all of them". -- http://mail.python.org/mailman/listinfo/python-list
Re: Social problems of Python doc [was Re: Python docs disappointing]
Thanks Raymond. I've been out of python community for a couple of years. I've saved your messages and will study it later when next time i work in python. Possibly today and will reply in some of your points. But just wanted to say thanks for improving python. Also, sometimes ago out of the blue i noticed someone has posted a bug on python's gzip doc with acknowledgement. http://bugs.python.org/issue2406 Thank you M.-A. DARCHE (madarche). Also, i noticed python doc now and later has improved a lot since last i looked around python 2.4. For one thing, the html/xhtml is now valid html. Good riddence of the fucking TeX. Also, code examples have syntax coloring on. Xah â http://xahlee.org/ â On Aug 12, 12:15 pm, Raymond Hettinger wrote: > [Xah Lee] > > > i've wrote several articles about this issue, total time spend on this > > is probably more than 2 months full-time work. See: > > > ⢠Python Documentation Problems > > http://xahlee.org/perl-python/python_doc_index.html > > I just read you post. You did devote a substantial amount of time > to the project. Some of your criticisms are valid. Wish you had > posted patches, I think many of them would have been accepted. > > Since you wrote this a few years ago, many examples have > been added to the docs and more are forthcoming. > > > I often receive thank you emails for 2 particular articles, which are > > most frequently google searched as indicated by my weblog: > > > ⢠Python Doc Problem Example: gzip > > http://xahlee.org/perl-python/python_doc_gzip.html > > > ⢠Python Doc Problem Example: sort() > > http://xahlee.org/perl-python/python_doc_sort.html > > > ⢠Sorting in Python and Perl > > http://xahlee.org/perl-python/sort_list.html > > Some are the criticisms are valid; others seem off-base. > > Here are a few thoughts on list.sort() for those who are interested: > > * The key= and reversed= parameters are not intended for special > cases, leaving cmp= for the general case. They were intended to > be full replacements. In Python3.x, the cmp function is gone. > > * The interaction of the key= and cmp= functions can be made to > interact (the key function is first applied to every element and > the cmp function then gets applied to the results of the key > function). This isn't a normal or intended use case, so the docs > don't delve into the subject. > > * The reversed parameter does more than list.sort() followed by > list.reverse(). It also preserves stability in the event of equal > keys: > >>>> sorted([(1,2), (1,3)], key=itemgetter(0), reverse=True) >[(1,2), (1,3)] > > So it was not correct to say that the following are equivalent: > > li.sort(lambda x, y: cmp(x[1],y[1]), reverse=True) > li.sort(lambda x, y: cmp(y[1],x[1])) > > * We should link the sorted() and list.sort() docs to the > sorting how-to (with a fuller discussion on the art of sorting > including a discussion of operator.itemgetter() and > operator.attrgetter() which were designed to work with the key= > parameter. > > Raymond -- http://mail.python.org/mailman/listinfo/python-list
Re: Xah's Edu Corner: The importance of syntax & notations.
w_a_x_man wrote: > On Aug 16, 11:05 am, Petey Keller wrote: >> Compiler go through *great* pains > > Compiler work real hard. > Compiler have heap big trouble. ROTFL. :-) -- Dr Jon D Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/?u -- http://mail.python.org/mailman/listinfo/python-list
[RELEASED] Python 3.1.1
On behalf of the Python development team, I'm happy to announce the first bugfix release of the Python 3.1 series, Python 3.1.1. This bug fix release fixes many normal bugs and several critical ones including potential data corruption in the io library. Python 3.1 focuses on the stabilization and optimization of the features and changes that Python 3.0 introduced. For example, the new I/O system has been rewritten in C for speed. File system APIs that use unicode strings now handle paths with undecodable bytes in them. Other features include an ordered dictionary implementation, a condensed syntax for nested with statements, and support for ttk Tile in Tkinter. For a more extensive list of changes in 3.1, see http://doc.python.org/3.1/whatsnew/3.1.html or Misc/NEWS in the Python distribution. Please note the Windows and Mac binaries are not available yet but will be in the coming days. To download Python 3.1.1 visit: http://www.python.org/download/releases/3.1.1/ The 3.1 documentation can be found at: http://docs.python.org/3.1 Bugs can always be reported to: http://bugs.python.org Enjoy! -- Benjamin Peterson Release Manager benjamin at python.org (on behalf of the entire python-dev team and 3.1.1's contributors) -- http://mail.python.org/mailman/listinfo/python-list
Re: OT Signature quote [was Re: Unrecognized escape sequences in string literals]
On Sun, 16 Aug 2009 05:05:01 +, Steven D'Aprano wrote:
> Now that I understand what the semantics of cout << "Hello world" are, I
> don't have any problem with it either. It is a bit weird, "Hello world"
> >> cout would probably be better,
Placing the stream on the LHS allows the main forms of << to be
implemented as methods of the ostream class. C++ only considers the LHS
operand when attempting to resolve an infix operator as a method.
Also, << and >> are left-associative, and that cannot be changed by
overloading. Having the ostream on the LHS allows the operators to be
chained:
cout << "Hello" << ", " << "world" << endl
equivalent to:
(((cout << "Hello") << ", ") << "world") << endl
[operator<< returns the ostream as its result.]
Even if you could make >> right-associative, the values would have to be
written right-to-left:
endl >> "world" >> ", " >> "Hello" >> cout
i.e.:
endl >> ("world" >> (", " >> ("Hello" >> cout)))
--
http://mail.python.org/mailman/listinfo/python-list
Re: Python 'for' loop is memory inefficient
On Aug 16, 3:35 pm, sturlamolden wrote: > On 16 Aug, 14:57, Dennis Lee Bieber wrote: > > > Well, the alternative would be to have two keywords for looping: one > > for your "simple" incrementing integer loop, and another for a loop that > > operates over the elements of some collection type. > > A compiler could easily recognise a statement like > > for i in range(n): > > as a simple integer loop. It would be a simple to do if you were writing it for a different langauge was a lot less dynamic than Python is. It'd be quite a complex hack to add it to CPython's compiler while maintaing the current highly dynamic runtime semantics and backwards compatibility, which is a design constraint of Python whether you like it or not. And all this complaining about an issue that can be worked around by xrange instead of range. Sheesh. > In fact, Cython is able to do this. Cython can do this easily because it is a different language that is a lot less dynamic than Python. If you don't care about the dynamic stuff why don't you just use Cython? Or quit complaining and just use xrange. Carl Banks -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 'for' loop is memory inefficient
On Aug 16, 6:28 pm, exar...@twistedmatrix.com wrote: > On 01:23 am, benjamin.kap...@case.edu wrote: > > >On Sun, Aug 16, 2009 at 6:35 PM, sturlamolden > >wrote: > > >>A compiler could easily recognise a statement like > > >> for i in range(n): > > >>as a simple integer loop. In fact, Cython is able to do this. > > >but special cases aren't special enough to break the rules. > > Although I think PyPy also recognizes this case and makes it as > efficient as using xrange, and does so without breaking any rules. PyPy uses a JIT compiler (which is still slower than CPython, suggesting that perhaps they should have spent more time optimizing the general case than optimizing for an easily avoided special case). > There *are* _some_ legitimate complaints to be made about the CPython > runtime. :) This isn't one of them. xrange has been part of Python for 10 years. If there are any complaints to be made about this situation it's that there are any 2.x learning materials anythere that continue to use range() and not xrange() in this context. Carl Banks -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 'for' loop is memory inefficient
exar...@twistedmatrix.com writes: > Although I think PyPy also recognizes this case and makes it as > efficient as using xrange, and does so without breaking any rules. How can pypy possibly know that the user hasn't assigned some other value to "range"? -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 'for' loop is memory inefficient
On 01:23 am, benjamin.kap...@case.edu wrote: On Sun, Aug 16, 2009 at 6:35 PM, sturlamolden wrote: A compiler could easily recognise a statement like � for i in range(n): as a simple integer loop. In fact, Cython is able to do this. but special cases aren't special enough to break the rules. Although I think PyPy also recognizes this case and makes it as efficient as using xrange, and does so without breaking any rules. There *are* _some_ legitimate complaints to be made about the CPython runtime. :) Jean-Paul -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 'for' loop is memory inefficient
On Aug 17, 8:35 am, sturlamolden wrote: > A compiler could easily recognise a statement like > for i in range(n): > as a simple integer loop. In fact, Cython is able to do this. Extremely easy, once users relinquish the right to replace built-in "range" with their own concoctions ... -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 'for' loop is memory inefficient
On Sun, Aug 16, 2009 at 6:35 PM, sturlamolden wrote: > > A compiler could easily recognise a statement like > > for i in range(n): > > as a simple integer loop. In fact, Cython is able to do this. but special cases aren't special enough to break the rules. -- http://mail.python.org/mailman/listinfo/python-list
Re: zip codes
On 2009-08-16, Shailen wrote: > Thanks Martin and Aahz. Anyone know if zip code information is > copyrighted for the US? You can't copyright "information" as such. Only concrete expressions of information. A particular publication containing zip code information can be copyrighted. The underlying facts themselve cannot be. -- Grant -- http://mail.python.org/mailman/listinfo/python-list
Re: zip codes
> It was a long time ago, I don't remember specifics, and the contents > are surely out of date by now, but I extracted a bunch of the TIGER > geographic coordinates for zip codes here: > > http://www.nightsong.com/phr/chess/zipcodes.zip That file may have actually come from here: http://www.census.gov/geo/www/tiger/zip1999.html -- http://mail.python.org/mailman/listinfo/python-list
Re: zip codes
Shailen writes: > Thanks Martin and Aahz. Anyone know if zip code information is > copyrighted for the US? Anyone can look up zip codes on usps.gov (and > other locations),so the information is readily available. I need zip > codes for a handful of cities and could map those myself (or write a > script to scrape them for me), but am not sure if they *MUST* be > purchased for copyright reasons. Anyone know? I don't think US zip code info is copyrighted. There is a lot of it in the TIGER database: http://www.census.gov/geo/www/tiger/tigerua/ua_tgr2k.html There are also some API's operated by usps.com if you want just a few lookups now and then. It was a long time ago, I don't remember specifics, and the contents are surely out of date by now, but I extracted a bunch of the TIGER geographic coordinates for zip codes here: http://www.nightsong.com/phr/chess/zipcodes.zip -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 'for' loop is memory inefficient
On 16 Aug, 14:57, Dennis Lee Bieber wrote: > Well, the alternative would be to have two keywords for looping: one > for your "simple" incrementing integer loop, and another for a loop that > operates over the elements of some collection type. A compiler could easily recognise a statement like for i in range(n): as a simple integer loop. In fact, Cython is able to do this. -- http://mail.python.org/mailman/listinfo/python-list
Re: zip codes
Thanks Martin and Aahz. Anyone know if zip code information is copyrighted for the US? Anyone can look up zip codes on usps.gov (and other locations),so the information is readily available. I need zip codes for a handful of cities and could map those myself (or write a script to scrape them for me), but am not sure if they *MUST* be purchased for copyright reasons. Anyone know? - Shailen Tuli -- http://mail.python.org/mailman/listinfo/python-list
Re: redoing libgmail interface to "smtplib" blah?
Dennis Lee Bieber wrote: On Sat, 15 Aug 2009 23:14:39 -0600, John Haggerty declaimed the following in gmane.comp.python.general: I did detect one problem thus far File "test.py", line 152 if len(args) == 1 and args[0] = "-c": Should have been fine, unless my memory of sys.argv contents was wrong (as I recall, sys.argv, if it behaves like other languages, would You missed the actual problem: there's a single '=' in the second part of the if expression. Should be "==" DaveA -- http://mail.python.org/mailman/listinfo/python-list
Re: Nltk with python
In article <82c9f923-1098-4b7e-8f9d-9504c1a89...@12g2000pri.googlegroups.com>, ArshaKrishna wrote: > >How can I resolve scope ambiguity using nltk toolkit with python Question not clear, please provide more explanation -- Aahz (a...@pythoncraft.com) <*> http://www.pythoncraft.com/ "I saw `cout' being shifted "Hello world" times to the left and stopped right there." --Steve Gonedes -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 2.6 still not giving memory back to the OS...
On Aug 15, 7:55 am, Chris Withers wrote:
> Hi All,
>
> I thought this was fixed back in Python 2.5, but I guess not?
>
> So, I'm playing in an interactive session:
>
> >>> from xlrd import open_workbook
> >>> b = open_workbook('some.xls',pickleable=0,formatting_info=1)
>
> At this point, top shows the process usage for python to be about 500Mb.
> That's okay, I'd expect that, b is big ;-)
>
> >>> del b
>
> However, it still does now, maybe the garbage collector needs a kick?
>
> >>> import gc
> >>> gc.collect()
> 702614
>
> Nope, still 500Mb. What gives? How can I make Python give the memory its
> no longer using back to the OS?
>
> Okay, so maybe this is something to do with it being an interactive
> session? So I wrote this script:
>
> from xlrd import open_workbook
> import gc
> b = open_workbook('some.xls',pickleable=0,formatting_info=1)
> print 'opened'
> raw_input()
> del b
> print 'deleted'
> raw_input()
> gc.collect()
> print 'gc'
> raw_input()
>
> The raw inputs are there so I can check the memory usage in top.
> Even after the gc, Python still hasn't given the memory back to the OS :-(
>
> What am I doing wrong?
>
> Chris
>
> --
> Simplistix - Content Management, Batch Processing & Python Consulting
> -http://www.simplistix.co.uk
Repeat the 'b = open_workbook ...' line in the interpreter several
times and track the memory usage after each execution. I noticed this
behavior on linux, but saw that after repeating it a few times memory
usage finally stop going up. Probably just the behavior of the
allocator.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Xah's Edu Corner: The importance of syntax & notations.
On Aug 16, 9:05 am, Peter Keller wrote:
> In comp.lang.scheme Xah Lee wrote:
>
> > Xah's Edu Corner: The importance of syntax & notations.
>
> >http://www.stephenwolfram.com/publications/recent/mathml/mathml_abstr...
>
> > this article should teach the coding sophomorons and computer
> > ?science? idiotic authors who harbor the notion that syntax is not
> > important, picked up by all the elite i-reddit & twittering & hacker
> > news am-hip dunces.
>
> I must have really tweaked you with my "Syntax is not important, ideas are."
> statement.
>
> I read Wolfram's article carefully. He applies an intuitive sense onto
> why he does or doesn't like a particular notation, but yet can't really
> elucidate his feelings. I'm surprised that didn't tweak you worse. He
> also goes so far as to mention that:
>
> "But actually we still don't know a clean simple way to represent things
> like geometrical diagrams in a kind of language-like notation. And
> my guess is that actually of all the math-like stuff out there, only
> a comparatively small fraction can actually be represented well with
> language-like notation."
>
For someone talking about notation and language, it is amusing that
Wolfram refuses to write grammatically correct sentences. Each of the
pseudo-sentences quoted above is a dependent clause. Wolfram writes
like that. He typically begins sentences with "but" or "and".
In the article cited, he also claims to be more-or-less the only
person alive to have thought about these issues, and that Mathematica
is the solution. This is not surprising,and it is nevertheless clear
that Wolfram has spent some time thinking about mathematical notation,
and some money developing fonts and such. His self-praise is perhaps
not deserved.
It is unfortunate that most users of Mathematica labor under a
misunderstanding of the meaning of the fundamental algorithmic
notation of that system, namely "function definition".
f[x_]:=x+1is not a function definition, although most users think
so.
In fact, it is a pattern/replacement rule.
If you want to write the equivalent of the lisp (defun f(x)(+ x 1))
you can do so in mathematica, but it looks like this:
f=#1+1&
or alternatively,
f=Function[Plus[Slot[1],1]]
or alternatively,
f= Function[{x},x+1]
How do those choices grab you for the Emmy in "Excellence in
Notation"?
By the way, what is wrong with f[x_]:=x+1?
While you might think it maps x->x+1 for all x, it does so only in
the absence of other rules involving f. Thus the presence of another
definition (actually another rule) ... f[z_]:=z^2/;OddQ[z] changes
the definition when the argument is an odd integer.
An equivalent definition is
f[z_?OddQ]:=z^2
now you could have 2 rules
f[x_?Predicate1]:= 123
f[x_?Predicate2]:= 456
and it might not be clear which Predicate is a subset of the other.
(It is clear that the blank pattern "_" is a superset of "_?OddQ" ).
So how does Mathematica deal with this situation?
The predicates are tested in some order until one returns True.
What order is that?
"Whenever the appropriate ordering is not clear, Mathematica stores
rules in the order you give them. "
Oh, when is the ordering not clear?
Uh, "you should realize that this [ordering] is not always possible".
(quotes from mathematica documentation , TheOrderingOfDefinitions.)
While Wolfram has provided an admirable summary of the history of
notation, his solution is less so.
RJF
--
http://mail.python.org/mailman/listinfo/python-list
Re: Xah's Edu Corner: The importance of syntax & notations.
On Aug 16, 12:05 pm, Peter Keller wrote: > In comp.lang.scheme Xah Lee wrote: > > > Xah's Edu Corner: The importance of syntax & notations. > > >http://www.stephenwolfram.com/publications/recent/mathml/mathml_abstr... > > > this article should teach the coding sophomorons and computer > > ?science? idiotic authors who harbor the notion that syntax is not > > important, picked up by all the elite i-reddit & twittering & hacker > > news am-hip dunces. > > I must have really tweaked you with my "Syntax is not important, ideas are." > statement. > > I read Wolfram's article carefully. He applies an intuitive sense onto > why he does or doesn't like a particular notation, but yet can't really > elucidate his feelings. Exactly; and as far as I can determine, Knuth does the same. He applies standards of *good taste* to his notation. (No surprise that he's also singled out for vituperation by the OP.) In my opinion Knuth believed in the value of literate programming for similar reasons: To try to exploit existing cognitive training. If your user base is familiar with English, or mathematical notation, or some other lexicography, try to exploit the pre-wired associations. Clearly this involves some intuition. > ... > Thank you. > > -pete -- http://mail.python.org/mailman/listinfo/python-list
Re: random.gauss vs. random.normalvariate
Dennis Lee Bieber writes: > > > No language can guard against independent access of a shared/global > > > object by multiple threads... > http://en.wikipedia.org/wiki/Erlang_(programming_language) > """ > Like operating system processes (and unlike green threads and operating > system threads) they have NO SHARED STATE between them. > """ > which seems to reinforce my statement, not refute it. Id say Erlang guards against independent access of shared/global objects by not allowing them. > (The Amiga was heavily dependent upon message ports... Having to > copy data buffers between processes would have slowed the system > down drastically [8MHz processor, in those days], It's perfectly ok for Erlang implementation to just pass pointers around, when the processes are on the same machine. Erlang prohibits data mutation so there isn't an issue of a process modifying some structure while another process is using it. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 'for' loop is memory inefficient
On 16 Aug, 11:45, "bartc" wrote: > A for-loop, for iterating over a simple sequence, should be one of the > fastest things in the language. Anyone experienced with interpreted high-level languages knows this is not true. Not because iterating a sequence is expensive, but because the interpreter is constantly executing the body of the loop. There is a reason why Matlab and Python/NumPy programmers rely heavily on vectorized array expressions for efficient numerics. The only thing more evil than a for-loop is recursive function calls. This does not mean Python is slow. It just means you have to program differently. -- http://mail.python.org/mailman/listinfo/python-list
Re: XPath support?
On Sun, 16 Aug 2009 20:29:15 +, kj wrote: > I'm looking for a XML parser that produces an object with full XPath > support. What I've been using up to now, xml.etree.ElementTree, fails > to support Xpath predicates, as in "sp...@eggs='3']/ham". > > What I'm trying to do is to read-in a large XML string, and parse it > into an object from which I can extract nodes matching selectors that > include such predicates. > > Any suggestions would be greatly appreciated. > > TIA! > > kynn Have you tried lxml (http://codespeak.net/lxml/)? Kev -- http://mail.python.org/mailman/listinfo/python-list
Re: XPath support?
kj schrieb: I'm looking for a XML parser that produces an object with full XPath support. What I've been using up to now, xml.etree.ElementTree, fails to support Xpath predicates, as in "sp...@eggs='3']/ham". What I'm trying to do is to read-in a large XML string, and parse it into an object from which I can extract nodes matching selectors that include such predicates. Any suggestions would be greatly appreciated. Try lxml. It's element-tree compatible, and supports xpath. Diez -- http://mail.python.org/mailman/listinfo/python-list
XPath support?
I'm looking for a XML parser that produces an object with full XPath support. What I've been using up to now, xml.etree.ElementTree, fails to support Xpath predicates, as in "sp...@eggs='3']/ham". What I'm trying to do is to read-in a large XML string, and parse it into an object from which I can extract nodes matching selectors that include such predicates. Any suggestions would be greatly appreciated. TIA! kynn -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 'for' loop is memory inefficient
bartc wrote: "Steven D'Aprano" wrote in message news:02969972$0$20647$c3e8...@news.astraweb.com... On Fri, 14 Aug 2009 18:25:45 -0700, Dr. Phillip M. Feldman wrote: It seems as though Python is actually expanding range(2,n) into a list of numbers, even though this is incredibly wasteful of memory. There should be a looping mechanism that generates the index variable values incrementally as they are needed. Others have already pointed out to you that xrange() (for Python 2.x) does what you want. In Python 3.x, the old range() is gone for good, and xrange() renamed to just range(). It does seem rather worrying that whoever originally thought up Python decided it would be a good idea to implement a simple 1 to N (or 0 to N-1) for-loop by first creating an array of N consecutive integers! Whoever? I am shocked! ;-) They must have known Python was going to be slow anyway, but this wouldn't have helped the speed any. Nor the memory consumption. A for-loop, for iterating over a simple sequence, should be one of the fastest things in the language. [Presumably the internal code that created those consecutive integers used a more conventional looping method...] -- http://mail.python.org/mailman/listinfo/python-list
Re: Splitting a string into substrings of equal size
On Aug 14, 8:22 pm, candide wrote: > Suppose you need to split a string into substrings of a given size (except > possibly the last substring). I make the hypothesis the first slice is at the > end of the string. > A typical example is provided by formatting a decimal string with thousands > separator. > > What is the pythonic way to do this ? > > For my part, i reach to this rather complicated code: > > # -- > > def comaSep(z,k=3, sep=','): > z=z[::-1] > x=[z[k*i:k*(i+1)][::-1] for i in range(1+(len(z)-1)/k)][::-1] > return sep.join(x) > > # Test > for z in ["75096042068045", "509", "12024", "7", "2009"]: > print z+" --> ", comaSep(z) > > # -- > > outputting : > > 75096042068045 --> 75,096,042,068,045 > 509 --> 509 > 12024 --> 12,024 > 7 --> 7 > 2009 --> 2,009 > > Thanks FWIW: def chunks(s, length=3): stop = len(s) start = stop - length while start > 0: yield s[start:stop] stop, start = start, start - length yield s[:stop] s = '1234567890' print ','.join(reversed(list(chunks(s # prints '1,234,567,890' -- http://mail.python.org/mailman/listinfo/python-list
Re: Xah's Edu Corner: The importance of syntax & notations.
In comp.lang.scheme w_a_x_man wrote: > On Aug 16, 11:05?am, Petey Keller wrote: >> Compiler go through *great* pains > > Compiler work real hard. > Compiler have heap big trouble. That's a funny observation in the context of this thread--which I appreciate, since syntax really is the cornerstone of meaning transferal between people. The unintended connotation brought in by what I mistakenly wrote underscores the value of syntax. However, what we don't have is a means of measuring the effectiveness and/or efficiency of expressing meaning for an arbitrary set of syntax rules. Computer Scientists can do this somewhat in that the expressive power of parsing is greater than regular expressions and both can use a syntax to represent them. But in a single complexity class, the "black art" of how to place a metric on a syntax is, at least at this time, relegated to the right brain and how it visually sees (and visually parses) the syntax and how our emotions relate to the syntax. The wolfram article, in fact, never does mention any metric other than "this is hard to understand, this is less hard to understand". In a sense, how is that useful at all? Instead of really trying to find a method by which understanding can be placed upon a metric (or discovering a method *can not* be found, he seems to anecdotally ascribe understanding difficulty upon various syntaxs. The real frustrations of Xah Lee might be explained by his denial of the right brain processing of syntax information. It is to be expected since most industrial cultures suppress right brain advancement (emotional understanding/social interaction, drawing, music, spatial relations) in lieu of left brain processing (language and syntax, symbolic manipulation (part, though not all of the skill set of math), object naming). In fact, his skills of communicating his ideas in a social setting which, in my opinion, are poor and stunted, is a red flag and the epitome of this type of cultural viewpoint. Thank you. -pete -- http://mail.python.org/mailman/listinfo/python-list
Re: OT Signature quote [was Re: Unrecognized escape sequences in string literals]
On Aug 16, 6:18 am, Steven D'Aprano wrote: > On Sun, 16 Aug 2009 01:41:41 -0700, Douglas Alan wrote: > > I would definitely not like a language that obscures assignment by > > moving it over to the right side of lines. > One could argue that left-assigned-from-right assignment obscures the > most important part of the assignment, namely *what* you're assigning, in > favour of what you're assigning *to*. The most important things are always the side-effects and the name- bindings. In a large program, it can be difficult to figure out where a name is defined, or which version of a name a particular line of code is seeing. Consequently languages should always go out of their way to make tracking this as easy as possible. Side effects are also a huge issue, and a source of many bugs. This is one of the reasons that that are many functional languages that prohibit or discourage side-effects. Side effects should be made as obvious as is feasible. This is why, for instance, in Scheme, variable assignment as an exclamation mark in it. E.g., (set! x (+ x 1)) The exclamation mark is to make the fact that a side effect is happening there stand out and be immediately apparent. And C++ provides the "const" declaration for similar reasons. > In any case, after half a century of left-from-right assignment, I think > it's worth the experiment in a teaching language or three to try it the > other way. The closest to this I know of is the family of languages > derived from Apple's Hypertalk, where you do assignment with: > > put somevalue into name That's okay with me, but only because the statement begins with "put", which lets you know at the very beginning of the line that something very important is happening. You don't have to scan all the way to the right before you notice. Still, I would prefer let name = somevalue as the "let" gives me the heads up right away, and then immediately after the "let" is the name that I might want to be able to scan for quickly. |>ouglas -- http://mail.python.org/mailman/listinfo/python-list
Re: random.gauss vs. random.normalvariate
John Haggerty wrote: On Sat, Aug 15, 2009 at 7:23 PM, Dennis Lee Bieber wrote: On Sat, 15 Aug 2009 14:34:36 -0600, John Haggerty declaimed the following in gmane.comp.python.general: What does the term "thread safe" mean exactly. I never had to program with "threads" before That, part way through the logic of the function, control could be switched to a different thread which call the same function... This second call would change some of the internal values and may then be preempted and control returned to the first thread, which continues the rest of the function with different values then it had when first preempted. A very contrived example, untested of course, consider it pseudo-code... startt = None def atimer(): global startt startt = time.time() time.sleep(5) print time.time() - startt t1 = threading.thread(atimer) t2 = threading.thread(atimer) t1.start() t2.start() Say t1 gets all the way up to the sleep call, and (since sleep is a releasing call), t2 then starts. t2 changes the value of startt; and sleeps... both sleep and presuming the resolution is fine enough, t1 resumes, and prints a delta time that is incorrect -- it is printing the time difference from when t2 started to sleep, not from when t1 started to sleep. -- Wulfraed Dennis Lee Bieber KD6MOG wlfr...@ix.netcom.com HTTP://wlfraed.home.netcom.com/ -- http://mail.python.org/mailman/listinfo/python-list Interesting so it seems that the compiler(c/c++)interpreter(perl, python)/vm(java) doesn't do this? It is impossible for a language, vm, or operating system to avoid threading problems without the programmer's help, except by trivial means (eg. preventing you from having them at all). The power of threading is entirely tied up with the features the environment gives to the developer, and those features come with a risk. At one extreme is the CP/M model. You start a new program only when you finish the previous one. So the only communication between them is a file the first one leaves behind, that the second can look at. Next is separate processes. If you launch a second process, by default, they're independent, and not likely to get into trouble. But you can build pipes or shared memory, or sockets between them, and then you have to worry about race conditions. Next is threads, within a single process. At this point, you can share (global) variables between them, or you can have objects known to both when the thread is launched. The system cannot tell which ones are deliberate and which ones are accidental. So a language might give extra keywords to tell the compiler that certain things should be protected in certain ways. Or it might give a way to declare a "per-thread global" that acts like a global to each thread, but is actually two independent variables from the process point of view. The only real reason threads are singled out is it's easier to collide by mistake. But that's also what makes it efficient to "collide" on purpose. DaveA -- http://mail.python.org/mailman/listinfo/python-list
Re: Splitting on '^' ?
And .splitlines seems to be able to handle all "standard" end-of-line > markers without any special direction (which, ironically, strikes > me as a *little* Perlish, somehow): > > >>> "spam\015\012ham\015eggs\012".splitlines(True) > ['spam\r\n', 'ham\r', 'eggs\n'] > ... actually "working correctly" and robustly is "perlish"? :) The only reason I've ever actually used this method is this very feature of it, that you can't readily reproduce with other methods unless you start getting into regular expressions (and I really believe regular expressions should not be the default place one looks to solve a problem in Python) Then again, as soon as Python started allowing you to open files with mode "rU", I gleefully ran through my codebase and changed every operation to that and made sure to write out with platform-local newlines exclusively, thus finally flipping off those darn files that users kept producing with mixed line endings. > Amazing. I'm not sure this is the *best* way to do this in general > (I would have preferred it, and IMHO it would have been more > Pythonic, if .splitlines accepted an additional optional argument > where one could specify the end-of-line sequence to be used for > the splitting, defaulting to the OS's conventional sequence, and > then it split *strictly* on that sequence). > If you want strict and absolute splitting, you don't need another method; just do mystring.split(os.linesep); I mean sure, it doesn't have the 'keepends' feature -- but I don't actually understand why you want keepends with a strict definition of endings... If you /only/ want to split on \n, you know there's an \n on the end of each line in the returned list and can easily be sure to write it out (for example) :) In the modern world of mixed systems and the internet, and files being flung around willy-nilly, and editors being configured to varying degrees of correctness, and such It's Pythonic to be able to handle all these files that anyone made on any system and treat them as they are clearly *meant* to be treated. Since the intention *is* clear that these are all *end of line* markers-- it's explicitly stated, just slightly differently depending on the OS-- Python treats all of the line-endings as equal on read if you want it to. By using either str.splitlines() or opening a text file as "rU". Thank goodness for that :) In some cases you may need a more pedantic approach to line endings. In that case, just use str.split() :) --S -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 'for' loop is memory inefficient
"Steven D'Aprano" wrote in message news:02969972$0$20647$c3e8...@news.astraweb.com... On Fri, 14 Aug 2009 18:25:45 -0700, Dr. Phillip M. Feldman wrote: It seems as though Python is actually expanding range(2,n) into a list of numbers, even though this is incredibly wasteful of memory. There should be a looping mechanism that generates the index variable values incrementally as they are needed. Others have already pointed out to you that xrange() (for Python 2.x) does what you want. In Python 3.x, the old range() is gone for good, and xrange() renamed to just range(). It does seem rather worrying that whoever originally thought up Python decided it would be a good idea to implement a simple 1 to N (or 0 to N-1) for-loop by first creating an array of N consecutive integers! They must have known Python was going to be slow anyway, but this wouldn't have helped the speed any. Nor the memory consumption. A for-loop, for iterating over a simple sequence, should be one of the fastest things in the language. [Presumably the internal code that created those consecutive integers used a more conventional looping method...] -- Bartc -- http://mail.python.org/mailman/listinfo/python-list
Re: Splitting on '^' ?
On Aug 16, 1:09 pm, kj wrote: > And .splitlines seems to be able to handle all > "standard" end-of-line markers without any special > direction (which, ironically, strikes > me as a *little* Perlish, somehow): It's Pythonic. Universal newline-handling for text has been a staple of Python for as long as I can remember (very possibly since the very beginning). > >>> "spam\015\012ham\015eggs\012".splitlines(True) > > ['spam\r\n', 'ham\r', 'eggs\n'] > > Amazing. I'm not sure this is the *best* way to do > this in general (I would have preferred it, and IMHO > it would have been more Pythonic, if .splitlines > accepted an additional optional argument [...]). I believe it's the best way. When you can use a string method instead of a regex, it's definitely most Pythonic to use the string method. I would argue that this particular string method is Pythonic in design. Remember, Python strives not only for explicitness, but simplicity and ease of use. When dealing with text, universal newlines are much more often than not simpler and easier for the programmer. John -- http://mail.python.org/mailman/listinfo/python-list
Re: problem with interface of operator.itemgetter
On Thu, Aug 13, 2009 at 11:16 PM, dou dou wrote:
> I have a function to do some thing like LEFT JOIN in SQL, the function use
> the itemgetter to get the "ON" and "SELECT" parameters of the two table(list
> of list), the problem is that itemgetter may return a value or a tuple of
> values, because of the inconsistent return type of itemgetter, I have to do
> 2^3 IF check,
> the function like this:
>
> def left_join(table1, on_index1, table2, on_index2, getter1, getter2):
> """do thing like:
> SELECT on1(table1), g1(table1), g2(table2) FROM table1
> LEFT JOIN table2
> ON on1(table1) == on2(table2)
> """
> on1 = itemgetter(*on_index1)
> on2 = itemgetter(*on_index2)
> g1 = itemgetter(*getter1)
> g2 = itemgetter(*getter2)
>
> d2 = {}
> d2 = dict((on2(r2), r2) for r2 in table2)
>
> #if itemgetter always return tuple, below could simple as one line
> #return [ list(on1(r1) + g1(r1) + g2(d2.get(on1(r1 for r1 in table1
> ]
>
> len_on = len(on_index1)
> len_g1 = len(getter1)
> len_g2 = len(getter2)
>
> if len_on == 1:
> if len_g1 == 1 and len_g2 == 1:
> return [ [on1(r1), g1(r1), g2(d2.get(on1(r1)))] for r1 in table1
> ]
> elif len_g1 == 1 and len_g2 > 1:
> return [ list((on1(r1),g1(r1))+g2(d2.get(on1(r1 for r1 in
> table1 ]
> elif len_g1 > 1 and len_g2 == 1:
> return [ list((on1(r1),)+g1(r1)+(g2(d2.get(on1(r1))),)) for r1
> in table1 ]
> else: #len_g1 > 1 and len_g2 > 1:
> return [ list((on1(r1),)+g1(r1)+g2(d2.get(on1(r1 for r1 in
> table1 ]
> else: # len_on > 1
> if len_g1 == 1 and len_g2 == 1:
> return [ list(on1(r1))+[g1(r1),g2(d2.get(on1(r1)))] for r1 in
> table1 ]
> elif len_g1 == 1 and len_g2 > 1:
> return [ list(on1(r1)+(g1(r1),)+g2(d2.get(on1(r1 for r1 in
> table1 ]
> elif len_g1 > 1 and len_g2 == 1:
> return [ list(on1(r1)+g1(r1)+(g2(d2.get(on1(r1))),)) for r1 in
> table1 ]
> else: #len_g1 > 1 and len_g2 > 1:
> return [ list(on1(r1)+g1(r1)+g2(d2.get(on1(r1 for r1 in
> table1 ]
>
> so is there a way to force itemgetter to return tuple even when
> itemgetter(only_have_one_argument)? or some other function to do this?
>
> Thanks.
>
You can use a little helper function to create your itemgetter like this:
def makeItemGetter(indexes):
I = itemgetter(*indexes)
if len(indexes) > 1:
return I
return lambda thing: (I(thing),)
If indexes contains only one index the itemgetter is wrapped in a
lambda that turns its output into a tuple.
HTH,
~Simon
--
http://mail.python.org/mailman/listinfo/python-list
Re: Xah's Edu Corner: The importance of syntax & notations.
On Aug 16, 11:05 am, Petey Keller wrote: > Compiler go through *great* pains Compiler work real hard. Compiler have heap big trouble. -- http://mail.python.org/mailman/listinfo/python-list
Re: OT Signature quote [was Re: Unrecognized escape sequences in string literals]
On Aug 16, 8:45 am, MRAB wrote: > No, APL is strictly right-to-left. > > -> x > > means "goto x". > > Writing to the console is: > > [] <- myVar > > Reading from the console is: > > myVar <- [] Ah, thanks for the correction. It's been 5,000 years since I used APL! |>ouglas -- http://mail.python.org/mailman/listinfo/python-list
Re: flatten a list of list
Terry writes: > Is there a simple way (the pythonic way) to flatten a list of list? > rather than my current solution: > > new_list=[] > for l in list_of_list: > new_list.extend(l) from itertools import chain new_list = list(chain(list_of_list)) -- http://mail.python.org/mailman/listinfo/python-list
Re: flatten a list of list
On 8/16/2009 5:47 AM Terry apparently wrote: > Is there a simple way (the pythonic way) to flatten a list of list? > rather than my current solution: > new_list=[] > for l in list_of_list: > new_list.extend(l) new_list = list(xi for lst in list_of_list for xi in lst) hth, Alan Isaac -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 2.6 still not giving memory back to the OS...
> As far as releasing memory back to the OS is concerned, I have dim > memories of *x systems where free() would return space to the OS if > the block was "large" and it was next to the "break" point ... this > effect could be what you are seeing. Today, there are two cases when malloc returns memory on a typical Unix system (in particular, in Linux malloc): a) if the malloc block block is small (below page size), it is allocated from the brk heap, where it can only be returned if the last page of that heap is completely free, and b) if the block is large (multiple pages), it gets returned to the system right away. Case b) can only happen if the C malloc uses mmap to allocate large blocks. For Python, case b) is realistic, in the sense that most allocations go to Python's obmalloc, and those allocate from C malloc in chunks of 256kiB (IIRC). So when such an arena is completely free (not a single Python object allocated on it anymore), it can get returned to the system. In some case, Python also allocates smaller blocks from C malloc; in this case, a) will trigger. So as long as something at the end of the heap stays allocated, C malloc will not return anything from the brk heap to the system. Regards, Martin -- http://mail.python.org/mailman/listinfo/python-list
Re: flatten a list of list
On Aug 16, 1:25 pm, Steven D'Aprano wrote:
...
> Chris' suggestion using itertools seems pretty good:
>
> >>> from timeit import Timer
> >>> setup = """\\
>
> ... L = [ [None]*5000 for _ in xrange(%d) ]
> ... from itertools import chain
> ... """>>> Timer("list(chain.from_iterable(L))", setup %
> 4).repeat(number=1000)
>
> [0.61839914321899414, 0.61799716949462891, 0.62065696716308594]>>>
> Timer("list(chain.from_iterable(L))", setup % 8).repeat(number=1000)
>
> [1.2618398666381836, 1.3385050296783447, 3.9113419055938721]>>>
> Timer("list(chain.from_iterable(L))", setup % 16).repeat(number=1000)
>
> [3.1349358558654785, 4.8554730415344238, 5.431217987061]
>
> --
> Steven
I had a peek at itertools ( which is a C module btw) and realized that
chain solves the problem by creating a chain object,
which is a sort of generator. Both creating the chain object and
converting the chain object to a list seem to be O(N), so
the whole is O(N) too ...
Then I tried this pure python version:
# - CODE
from timeit import Timer
setup = """\\
L = [ [None]*5000 for _ in range(%d) ]
def pychain( list_of_list ):
for l in list_of_list:
for elem in l:
yield elem
"""
print( Timer("list(pychain(L))", setup % 4).repeat(number=1000))
print( Timer("list(pychain(L))", setup % 8).repeat(number=1000))
print( Timer("list(pychain(L))", setup % 16).repeat(number=1000))
# - END CODE
and got times that seem to confirm it :
[2.818755865097046, 2.7880589962005615, 2.79232120513916]
[5.588631868362427, 5.588244915008545, 5.587780952453613]
[11.620548009872437, 11.39465618133545, 11.40834903717041]
For reference, here are the times of the itertools.chain solution on
my laptop:
[0.6518809795379639, 0.6491332054138184, 0.6483590602874756]
[1.3188841342926025, 1.3173959255218506, 1.3207998275756836]
[2.7200729846954346, 2.5402050018310547, 2.543621063232422]
All this with Python 3.1 compiled from source on Xubuntu 8.10.
Ciao
-
FB
--
http://mail.python.org/mailman/listinfo/python-list
Re: Komodo(!)
Kee Nethery wrote: I've heard there is a nice add-on to Eclipse but Eclipse has even more setup variables than Wings and I've avoided it for that reason. Hi I've just started using python and since I've been an eclipse user for many years I tried http://pydev.sourceforge.net/ and I really enjoyed that! :-) cheers Lorenzo -- Lorenzo Bettini, PhD in Computer Science, DI, Univ. Torino ICQ# lbetto, 16080134 (GNU/Linux User # 158233) HOME: http://www.lorenzobettini.it MUSIC: http://www.purplesucker.com http://www.myspace.com/supertrouperabba BLOGS: http://tronprog.blogspot.com http://longlivemusic.blogspot.com http://www.gnu.org/software/src-highlite http://www.gnu.org/software/gengetopt http://www.gnu.org/software/gengen http://doublecpp.sourceforge.net -- http://mail.python.org/mailman/listinfo/python-list
Re: Splitting on '^' ?
In ru...@yahoo.com writes: >On Aug 14, 2:23=A0pm, kj wrote: >> Sometimes I want to split a string into lines, preserving the >> end-of-line markers. =A0In Perl this is really easy to do, by splitting >> on the beginning-of-line anchor: >> >> =A0 @lines =3D split /^/, $string; >> >> But I can't figure out how to do the same thing with Python. =A0E.g.: >Why not this? lines =3D 'spam\nham\neggs\n'.splitlines (True) lines >['spam\n', 'ham\n', 'eggs\n'] That's perfect. And .splitlines seems to be able to handle all "standard" end-of-line markers without any special direction (which, ironically, strikes me as a *little* Perlish, somehow): >>> "spam\015\012ham\015eggs\012".splitlines(True) ['spam\r\n', 'ham\r', 'eggs\n'] Amazing. I'm not sure this is the *best* way to do this in general (I would have preferred it, and IMHO it would have been more Pythonic, if .splitlines accepted an additional optional argument where one could specify the end-of-line sequence to be used for the splitting, defaulting to the OS's conventional sequence, and then it split *strictly* on that sequence). But for now this .splitlines will do nicely. Thanks! kynn -- http://mail.python.org/mailman/listinfo/python-list
Re: Python or ActionScript 3.0
On Aug 16, 9:30 pm, paul wrote: > Jaseem schrieb:> Hi, > > > Is python similar to actionscript 3.0 > > Not really. > > > Which is better to create a rich gui internet application? > > Is it AS 3.0 with flex or python with its GUI libs? > > Flex+AS3 definitely! (it's been designed for that, no surprise here) > > > > > Is python in demand? > > Depends. It seems quite popular in the scientific community and for > system administration these days. > > > Heard that python is similar to lisp. But both python and AS 3.0 is > > almost identical. Which is more similar to lisp are powerful? > > If python is 100m away from lisp, than it's 102.32m for AS3. > > cheers > Paul > > > > > Thank You. > > Alright! -- http://mail.python.org/mailman/listinfo/python-list
Re: What happened to __cmp__() in Python 3.x?
[Xavier Ho] > > I've recently made my way to Python 3.1 and I'm not seeing __cmp__() in the > > documentation. > > > Is there a substitution for this special method in 3.1, or do I really have > > to define all six rich comparison methods to work it out? FWIW, there is a recipe for expanding the comparison operators: http://code.activestate.com/recipes/576685/ Raymond -- http://mail.python.org/mailman/listinfo/python-list
Re: flatten a list of list
Steven D'Aprano wrote:
On Sun, 16 Aug 2009 02:47:42 -0700, Terry wrote:
Is there a simple way (the pythonic way) to flatten a list of list?
Chris' suggestion using itertools seems pretty good:
from timeit import Timer
setup = """\\
... L = [ [None]*5000 for _ in xrange(%d) ]
... from itertools import chain
... """
Timer("list(chain.from_iterable(L))", setup % 4).repeat(number=1000)
[0.61839914321899414, 0.61799716949462891, 0.62065696716308594]
Timer("list(chain.from_iterable(L))", setup % 8).repeat(number=1000)
[1.2618398666381836, 1.3385050296783447, 3.9113419055938721]
Timer("list(chain.from_iterable(L))", setup % 16).repeat(number=1000)
[3.1349358558654785, 4.8554730415344238, 5.431217987061]
OK, it definitely helps to get a size estimate before building:
>>> setup = """\\
L = [ [None]*5000 for _ in xrange(%d) ]
import itertools
class Holder(object):
def __init__(self, list_of_lists):
self._list = list_of_lists
def __iter__(self):
return itertools.chain.from_iterable(self._list)
def __len__(self):
return sum(len(x) for x in self._list)
"""
>>> timeit.Timer("list(Holder(L))", setup % 4).repeat(number=1000)
[0.59912279353940789, 0.59505886921382967, 0.59474989139681611]
>>> timeit.Timer("list(Holder(L))", setup % 8).repeat(number=1000)
[1.1898235669617208, 1.194797383466323, 1.1945367358141823]
>>> timeit.Timer("list(Holder(L))", setup % 16).repeat(number=1000)
[2.4244464031043123, 2.4261885239604482, 2.4050011942858589]
vs straight chain.from_iterable (on my machine):
[0.7828263089303249, 0.79326171343005925, 0.80967664884783019]
[1.499510971366476, 1.5263249938190455, 1.5599706107899181]
[3.4427520816193109, 3.632409426337702, 3.5290488036887382]
--Scott David Daniels
scott.dani...@acm.org
--
http://mail.python.org/mailman/listinfo/python-list
Re: Python or ActionScript 3.0
Jaseem schrieb: Hi, Is python similar to actionscript 3.0 Not really. Which is better to create a rich gui internet application? Is it AS 3.0 with flex or python with its GUI libs? Flex+AS3 definitely! (it's been designed for that, no surprise here) Is python in demand? Depends. It seems quite popular in the scientific community and for system administration these days. Heard that python is similar to lisp. But both python and AS 3.0 is almost identical. Which is more similar to lisp are powerful? If python is 100m away from lisp, than it's 102.32m for AS3. cheers Paul Thank You. -- http://mail.python.org/mailman/listinfo/python-list
Re: my recursive function call is wrong?
Dear Kev Thank you very much. I got it.:) 2009/8/16 Kev Dwyer > On Sun, 16 Aug 2009 16:57:41 +0900, Chang Min Jeon wrote: > > > Hello, > > You have placed recursive calls to the function in a number of different > locations; when len(macro) becomes zero control will return to the > calling function, but this calling function may have more code to > execute, including further calls to start_parse(), and further attempts > to index macro. > > I like to keep recursive calls at the end of a function, so that there is > a clean path back to the top level caller once the terminal condition is > reached. You can do it differently, but you need to bear in mind the > execution paths through your code. > > Cheers, > > Kev > > -- > http://mail.python.org/mailman/listinfo/python-list > -- CashFlow To be rich. -- http://mail.python.org/mailman/listinfo/python-list
Re: Xah's Edu Corner: The importance of syntax & notations.
In comp.lang.scheme Xah Lee wrote: > Xah's Edu Corner: The importance of syntax & notations. > > http://www.stephenwolfram.com/publications/recent/mathml/mathml_abstract.html > > this article should teach the coding sophomorons and computer > ?science? idiotic authors who harbor the notion that syntax is not > important, picked up by all the elite i-reddit & twittering & hacker > news am-hip dunces. I must have really tweaked you with my "Syntax is not important, ideas are." statement. I read Wolfram's article carefully. He applies an intuitive sense onto why he does or doesn't like a particular notation, but yet can't really elucidate his feelings. I'm surprised that didn't tweak you worse. He also goes so far as to mention that: "But actually we still don't know a clean simple way to represent things like geometrical diagrams in a kind of language-like notation. And my guess is that actually of all the math-like stuff out there, only a comparatively small fraction can actually be represented well with language-like notation." It is simply that the method by which the right brain categorizes and processes visual information is not observable by the left brain. Therefore no language can EVER be constructed by the left brain to represent why the right brain "prefers" some visual layouts for languages over others. I've done enough classical art training in my life to understand the conflict between the powerful spatial/visual processor the right brain has and the (in the context of drawing) meaningless linguistics of trying to describe the process. Only when we as human beings build the observation channels needed (with physical connection between certain areas of the left and right sides of the brain) will any sort of meaningful left brain language be created for the visual understanding/gradation of the spatial relationship and the method by which our right brain performs its processing. If you want to design a better computer language, hire an artist. Most semantic objects in programs stand in some spatio-temporal relation to each other. If you deny that fact, then simply look at the directed acyclic form/SSA form/CPS transform of any of your favorite languages. Compiler go through *great* pains to transform left brain scribblings into large spatio-temporal "2d images" where lots of algorithms are done before converting them into assembly. This is because it is simply easier to visually understand how to do the processing of those elements than not. Thank you. -pete -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 'for' loop is memory inefficient
On Sun, Aug 16, 2009 at 2:30 AM, Emmanuel Surleau wrote: > > I don't see what's particularly un-Pythonic with this code. Not using xrange() > is a mistake, certainly, but it remains clear, easily understandable code > which correctly demonstrates the naive algorithm for detecting whether n is a > prime. It doesn't call for condescension It's not that the code is bad, but too many people coming from Java and C keep thinking of for loops like they're using Java or C and therefore that "for i in range(a,b)" is identical to "for(int i = a; i < b; i++)". It's not and, for the most part, you shouldn't code like that. Since you're using numbers, range/xrange is the appropriate idiom but you still have to remember that a for loop in python doesn't loop until a condition is met, it loops through an iterator until the interator says it's done. -- http://mail.python.org/mailman/listinfo/python-list
Re: Surpressing Warnings
This is strange because I actually had "if exists" in my code: sqlKWDrop = 'DROP TABLE IF EXISTS ' + kwTable + ';' where kwTable, in the instance cited below, becomes "judaism_128". What gives? Victor On Sun, Aug 9, 2009 at 7:57 PM, Dennis Lee Bieber wrote: > On Sun, 9 Aug 2009 15:21:43 -0500, Victor Subervi > declaimed the following in > gmane.comp.python.general: > > > Hi: > > I get a ton of warnings like this from a program I run: > > > > Warning (from warnings module): > > File "C:\Python25\read.py", line 67 > > cursor.execute(sqlKWDrop) > > Warning: Unknown table 'judaism_128' > > > Personally -- I'd suggest fixing the database so that the table > does > exist... > >Ah, but then -- it appears from the name, that the purpose of this > SQL statement is to delete the table... In which case use a database > that supports (for example, current versions of MySQL, SQLite, and > PostgreSQL) "drop table IF EXISTS tbl_name" which suppress the > warning/error message and update the SQL as appropriate. > >Appears that M$ SQL Server does NOT implement that syntax... Nor > could I find it for Firebird. > >If the application is specific for one database engine, it might be > worth it to find out what features permit discovering if a table exists > and bypassing the drop if it doesn't... > > > -- >Wulfraed Dennis Lee Bieber KD6MOG >wlfr...@ix.netcom.com HTTP://wlfraed.home.netcom.com/ > > -- > http://mail.python.org/mailman/listinfo/python-list > -- http://mail.python.org/mailman/listinfo/python-list
Re: callable virtual method
Christian Heimes a écrit : Jean-Michel Pichavant wrote: scott.dani...@acm.org That could do the trick, sparing me from writing additional code in each methods. Thanks. Why are you trying to reinvent the wheel? Python's abc module already takes care of these details. Christian I'm working with python 2.4 and don't plan to change. The abc module would have been exactly what I was looking for. I'll keep it mind if I ever upgrade to python 2.6+ JM -- http://mail.python.org/mailman/listinfo/python-list
Re: callable virtual method
Christian Heimes wrote: Jean-Michel Pichavant wrote: talking about approaches: 1/ class Interface: def foo(self): if self.__class__.foo == Interface.foo: raise NotImplementedError 2/ class Interface: def foo(self): self._foo() def _foo(sef): raise NotImplementedError Please don't call it an interface when it's really an abstract base class. And abstract base classes are probably the solution the OP is looking for, http://docs.python.org/library/abc.html Christian Sadly I'm working with python 2.4. Anyway it's good to hear they've added ABC support to python, didn't know that. I didn't know there was a difference between interface and abstract classes as well. With a little bit of googling, I found out that actually Interface classes do not provide any implementation. What I'm looking for is definitely an abstract class. JM -- http://mail.python.org/mailman/listinfo/python-list
Re: callable virtual method
Jean-Michel Pichavant wrote: scott.dani...@acm.org That could do the trick, sparing me from writing additional code in each methods. Thanks. Why are you trying to reinvent the wheel? Python's abc module already takes care of these details. Christian -- http://mail.python.org/mailman/listinfo/python-list
Re: Is it possible to use python to get True Full Duplex on a Serial port?
On 2009-08-15, Hendrik van Rooyen wrote: > On Saturday 15 August 2009 16:25:03 Grant Edwards wrote: > >> Are you using python file operations open/read/write or OS >> file-descriptor operations os.open/os.read/os.write? > > The former - that seems to be the source of my trouble. > > I have now written a little test that uses serial.Serial and > it works a treat. Good to hear. > I am still confused about pyserial and serial - I found serial > in my distribution library, (on the SuSe machine, not on the > 2.5 in Slackware) but I had to download pyserial. That's very interesting. Is the pre-existing "serial" a version of pyserial that the packager had pre-installed or is it something else? I didn't know any distributions shipped Python with pyserial installed. In either case, "serial" isn't something that ships with the standard Python library. > I see that you were the the original author. Thank you for > letting this stuff loose in the wild. My pleasure. -- -- http://mail.python.org/mailman/listinfo/python-list
Re: callable virtual method
Scott David Daniels wrote:
Jean-Michel Pichavant wrote:
Steven D'Aprano wrote:
On Fri, 14 Aug 2009 18:49:26 +0200, Jean-Michel Pichavant wrote:
Sorry guys (means guys *and* gals :op ), I realized I've not been able
to describe precisely what I want to do. I'd like the base class to be
virtual (aka abstract). However it may be abstract but it does not
mean
it cannot do some usefull stuff.
Here is the schema of my abstract methods :
class Interface(object):
def method(self):
# -
# some common stuff executed here
# -
print 'hello world'
# -
# here shall stand child specific stuff (empty in the
interface
method)
# -
if self.__class__.method == Interface.method:
raise NotImplementedError('You should have read the
f**
manual ! You must override this method.')
Okay, so I want to sub-class your Interface class. As you said, the
methods in the abstract class are still useful, so in my class, I
don't need any extra functionality for some methods -- I'm happy
with just the "common stuff". So I use normal OO techniques and
over-ride just the methods I need to over-ride:
Sometimes the base is doing cool stuff but incomplete stuff which
requires knowledge only hold by the sub class. In my case the
interface is a high level interface for a software that can run on
multiple hardware platforms. Only the sub class has knowledge on how
to operate the hardware, but no matter the hardware it still produces
the same effect.
Let's say I have 50 different hardwares, I'll have 50 sub classes of
Interface with the 'start' method to define. It wouldn't be
appropriate (OO programming)to write 50 times '_log.debug('Starting
%s' % self)' in each child start method when the simple task of
logging the call can be nicely handled by the base class.
In the meantime, I must make sure the user, who is not a python guru
in this case, has implemented the start method for his hardware,
because only him knows how to effectively start this hardware. I
don't want him to come to me saying, "I got no error, still my
hardware does not start". You can then blame him for not reading the
docs, but it will still be less expensive to throw a nice exception
with an accurate feedback.
[snip]
class VerboseGoodChild(Interface):
# forced to over-ride methods for no good reason
Definitely no !! This is the purpose of an interface class: to force
people to write these methods. They *are* required, if they were not,
they would not belong to the Interface.
JM
But there _is_ one moment when you can check those things, then avoid
checking thereafter: object creation. So you can complicate your
__init__ (or __new__) with those checks that make sure you instantiate
only fully defined subclasses:
# obviously not tested except in concept:
class Base(object_or_whatever):
def __init__(self, ...):
class_ = self.__class__
if class_ is Base:
raise TypeError('Attempt to instantiate Base class')
for name in 'one two three four':
if getattr(Base, name) is not getattr(Base, name):
raise NotImplementedError(
'%s implementation missing' % name)
...
--Scott David Daniels
scott.dani...@acm.org
That could do the trick, sparing me from writing additional code in each
methods. Thanks.
JM
--
http://mail.python.org/mailman/listinfo/python-list
Re: Python 'for' loop is memory inefficient
> It's a particular unfair criticism because the critic (Ethan Furman) > appears to have made a knee-jerk reaction. The "some language in Python" > behaviour he's reacting to is the common idiom: > > for i in range(len(seq)): > do_something_with(seq[i]) > > > instead of the "Python in Python" idiom: > > for obj in seq: > do_something_with(obj) > > > That's a reasonable criticism, but *not in the case*. Ethan appears to > have made the knee-jerk reaction "for i in range() is Bad" without > stopping to think about what this specific piece of code is actually > doing. > > (Replace 'obj' with 'j', 'seq' with 'range(2, n)', and > 'do_something_with' with 'if (n % j) == 0: return False', and you have > the exact same code pattern.) Fair enough. But as far as I know, for i in (x)range(num) is the canonical way to iterate over numbers in Python. Another case of lack of RTFM* before answering, I suppose. Cheers, Emm *Read The Fine Mail -- http://mail.python.org/mailman/listinfo/python-list
Re: my recursive function call is wrong?
On Sun, 16 Aug 2009 16:57:41 +0900, Chang Min Jeon wrote: Hello, You have placed recursive calls to the function in a number of different locations; when len(macro) becomes zero control will return to the calling function, but this calling function may have more code to execute, including further calls to start_parse(), and further attempts to index macro. I like to keep recursive calls at the end of a function, so that there is a clean path back to the top level caller once the terminal condition is reached. You can do it differently, but you need to bear in mind the execution paths through your code. Cheers, Kev -- http://mail.python.org/mailman/listinfo/python-list
Re: unittest
John: Well, this is actually a script which wraps around another application. :-) My goal is when I introduce a new feature I don't want to break old stuff so instead of me testing manually I want to build a framework of tests. On Sat, Aug 15, 2009 at 11:37 PM, John Haggerty wrote: > This is an interesting question. I am just wondering: do you really have > that many features that it would be impossible to just have a shell script > run specific types of input or tests? > > When I did programming in the past for education they just had lists of > input data and we ran the program against the test data. > > I just get slightly confused when "test suites" start to have to apply? > > On Fri, Aug 14, 2009 at 9:28 PM, Mag Gam wrote: >> >> I am writing an application which has many command line arguments. >> For example: foo.py -args "bar bee" >> >> I would like to create a test suit using unittest so when I add >> features to "foo.py" I don't want to break other things. I just heard >> about unittest and would love to use it for this type of thing. >> >> so my question is, when I do these tests do I have to code them into >> foo.py? I prefer having a footest.py which will run the regression >> tests. Any thoughts about this? >> >> TIA >> -- >> http://mail.python.org/mailman/listinfo/python-list > > -- http://mail.python.org/mailman/listinfo/python-list
Re: OT Signature quote [was Re: Unrecognized escape sequences in string literals]
Douglas Alan wrote: [snip] C++ also allows for reading from stdin like so: cin >> myVar; I think the direction of the arrows probably derives from languages like APL, which had notation something like so: myVar <- 3 [] <- myVar "<-" was really a little arrow symbol (APL didn't use ascii), and the first line above would assign the value 3 to myVar. In the second line, the "[]" was really a little box symbol and represented the terminal. Assigning to the box would cause the output to be printed on the terminal, so the above would output "3". If you did this: [] -> myVar It would read a value into myVar from the terminal. APL predates Unix by quite a few years. No, APL is strictly right-to-left. -> x means "goto x". Writing to the console is: [] <- myVar Reading from the console is: myVar <- [] -- http://mail.python.org/mailman/listinfo/python-list
Re: What happened to __cmp__() in Python 3.x?
Xavier Ho wrote: On Sun, Aug 16, 2009 at 9:49 PM, Mark Lawrence wrote: Unfortunately I don't think it's that easy, see. http://mail.python.org/pipermail/python-list/2008-November/688761.html The issue referenced is still open. This of course assumes that I've posted the correct link this time! I'm not sure what you're referring to here. The link brought me to about __ne__ being automatically determined when __eq__ is defined. Although it is a rich comparison special method, it doesn't entirely cover the usefulness of __cmp__(). Terry: I'll give that a test tomorrow and see what I can come up with. Thanks for the quick info. Regards, Ching-Yun "Xavier" Ho, Technical Artist Contact Information Mobile: (+61) 04 3335 4748 Skype ID: SpaXe85 Email: cont...@xavierho.com Website: http://xavierho.com/ I wasn't discussing __cmp__, I was referring to the quote by Chris Rebert from the Python docs regarding the rich comparison methods, a discrepancy between the documentation and the implementation as noted in the link that I gave, and an indication that the issue raised on this discrepancy is still open. As Terry Reedy has mentioned __lt__ elsewhere, you should be aware of the discrepancy, otherwise you could go charging off down the wrong track. FWIW it was Terry who raised the issue 4395, I'm sure that he could explain the ramifications of it all far better than I ever could, so I'll sign out. -- Kindest regards. Mark Lawrence. -- http://mail.python.org/mailman/listinfo/python-list
Re: flatten a list of list
Chris Rebert: > The OP asked for "simple", not "best", "most proper", or "fastest". My > comment was intended to mean that the code was marginally *simpler*, > not faster. Yep, the OP has asked for simple code. But often this is not the right way to solve this situation. A better way is to create (or copy) a flatten that's efficient and well tested & debugged, put it into some library of utilities, and then use import&use it when it's needed. Bye, bearophile -- http://mail.python.org/mailman/listinfo/python-list
platform-specific overrides of functions and class methods (expanding on imputils demo code)
i've just had to put something together for pyjamas-desktop which may prove to be useful to other people, so i'm pointing people in its general direction, for archive purposes. the purpose behind the platform override system is to allow implementations of a common API, in python, to share the majority of their codebase (modules, classes, functions etc.) _but_, for _very_ specific platform implementation purposes, allow for "overrides". example: test.py def test(): print "hello" platform/testOverridingPlatformName.py: def test(): print "this is not kansas any more" code is here: http://pyjamas.svn.sourceforge.net/viewvc/pyjamas/trunk/pyjd/ modules to pay attention to: importers.py (a modified version of Demos/ imputils/importers.py) and modcompile.py. setup/init function is very simple - see __init__py.in last few lines. on reading modcompile.py you may be forgiven for going "wtf" but basically PlatformParser loads the python source; turns it into an AST; then also the "platform-specific" version is loaded and turned into an AST; then, the two ASTs are handed to the "merge" function which does a top-level "replace" of functions and a top-level "replace" of class methods. _theen_ the resultant "merged" AST is handed to a module which was derived from compiler/pycodegen.py - none of the code in there can cope with being handed an already-compiled AST so it was necessary to make a class that did. looking around on the internet i find quite a few people asking about how to do this, so ... take a look at modcompile.Module, and how it's used. very simple. i've disabled saving and detection of .pyc files for now, because the job of loading code from .pyc should really be done by PlatformParser (which understands the concept of... duh, a platform). the _last_ thing that you want to happen is to run one platform's code, generate some .pyc files, then change a config file to run a different back-end platform, for example (which is possible with pyjamas-desktop) and end up running the _wrong_ platform-specific code. for those people wondering, "why in god's green earth would anyone want to _do_ such a thing???" it's quite simple: the alternative is a complete dog's dinner, in pyjamas: def do_some_DOM_manipulation(document): # hre we go... if platform == 'hulahop' # this is for XULrunner do_some_stuff() elif platform == 'pywebkitgtk': do_something_different() elif platform == 'mshtml' # for pywin32 and comtypes do_something_dreadful() else: do_the_default_here() now imagine that across an API with ... four hundred functions. i just... couldn't bring myself to do that. not when the pyjs (python- to-javascript) compiler _already_ solved this problem (thanks to james tauber) by deploying the AST merge concept. all i did was merge that with the imputils demo code so that, rather than at compile-time the pyjs compiler goes and generates five platform-specific versions of the same application, pyjamas-desktop at _run_ time can do exactly the same thing. but - it's a generic enough idea to be of value elsewhere - for example, all the lvely code in e.g. the setup distutils? all those looovely "if os.platform == 'win32'", and "if sys.this = 'posix' " could be replaced with platform-specific overrides that got merged at run-time, thus _dramatically_ simplifying the look and the useability of the code. enjoy. l. -- http://mail.python.org/mailman/listinfo/python-list
Re: What happened to __cmp__() in Python 3.x?
On Sun, Aug 16, 2009 at 9:49 PM, Mark Lawrence wrote: > > Unfortunately I don't think it's that easy, see. > http://mail.python.org/pipermail/python-list/2008-November/688761.html > The issue referenced is still open. This of course assumes that I've > posted the correct link this time! > I'm not sure what you're referring to here. The link brought me to about __ne__ being automatically determined when __eq__ is defined. Although it is a rich comparison special method, it doesn't entirely cover the usefulness of __cmp__(). Terry: I'll give that a test tomorrow and see what I can come up with. Thanks for the quick info. Regards, Ching-Yun "Xavier" Ho, Technical Artist Contact Information Mobile: (+61) 04 3335 4748 Skype ID: SpaXe85 Email: cont...@xavierho.com Website: http://xavierho.com/ -- http://mail.python.org/mailman/listinfo/python-list
Re: What happened to __cmp__() in Python 3.x?
Chris Rebert wrote: On Sat, Aug 15, 2009 at 8:09 AM, Xavier Ho wrote: Hey all, I've recently made my way to Python 3.1 and I'm not seeing __cmp__() in the documentation. Is there a substitution for this special method in 3.1, or do I really have to define all six rich comparison methods to work it out? I don't think so. Quoting http://docs.python.org/dev/py3k/reference/datamodel.html "There are no swapped-argument versions of [the comparison] methods (to be used when the left argument does not support the operation but the right argument does); rather, __lt__() and __gt__() are each other’s reflection, __le__() and __ge__() are each other’s reflection, and __eq__() and __ne__() are their own reflection." I believe this means you only need to define one method from each of the following pairs to get all the operators working: * __eq__ or __ne__ * __lt__ or __gt__ * __ge__ or __le__ Cheers, Chris Unfortunately I don't think it's that easy, see. http://mail.python.org/pipermail/python-list/2008-November/688761.html The issue referenced is still open. This of course assumes that I've posted the correct link this time! -- Kindest regards. Mark Lawrence. -- http://mail.python.org/mailman/listinfo/python-list
Re: flatten a list of list
On Sun, Aug 16, 2009 at 7:31 AM, Steven D'Aprano wrote: > On Sun, 16 Aug 2009 06:59:52 -0400, Chris Rebert wrote: >>> Surely that's going to be O(N**2)? >> >> The OP asked for "simple", not "best", "most proper", or "fastest". My >> comment was intended to mean that the code was marginally *simpler*, not >> faster. > > Fair enough, but he also asked for Pythonic, and while some people might > argue that "terrible performance" is Pythonic, I hope you wouldn't be one > of them! :) Indeed not. :) I expected it would be worse performance-wise than the OP's original due to all the intermediate lists that get produced; it shouldn't be used in optimized production code. > If it soothes your ruffled sense of honour *wink*, I think your solution > with itertools.chain is probably the best so far. Except it's not really my solution, it's whoever put it in the itertools docs's. :( But I'm glad to been able to help by pointing the recipe out. :-) Cheers, Chris -- http://blog.rebertia.com -- http://mail.python.org/mailman/listinfo/python-list
Re: What happened to __cmp__() in Python 3.x?
Xavier Ho wrote: I'm really looking for a way to set up Python classes' natural ordering for sorting purposes. I believe __lt__ (<) is the only method (operator) used by both .sort and heap module. -- http://mail.python.org/mailman/listinfo/python-list
Re: OT Signature quote [was Re: Unrecognized escape sequences in string literals]
On Sunday 16 August 2009 12:18:11 Steven D'Aprano wrote: > In any case, after half a century of left-from-right assignment, I think > it's worth the experiment in a teaching language or three to try it the > other way. The closest to this I know of is the family of languages > derived from Apple's Hypertalk, where you do assignment with: > > put somevalue into name > > (Doesn't COBOL do something similar?) Yup. move banana to pineapple. move accountnum in inrec to accountnum in outrec. move corresponding inrec to outrec. It should all be upper case of course... I cannot quite recall, but I have the feeling that in the second form, "of" was also allowed instead of "in", but it has been a while now so I am probably wrong. The move was powerful - it would do conversions for you based on the types of the operands - it all "just worked". - Hendrik -- http://mail.python.org/mailman/listinfo/python-list
Re: flatten a list of list
On Sun, 16 Aug 2009 06:59:52 -0400, Chris Rebert wrote: >> Surely that's going to be O(N**2)? > > The OP asked for "simple", not "best", "most proper", or "fastest". My > comment was intended to mean that the code was marginally *simpler*, not > faster. Fair enough, but he also asked for Pythonic, and while some people might argue that "terrible performance" is Pythonic, I hope you wouldn't be one of them! :) If it soothes your ruffled sense of honour *wink*, I think your solution with itertools.chain is probably the best so far. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: flatten a list of list
On Sun, 16 Aug 2009 02:47:42 -0700, Terry wrote:
> Hi,
>
> Is there a simple way (the pythonic way) to flatten a list of list?
> rather than my current solution:
>
> new_list=[]
> for l in list_of_list:
> new_list.extend(l)
I don't think that scales terribly well. In my testing, it performs about
as badly as the O(N**2) behaviours others have suggested (using sum or
reduce with add) -- perhaps a bit worse for small N, but not quite as
badly for large N.
> new_list=reduce(lambda x,y:x.extend(y), list_of_list)
That doesn't even work.
>>> list_of_list = [ [1,2,3], [2, 4, 8] ]
>>> new_list=reduce(lambda x,y:x.extend(y), list_of_list)
>>> new_list is None
True
Chris' suggestion using itertools seems pretty good:
>>> from timeit import Timer
>>> setup = """\\
... L = [ [None]*5000 for _ in xrange(%d) ]
... from itertools import chain
... """
>>> Timer("list(chain.from_iterable(L))", setup % 4).repeat(number=1000)
[0.61839914321899414, 0.61799716949462891, 0.62065696716308594]
>>> Timer("list(chain.from_iterable(L))", setup % 8).repeat(number=1000)
[1.2618398666381836, 1.3385050296783447, 3.9113419055938721]
>>> Timer("list(chain.from_iterable(L))", setup % 16).repeat(number=1000)
[3.1349358558654785, 4.8554730415344238, 5.431217987061]
--
Steven
--
http://mail.python.org/mailman/listinfo/python-list
Re: flatten a list of list
On Aug 16, 6:59 pm, Chris Rebert wrote: > On Sun, Aug 16, 2009 at 6:49 AM, Steven > > > > > > D'Aprano wrote: > > On Sun, 16 Aug 2009 05:55:48 -0400, Chris Rebert wrote: > >> On Sun, Aug 16, 2009 at 5:47 AM, Terry wrote: > >>> Hi, > > >>> Is there a simple way (the pythonic way) to flatten a list of list? > >>> rather than my current solution: > > >>> new_list=[] > >>> for l in list_of_list: > >>> new_list.extend(l) > > >>> or, > > >>> new_list=reduce(lambda x,y:x.extend(y), list_of_list) > > >> #only marginally better: > >> from operator import add > >> new_list = reduce(add, list_of_list) > > > Surely that's going to be O(N**2)? > > The OP asked for "simple", not "best", "most proper", or "fastest". My > comment was intended to mean that the code was marginally *simpler*, > not faster. > > Cheers, > Chris > --http://blog.rebertia.com Well, if possible, I'd like not only to know a simple solution, but also the 'best', the 'most proper' and the 'fastest':-) If they are not the same. br, Terry -- http://mail.python.org/mailman/listinfo/python-list
Re: Problem Regarding Handling of Unicode string
On Aug 11, 1:17 pm, John Machin wrote:
> On Aug 10, 9:26 pm, joy99 wrote:
>
> > Dear Group,
>
> > I am using Python26 on WindowsXP with service pack2. My GUI is IDLE.
> > I am using Hindi resources and get nice output like:
> > एक
> > where I can use all the re functions and other functions without doing
> > any transliteration,etc.
> > I was trying to use Bengali but it is giving me output like:
>
> WHAT is giving you this output?
>
> > '\xef\xbb\xbf\xe0\xa6\x85\xe0\xa6\xa8\xe0\xa7\x87\xe0\xa6\x95'
>
> In a very ordinary IDLE session (Win XP SP3, Python 2.6.2, locale:
> Australia/English, no "Hindi resources"):
>
> >>> x = '\xef\xbb\xbf\xe0\xa6\x85\xe0\xa6\xa8\xe0\xa7\x87\xe0\xa6\x95'
> >>> ux = x.decode('utf-8')
> >>> ux
>
> u'\ufeff\u0985\u09a8\u09c7\u0995'>>> print ux
>
> অনেক # looks like what you wanted; please confirm>>> import unicodedata
> >>> for c in ux:
>
> print unicodedata.name(c)
>
> ZERO WIDTH NO-BREAK SPACE # this is a BOM
> BENGALI LETTER A
> BENGALI LETTER NA
> BENGALI VOWEL SIGN E
> BENGALI LETTER KA
>
>
>
> > I wanted to see Bengali output as
> > অনেক
> > and I like to use all functions including re.
> > If any one can help me on that.
>
> "I am using Hindi resources" doesn't tell us much ... except to prompt
> the comment that perhaps if you want to display Bengali script, you
> may need Bengali resources. However it looks like I can display your
> Bengali data without any special resources.
>
> It seems like you are not doing the same with Bengali as you are doing
> with Hindi. We can't help you very much if you don't show exactly what
> you are doing.
>
> Have you considered asking in an Indian Python forum? Note: you will
> still need to say what you are doing that works with Hindi but not
> with Bengali.
>
> Cheers,
> John
Dear Group,
I have already worked out my solution but everyone of yours' answers
helped me to see different solutions from different angles. Thank you
for the same. I am building some social network program in Bengali. I
just gave the transliteration problem which was giving me problem, I
thought as you are very expert pythoners so it would be minutes'
matter. By your answers I saw I was not wrong. But as I solved the
problem so I checked it bit late. Sorry for the same.
Best Regards,
Subhabrata.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Is it possible to use python to get True Full Duplex on a Serial port? - conclusions
On Sunday 16 August 2009 08:20:34 John Nagle wrote: > Hendrik van Rooyen wrote: > > On Saturday 15 August 2009 14:40:35 Michael Ströder wrote: > >> Hendrik van Rooyen wrote: > >>> In the past, on this group, I have made statements that said that on > >>> Linux, the serial port handling somehow does not allow transmitting and > >>> receiving at the same time, and nobody contradicted me. > > Absolutely false. No its true, if you open the serial port with the standard open() instead of os.open(). And it is also true that I was not contradicted in the past. :-) > > >> Despite all the good comments here by other skilled people I'd recommend > >> to determine whether the transmission line to the devices accessed > >> support full duplex. > > All standard PC serial ports are full-duplex devices. > I know this, and I started the thread because they would not work full duplex for me. 8< pyserial baudot program link --- > > You raise a good point, that is probably not well known amongst the > > youngsters here, as simple serial multidropping has gone out of fashion. > > Actually, no. Dynamixel servos as used on the latest Bioloid robots > are multidrop serial RS-485. But outside the embedded world, nobody uses > that stuff any more. (Embedded is going Ethernet; it's overkill but > works fine and is now cheap.) Exactly - it is no longer part of mainstream fashion. We also still use RS-485 because it is cheaper, and we have better control over timing. I enclose two naive test implementations. To run them you will need a loopback connector. One can be made by shorting pin 2 and 3 together on the standard DB9. The results are illuminating - on my development machine, (dual 64 bit, some gigs), the last lines look like this: test.py: The quick brown fox jumps over the lazy dog 1023 That took 3.91238284111 seconds - 3.82068636827 Millisecs per record, 261.733077152 recs per sec h...@linuxbox:~/dos/JOBS/sms/lib> test1.py: The quick brown fox jumps over the lazy dog 1023 That took 3.90402388573 seconds - 3.81252332591 Millisecs per record, 262.293477185 recs per sec h...@linuxbox:~/dos/JOBS/sms/lib> Almost no difference between the two implementations. This is basically because there is enough processing power to keep the link running at full speed in both instances. On the eBox, (486, 400MHz, 128Mb, no FP), the difference is startling: test.py: The quick brown fox jumps over the lazy dog 1023 That took 69.2863521576 seconds - 67.6624532789 Millisecs per record, 14.7792453797 recs per sec r...@ebox:/home/user/sms/lib# About eighteen times slower than the development machine. test1.py: The quick brown fox jumps over the lazy dog 1023 That took 10.391780138 seconds - 10.148222791 Millisecs per record, 98.5394211964 recs per sec r...@ebox:/home/user/sms/lib# Less than three times slower than the development machine. The little processor + Slackware + python cannot keep the link busy. Python, as a character handler, well let us say that it is suboptimal, because saying that something sucks, sucks. An almost seven times ratio between the implementations is not to be sneezed at. So the conclusions I have come to are the following: 1) Thou shalt not use ordinary python files for serial ports, on pain of death. 2) Thou shalt strive mightily to minimize python calls, doing all in thy power to move away from character input to string input. 3) Thou shalt expend real treasure for real processing power as there is no such thing as a free lunch. I would like to thank everybody who took the trouble to respond to teach me the error of my ways. - Hendrik test1.py Description: application/python test.py Description: application/python -- http://mail.python.org/mailman/listinfo/python-list
Re: flatten a list of list
On Sun, 16 Aug 2009 12:03:53 +0200, Michael Fötsch wrote:
> Terry wrote:
>> Is there a simple way (the pythonic way) to flatten a list of list?
>
> This is probably the shortest it can get:
>
> sum(list_of_lists, [])
That's also O(N**2).
>>> from timeit import Timer
>>> setup = "L = [ ([None]*5000) for x in xrange(%d) ]"
>>> Timer("sum(L, [])", setup % 4).repeat(number=1000)
[0.6070549488067627, 0.54354715347290039, 0.54686999320983887]
>>> Timer("sum(L, [])", setup % 8).repeat(number=1000)
[2.1285719871520996, 3.6722278594970703, 4.0785009860992432]
>>> Timer("sum(L, [])", setup % 16).repeat(number=1000)
[18.370341062545776, 20.40509295463562, 21.871708869934082]
--
Steven
--
http://mail.python.org/mailman/listinfo/python-list
Re: flatten a list of list
On Sun, Aug 16, 2009 at 6:49 AM, Steven D'Aprano wrote: > On Sun, 16 Aug 2009 05:55:48 -0400, Chris Rebert wrote: >> On Sun, Aug 16, 2009 at 5:47 AM, Terry wrote: >>> Hi, >>> >>> Is there a simple way (the pythonic way) to flatten a list of list? >>> rather than my current solution: >>> >>> new_list=[] >>> for l in list_of_list: >>> new_list.extend(l) >>> >>> or, >>> >>> new_list=reduce(lambda x,y:x.extend(y), list_of_list) >> >> #only marginally better: >> from operator import add >> new_list = reduce(add, list_of_list) > > Surely that's going to be O(N**2)? The OP asked for "simple", not "best", "most proper", or "fastest". My comment was intended to mean that the code was marginally *simpler*, not faster. Cheers, Chris -- http://blog.rebertia.com -- http://mail.python.org/mailman/listinfo/python-list
Re: flatten a list of list
On Sun, 16 Aug 2009 05:55:48 -0400, Chris Rebert wrote:
> On Sun, Aug 16, 2009 at 5:47 AM, Terry wrote:
>> Hi,
>>
>> Is there a simple way (the pythonic way) to flatten a list of list?
>> rather than my current solution:
>>
>> new_list=[]
>> for l in list_of_list:
>> new_list.extend(l)
>>
>> or,
>>
>> new_list=reduce(lambda x,y:x.extend(y), list_of_list)
>
> #only marginally better:
> from operator import add
> new_list = reduce(add, list_of_list)
Surely that's going to be O(N**2)?
I'd predict that would perform even worse than O(N**2) string
concatenation, on account that a string of size N has to allocate space
for N bytes, but a list of size N allocates space for N pointers (each 4
bytes, or 8 depending on the system), rounded up to the nearest power of
two. Also CPython can optimize string concatenation to O(N) under some
circumstances, but not lists.
>>> from timeit import Timer
>>> setup = """\\
... L = [ ([None]*5000) for x in xrange(%d) ]
... from operator import add
... """
>>> Timer("reduce(add, L)", setup % 4).repeat(number=1000)
[0.53808808326721191, 0.51404905319213867, 0.51157188415527344]
>>> Timer("reduce(add, L)", setup % 8).repeat(number=1000)
[2.1178171634674072, 3.8830602169036865, 4.72245192527771]
>>> Timer("reduce(add, L)", setup % 16).repeat(number=1000)
[17.190337896347046, 21.572744131088257, 21.584265947341919]
Looks like O(N**2) behaviour to me.
--
Steven
--
http://mail.python.org/mailman/listinfo/python-list
Re: How to find out in which module an instance of a class is created?
Chris Rebert schrieb: On Sun, Aug 16, 2009 at 6:25 AM, Johannes Janssen wrote: Gabriel Genellina schrieb: The try/except around sys._getframe(1) is because that function is not mandatory/available on all Python implementations (that's the case for jython which doesn't provide it). Thanks, shouldn't such information be part of the python documentation of sys._getframe() (http://docs.python.org/library/sys.html?highlight=sys._getframe#sys._getframe)? The leading underscore kinda indirectly implies it, but yeah, it's worth mentioning. File a bug in the docs: http://bugs.python.org/ Cheers, Chris I filed a bug: http://bugs.python.org/issue6712 . Johannes -- http://mail.python.org/mailman/listinfo/python-list
Re: How to find out in which module an instance of a class is created?
On Sun, Aug 16, 2009 at 6:25 AM, Johannes Janssen wrote: > Gabriel Genellina schrieb: >> >> The try/except around sys._getframe(1) is because that function is not >> mandatory/available on all Python implementations (that's the case for >> jython which doesn't provide it). > > Thanks, shouldn't such information be part of the python documentation of > sys._getframe() > (http://docs.python.org/library/sys.html?highlight=sys._getframe#sys._getframe)? The leading underscore kinda indirectly implies it, but yeah, it's worth mentioning. File a bug in the docs: http://bugs.python.org/ Cheers, Chris -- http://blog.rebertia.com -- http://mail.python.org/mailman/listinfo/python-list
Re: How to find out in which module an instance of a class is created?
Gabriel Genellina schrieb: The try/except around sys._getframe(1) is because that function is not mandatory/available on all Python implementations (that's the case for jython which doesn't provide it). Thanks, shouldn't such information be part of the python documentation of sys._getframe() (http://docs.python.org/library/sys.html?highlight=sys._getframe#sys._getframe)? Johannes -- http://mail.python.org/mailman/listinfo/python-list
wxFormBuilder finally supports wxPython
Version 3.1 of wxFormBuilder can generate wxPython code. I have previously used wxFormBuilder to generate XRC files for my wxPython projects. Though still in beta, this might be even better. :-) http://wxformbuilder.org/ -- http://mail.python.org/mailman/listinfo/python-list
Re: OT Signature quote [was Re: Unrecognized escape sequences in string literals]
On Sun, 16 Aug 2009 01:41:41 -0700, Douglas Alan wrote: > I like to be able to read everything from left to right, and Lisp does > that more than any other programming language. > > I would definitely not like a language that obscures assignment by > moving it over to the right side of lines. One could argue that left-assigned-from-right assignment obscures the most important part of the assignment, namely *what* you're assigning, in favour of what you're assigning *to*. In any case, after half a century of left-from-right assignment, I think it's worth the experiment in a teaching language or three to try it the other way. The closest to this I know of is the family of languages derived from Apple's Hypertalk, where you do assignment with: put somevalue into name (Doesn't COBOL do something similar?) Beginners found that *very* easy to understand, and it didn't seem to make coding harder for experienced Hypercard developers. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: flatten a list of list
Terry wrote: Is there a simple way (the pythonic way) to flatten a list of list? This is probably the shortest it can get: sum(list_of_lists, []) Kind Regards, M.F. -- http://mail.python.org/mailman/listinfo/python-list
Re: flatten a list of list
On Sun, Aug 16, 2009 at 5:47 AM, Terry wrote: > Hi, > > Is there a simple way (the pythonic way) to flatten a list of list? > rather than my current solution: > > new_list=[] > for l in list_of_list: > new_list.extend(l) > > or, > > new_list=reduce(lambda x,y:x.extend(y), list_of_list) #only marginally better: from operator import add new_list = reduce(add, list_of_list) #from the itertools recipes: from itertools import chain def flatten(listOfLists): return list(chain.from_iterable(listOfLists)) Cheers, Chris -- http://blog.rebertia.com -- http://mail.python.org/mailman/listinfo/python-list
Re: Splitting a string into substrings of equal size
Mark Tolonen schrieb:
"Gregor Lingl" wrote in message
news:4a87036a$0$2292$91cee...@newsreader02.highway.telekom.at...
Emile van Sebille schrieb:
On 8/14/2009 5:22 PM candide said...
...
What is the pythonic way to do this ?
I like list comps...
>>> jj = '1234567890123456789'
>>> ",".join([jj[ii:ii+3] for ii in range(0,len(jj),3)])
'123,456,789,012,345,678,9'
>>>
Emile
Less beautiful but more correct:
>>> ",".join([jj[max(ii-3,0):ii] for ii in
range(len(jj)%3,len(jj)+3,3)])
'1,234,567,890,123,456,789'
Gregor
Is it?
jj = '234567890123456789'
",".join([jj[max(ii-3,0):ii] for ii in range(len(jj)%3,len(jj)+3,3)])
',234,567,890,123,456,789'
Schluck!
Even more ugly:
",".join([jj[max(ii-3,0):ii] for ii in
range(len(jj)%3,len(jj)+3,3)]).strip(",")
'234,567,890,123,456,789'
Gregor
At least one other solution in this thread had the same problem.
-Mark
--
http://mail.python.org/mailman/listinfo/python-list
flatten a list of list
Hi, Is there a simple way (the pythonic way) to flatten a list of list? rather than my current solution: new_list=[] for l in list_of_list: new_list.extend(l) or, new_list=reduce(lambda x,y:x.extend(y), list_of_list) br, Terry -- http://mail.python.org/mailman/listinfo/python-list
Re: What happened to __cmp__() in Python 3.x?
On Sun, Aug 16, 2009 at 7:38 PM, Mark Lawrence wrote: > > Blast, I posted the wrong flaming link, sorry everybody. > No, don't be sorry. I found your link very informative, and while it's a little mixed, it could be useful. I'm really looking for a way to set up Python classes' natural ordering for sorting purposes. For example, every object of a class could own an attribute called 'Value'. If I could get Python to sort() a list of classes with that value, would the key=value parameter work, and is there a better way than to redefine 3 or more of the rich comparison special methods, etc. Also, I noticed heapq (the priority queue/heap queue module) doesn't use the natural sorting order like sorted() does. Just saying. Could someone give it a try? Regards, Ching-Yun "Xavier" Ho, Technical Artist Contact Information Mobile: (+61) 04 3335 4748 Skype ID: SpaXe85 Email: cont...@xavierho.com Website: http://xavierho.com/ -- http://mail.python.org/mailman/listinfo/python-list
Re: ignored test cases in unittest
On Aug 16, 5:25 pm, Duncan Booth wrote:
> Ben Finney wrote:
> > Terry writes:
>
> >> It seemed the to me that python unittest module does not support the
> >> counting of ignored test cases directly. Is there any ready solution
> >> for this?
>
> > One solution I've seen involves:
>
> > * a custom exception class, ‘TestSkipped’
>
> > * raising that exception at the top of test cases you want to
> > temporarily skip
>
> > * a custom ‘TestResult’ class that knows about a “skipped” result
>
> > * a custom reporter class that knows how you want to report that result
>
> I'd add to that a decorator so you can quickly mark a test case as ignored
> without editing the test itself. Also you could include a reason why it is
> ignored:
>
> �...@ignore("This test takes too long to run")
> def test_foo(self):
> ...
>
> That also means you can redefine the decorator easily if you want to try
> running all the ignored tests.
>
> Another decorator useful here is one that asserts that the test will fail.
> If the test passes then maybe someone fixed whatever was making it fail and
> if so you want to consider re-enabling it.
>
> �...@fails("Needs the frobnozz module to be updated")
> def test_whotsit(self):
> ...
Thanks for the solutions. I think the decorator idea is what I'm look
for:-)
--
http://mail.python.org/mailman/listinfo/python-list
Re: What happened to __cmp__() in Python 3.x?
Chris Rebert wrote: On Sat, Aug 15, 2009 at 1:06 PM, Mark Lawrence wrote: Xavier Ho wrote: Hey all, I've recently made my way to Python 3.1 and I'm not seeing __cmp__() in the documentation. Is there a substitution for this special method in 3.1, or do I really have to define all six rich comparison methods to work it out? If this question has already been asked somewhere, I apologise in advance. Already googled around but I didn't find information on this. Any replies appreciated. http://bytes.com/topic/python/answers/844614-python-3-sorting-comparison-function That seems to be about the built-in function cmp(). The OP was asking about the special method __cmp__ and the related rich comparison special methods (__eq__, __lt__, etc). Cheers, Chris Blast, I posted the wrong flaming link, sorry everybody. -- Kindest regards. Mark Lawrence. -- http://mail.python.org/mailman/listinfo/python-list
Re: OT Signature quote [was Re: Unrecognized escape sequences in string literals]
On Aug 16, 4:48 am, Erik Max Francis wrote: > Douglas Alan wrote: > > Personally, my favorite is Lisp, which looks like > > > (set! y (+ y 1)) > > For varying values of "Lisp." `set!` is Scheme. Yes, I'm well aware! There are probably as many different dialects of Lisp as all other programming languages put together. |>ouglas -- http://mail.python.org/mailman/listinfo/python-list
Re: ignored test cases in unittest
Ben Finney wrote:
> Terry writes:
>
>> It seemed the to me that python unittest module does not support the
>> counting of ignored test cases directly. Is there any ready solution
>> for this?
>
> One solution I've seen involves:
>
> * a custom exception class, âTestSkippedâ
>
> * raising that exception at the top of test cases you want to
> temporarily skip
>
> * a custom âTestResultâ class that knows about a âskippedâ result
>
> * a custom reporter class that knows how you want to report that result
>
I'd add to that a decorator so you can quickly mark a test case as ignored
without editing the test itself. Also you could include a reason why it is
ignored:
@ignore("This test takes too long to run")
def test_foo(self):
...
That also means you can redefine the decorator easily if you want to try
running all the ignored tests.
Another decorator useful here is one that asserts that the test will fail.
If the test passes then maybe someone fixed whatever was making it fail and
if so you want to consider re-enabling it.
@fails("Needs the frobnozz module to be updated")
def test_whotsit(self):
...
--
http://mail.python.org/mailman/listinfo/python-list
Re: OT Signature quote [was Re: Unrecognized escape sequences in string literals]
Douglas Alan wrote: Personally, my favorite is Lisp, which looks like (set! y (+ y 1)) For varying values of "Lisp." `set!` is Scheme. -- Erik Max Francis && m...@alcyone.com && http://www.alcyone.com/max/ San Jose, CA, USA && 37 18 N 121 57 W && AIM/Y!M/Skype erikmaxfrancis Get there first with the most men. -- Gen. Nathan Bedford Forrest, 1821-1877 -- http://mail.python.org/mailman/listinfo/python-list
