tox-1.3: virtualenv-based test run automizer
tox 1.3: the virtualenv-based test run automatizer === I am happy to announce tox 1.3, containing a few improvements over 1.2. TOX automates tedious test activities driven from a simple ``tox.ini`` file, including: * creation and management of different virtualenv environments with different Python interpreters * packaging and installing your package into each of them * running your test tool of choice, be it nose, py.test or unittest2 or other tools such as sphinx doc checks * testing dev packages against each other without needing to upload to PyPI Docs and examples are at: http://tox.testrun.org/ Installation: pip install -U tox code hosting and issue tracking on bitbucket: http://bitbucket.org/hpk42/tox best, Holger Krekel 1.3 - - fix: allow to specify wildcard filesystem paths when specifiying dependencies such that tox searches for the highest version - fix issue21: clear PIP_REQUIRES_VIRTUALENV which avoids pip installing to the wrong environment, thanks to bb's streeter - make the install step honour a testenv's setenv setting (thanks Ralf Schmitt) -- http://mail.python.org/mailman/listinfo/python-announce-list Support the Python Software Foundation: http://www.python.org/psf/donations/
Elementwise -//- first release -//- Element-wise (vectorized) function, method and operator support for iterables in python.
Elementwise provides a proxy object for iterables which supports chained method calls, as well as elementwise expressions and some built-in functions. Example: class ExampleList(ElementwiseProxyMixin, list): def __new__(cls, iterable): return list.__new__(cls, iterable) foo = ExampleList([1, 2, 3, 4]) # You could also do: efoo = ElementwiseProxy(foo) efoo = foo.each assert list(efoo.bit_length()) == [1, 2, 2, 3] print bit length: , list(efoo.bit_length()) assert list(efoo + 1) == [2, 3, 4, 5] print with addition of 1: , list(efoo + 1) assert list(efoo * 2) == [2, 4, 6, 8] print with multiplication by 2: , list(efoo * 2) assert list(efoo == 2) == [False, True, False, False] print testing equality: , efoo == 2 assert list((efoo + 1) * 2 + 3) == [7, 9, 11, 13] print chaining addition and multiplication: , (efoo + 1) * 2 + 3 Each ElementwiseProxy also has a parent attribute so you can backtrack in the chain as needed rather than store each intermediate value, if you think you might need them. There are still some issues with proper support of things like bool() and int(), which refuse to return things that are not of the correct type. Get it: PyPi: http://pypi.python.org/pypi/elementwise/0.111220 GitHub: https://github.com/nathan-rice/Elementwise This was developed as a proof of concept for expanding the role of element-wise syntax in python, and to that end I welcome comments. Nathan Rice -- http://mail.python.org/mailman/listinfo/python-announce-list Support the Python Software Foundation: http://www.python.org/psf/donations/
Cornice 0.6
Hey, We've released Cornice 0.6 Cornice provides helpers to build document REST-ish Web Services with Pyramid. This version has: - multiple bug fixes - a Paster template to quickly start a new Cornice project - a tutorial a full new example in examples/ You can try out the tutorial at http://packages.python.org/cornice/tutorial.html The main benefits of Cornice are: - automatic handling of some HTTP errors - Ask yourself: is your app handling properly 405 or 406 errors? - automatic web service documentation via a Sphinx extension. - a simple way to validate and convert requests data, and return structured 400 responses. Check it out : - Documentation - http://packages.python.org/cornice - PyPI - http://pypi.python.org/pypi/cornice - Repository - https://github.com/mozilla-services/cornice We'd love feedback new contributors ! Cheers Tarek -- Tarek Ziadé | http://ziade.org -- http://mail.python.org/mailman/listinfo/python-announce-list Support the Python Software Foundation: http://www.python.org/psf/donations/
Anyone still using Python 2.5?
Hi All, What's the general consensus on supporting Python 2.5 nowadays? Do people still have to use this in commercial environments or is everyone on 2.6+ nowadays? I'm finally getting some continuous integration set up for my packages and it's highlighting some 2.5 compatibility issues. I'm wondering whether to fix those (lots of ugly from __future__ import with_statement everywhere) or just to drop Python 2.5 support. What do people feel? cheers, Chris -- Simplistix - Content Management, Batch Processing Python Consulting - http://www.simplistix.co.uk -- http://mail.python.org/mailman/listinfo/python-list
Re: Anyone still using Python 2.5?
Chris Withers, 21.12.2011 08:15: What's the general consensus on supporting Python 2.5 nowadays? From my own (recent) polls, it appears that people want continued support for Python 2.4 and later for a couple of years to come, mainly because RHEL5 uses that by default and has official support until 2014. Similar considerations apply to many Solaris installations. The general consensus seems to be that support for Python 2.3 can easily be dropped, but that support for Py2.4 and later would be helpful. Stefan -- http://mail.python.org/mailman/listinfo/python-list
Can I get use pexpect to control this process?
I have a program X that constantly spews output, hundreds of lines per minute. X is not an interactive program. IE: it doesn't take any user input. It just produces a lot of textual output to STDOUT. I would like to save the output produced by X into a different file every 5 seconds regardless of the actual content. I want one file to contain the output from seconds 0-5, another file should contain 6-10, etc. etc. Can I do this with pexpect? I'm not sure I can because the before argument gives me EVERYTHING upto the most recent match. What I really need is something that will give me what was produced between the last 2 calls to pexpect.expect(). -- http://mail.python.org/mailman/listinfo/python-list
Re: [TIP] Anyone still using Python 2.5?
On Wed, Dec 21, 2011 at 07:15:46AM +, Chris Withers wrote: Hi All, What's the general consensus on supporting Python 2.5 nowadays? Do people still have to use this in commercial environments or is everyone on 2.6+ nowadays? I'm finally getting some continuous integration set up for my packages and it's highlighting some 2.5 compatibility issues. I'm wondering whether to fix those (lots of ugly from __future__ import with_statement everywhere) or just to drop Python 2.5 support. What do people feel? Most linux distribution went directly from 2.4 to 2.5 Debian: old stable (lenny) 2.4 stable (squeeze)2.5 Red Hat REHL5 2.4 REHL6 2.6 The most notable exception is Ubuntu Hardy and LTS release from april 2008 with 2.5. But this LTS is out of support for almost 1 year now and current LTS (Lucid) ship 2.6. If you don't plan to support 2.4, supporting 2.5 does not seems a priority. -- Pierre-Yves David http://www.logilab.fr/ signature.asc Description: Digital signature -- http://mail.python.org/mailman/listinfo/python-list
Re: Learning Python 2.4
On 21/12/11 02:13, Ashton Fagg wrote: I got the impression the OP was learning programming in general (i.e. from scratch) and not merely learning Python. If this is the case it shouldn't matter if they're merely learning the concepts as you can always get up to speed on the differences later on as they get more experienced. In which case the most important thing is the quality of the book as a text on Programming. If you find the the author's style to your taste, then use that book rather than struggle with a text based on a recent version that you personally find unreadable. -- http://mail.python.org/mailman/listinfo/python-list
RE: [TIP] Anyone still using Python 2.5?
We've a bunch of windows servers stuck on python 2.5 since an API we use on them is shipped to us pyc's only - forcing us to stay with that version. Most of our other machines are on 2.6 or 2.7. -Original Message- From: testing-in-python-boun...@lists.idyll.org [mailto:testing-in-python-boun...@lists.idyll.org] On Behalf Of Chris Withers Sent: 21 December 2011 07:16 To: Python List; testing-in-pyt...@lists.idyll.org; simplis...@googlegroups.com Subject: [TIP] Anyone still using Python 2.5? Hi All, What's the general consensus on supporting Python 2.5 nowadays? Do people still have to use this in commercial environments or is everyone on 2.6+ nowadays? I'm finally getting some continuous integration set up for my packages and it's highlighting some 2.5 compatibility issues. I'm wondering whether to fix those (lots of ugly from __future__ import with_statement everywhere) or just to drop Python 2.5 support. What do people feel? cheers, Chris -- Simplistix - Content Management, Batch Processing Python Consulting - http://www.simplistix.co.uk ___ testing-in-python mailing list testing-in-pyt...@lists.idyll.org http://lists.idyll.org/listinfo/testing-in-python ** This message is confidential and intended only for the addressee. If you have received this message in error, please immediately notify the postmas...@nds.com and delete it from your system as well as any copies. The content of e-mails as well as traffic data may be monitored by NDS for employment and security purposes. To protect the environment please do not print this e-mail unless necessary. NDS Limited. Registered Office: One London Road, Staines, Middlesex, TW18 4EX, United Kingdom. A company registered in England and Wales. Registered no. 3080780. VAT no. GB 603 8808 40-00 ** -- http://mail.python.org/mailman/listinfo/python-list
Re: Anyone still using Python 2.5?
On Wed, 21 Dec 2011 07:15:46 +, Chris Withers wrote: Hi All, What's the general consensus on supporting Python 2.5 nowadays? Do people still have to use this in commercial environments or is everyone on 2.6+ nowadays? Centos and Red Hat production systems still use Python 2.4, so yes, absolutely, 2.5 and 2.4 still need to be supported. Not necessarily by package authors though -- that's a matter for them to decide. I'm presently writing a small library which will support 2.4 through 3.2, which isn't as hard as it sounds like, but still isn't exactly fun. If the project were much bigger, I'd drop support for 2.4 and only support 2.5. At least then I could use conditional expressions and __future__ imports. I'm finally getting some continuous integration set up for my packages and it's highlighting some 2.5 compatibility issues. I'm wondering whether to fix those (lots of ugly from __future__ import with_statement everywhere) or just to drop Python 2.5 support. What do people feel? It really depends on *your* users, not arbitrary developers. How many of your users are using 2.5? -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: [TIP] Anyone still using Python 2.5?
On Wed, Dec 21, 2011 at 9:21 AM, Pierre-Yves David pierre-yves.da...@logilab.fr wrote: ... The most notable exception is Ubuntu Hardy and LTS release from april 2008 with 2.5. But this LTS is out of support for almost 1 year now and current LTS (Lucid) ship 2.6. Not quite. Ubuntu 8.04 LTS is supported on the server until April 2013. jml -- http://mail.python.org/mailman/listinfo/python-list
Re: [TIP] Anyone still using Python 2.5?
On Wed, Dec 21, 2011 at 2:15 AM, Chris Withers ch...@simplistix.co.uk wrote: Hi All, What's the general consensus on supporting Python 2.5 nowadays? Do people still have to use this in commercial environments or is everyone on 2.6+ nowadays? I'm finally getting some continuous integration set up for my packages and it's highlighting some 2.5 compatibility issues. I'm wondering whether to fix those (lots of ugly from __future__ import with_statement everywhere) or just to drop Python 2.5 support. What do people feel? Google app engine is still Python 2.5, as is Jython. Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton -- http://mail.python.org/mailman/listinfo/python-list
Re: Anyone still using Python 2.5?
Em quarta-feira, 21 de dezembro de 2011 08:50:34, Steven D'Aprano escreveu: On Wed, 21 Dec 2011 07:15:46 +, Chris Withers wrote: Hi All, What's the general consensus on supporting Python 2.5 nowadays? Do people still have to use this in commercial environments or is everyone on 2.6+ nowadays? Centos and Red Hat production systems still use Python 2.4, so yes, absolutely, 2.5 and 2.4 still need to be supported. Not necessarily by package authors though -- that's a matter for them to decide. I'm presently writing a small library which will support 2.4 through 3.2, which isn't as hard as it sounds like, but still isn't exactly fun. If the project were much bigger, I'd drop support for 2.4 and only support 2.5. At least then I could use conditional expressions and __future__ imports. I'm finally getting some continuous integration set up for my packages and it's highlighting some 2.5 compatibility issues. I'm wondering whether to fix those (lots of ugly from __future__ import with_statement everywhere) or just to drop Python 2.5 support. What do people feel? It really depends on *your* users, not arbitrary developers. How many of your users are using 2.5? There are still people on 2.5. ESRIs customers (www.esri.com) that rely heavily on Python 2.5, because it ships with a popular ArcGIS release (9.31). The new ArcGIS release uses 2.6, but I can see 9.31 lurking around for another year, at least. Cheers. -- http://mail.python.org/mailman/listinfo/python-list
Why widgets become 'NoneType'?
Hi Folks,
I was driven nuts by this thing: widgets lost their attributes, then I
can't configure them. Please take a look at the codes below:
from Tkinter import *
canvas = Canvas(width=300, height=400, bg='white')
canvas.pack(expand=NO, fill=BOTH)
pic = PhotoImage(file=img)
canvas.create_image(0, 0, image=pic)
al = PhotoImage(file='a.gif')
lbl = Label(canvas, text=x, fg='red').pack(side=LEFT)
canvas.create_text(40,20, text='Howdy')
the last line of code got error message, says canvas object has no
attribute of config. The same problem happened again, the code is
below:
def make_labels(win, astr):
labels = []
for i in range(len(astr)):
lbl = Label(win, text=astr[i]).pack(side=LEFT )
labels.append(lbl)
return tuple(labels)
def config_labels(atuple, func):
for lbl in atuple:
lbl.config('%s') % func
root = Tk()
lbls = make_labels(root, 'foobar')
config_labels(lbls, fg='red')
The config for Label was picked up: No attributes of config. I tried
to print type(lbls), and found Python interpreter reported as
'NoneType'. I also tried to print out dir(lbls), fount there was no
attributes I familiar with such as config and such. What is wrong with
them? Both of the codes above WORKED, since I saw my widgets displayed
them as I wanted, but I just can't configure them as I usually did.
Can somebody help me out? I never experience such a weird thing.
Thanks!
Cosmo
--
http://mail.python.org/mailman/listinfo/python-list
Re: Anyone still using Python 2.5?
In article 4ef1b9fa$0$29973$c3e8da3$54964...@news.astraweb.com, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: Centos and Red Hat production systems still use Python 2.4, so yes, absolutely, 2.5 and 2.4 still need to be supported. Is Python 2.4 destined to be the next IE-6? -- http://mail.python.org/mailman/listinfo/python-list
Re: Why widgets become 'NoneType'?
On 12/21/2011 07:59 AM, Muddy Coder wrote:
Hi Folks,
I was driven nuts by this thing: widgets lost their attributes, then I
can't configure them. Please take a look at the codes below:
from Tkinter import *
canvas = Canvas(width=300, height=400, bg='white')
canvas.pack(expand=NO, fill=BOTH)
pic = PhotoImage(file=img)
canvas.create_image(0, 0, image=pic)
al = PhotoImage(file='a.gif')
lbl = Label(canvas, text=x, fg='red').pack(side=LEFT)
canvas.create_text(40,20, text='Howdy')
the last line of code got error message, says canvas object has no
attribute of config. The same problem happened again, the code is
below:
def make_labels(win, astr):
labels = []
for i in range(len(astr)):
lbl = Label(win, text=astr[i]).pack(side=LEFT )
labels.append(lbl)
return tuple(labels)
def config_labels(atuple, func):
for lbl in atuple:
lbl.config('%s') % func
root = Tk()
lbls = make_labels(root, 'foobar')
config_labels(lbls, fg='red')
The config for Label was picked up: No attributes of config. I tried
to print type(lbls), and found Python interpreter reported as
'NoneType'. I also tried to print out dir(lbls), fount there was no
attributes I familiar with such as config and such. What is wrong with
them? Both of the codes above WORKED, since I saw my widgets displayed
them as I wanted, but I just can't configure them as I usually did.
Can somebody help me out? I never experience such a weird thing.
Thanks!
Cosmo
When posting error messages, post it exactly and completely; do not
paraphrase.
--
DaveA
--
http://mail.python.org/mailman/listinfo/python-list
Re: [TIP] Anyone still using Python 2.5?
On Dec 21, 2011, at 2:15 AM, Chris Withers ch...@simplistix.co.uk wrote: Hi All, What's the general consensus on supporting Python 2.5 nowadays? Do people still have to use this in commercial environments or is everyone on 2.6+ nowadays? For those of us living the nightmare of AppEngine *and* working on an app old enough to not be using the newer Datastore, we're stuck on 2.5 until we can justify a data migration. Frankly I don't know how many such apps exist these days that are still actively developed, though. I'm finally getting some continuous integration set up for my packages and it's highlighting some 2.5 compatibility issues. I'm wondering whether to fix those (lots of ugly from __future__ import with_statement everywhere) or just to drop Python 2.5 support. What do people feel? cheers, Chris -- Simplistix - Content Management, Batch Processing Python Consulting - http://www.simplistix.co.uk ___ testing-in-python mailing list testing-in-pyt...@lists.idyll.org http://lists.idyll.org/listinfo/testing-in-python -- http://mail.python.org/mailman/listinfo/python-list
Re: Learning Python 2.4
On 12/20/11 7:31 PM, Rick Johnson wrote: Anything before Python 3.0 is now obsolete. We are currently at 3.2.2 for a stable release. 2.7 is still a supported production release of Python. It has not been end-of-lifed. -- Kevin Walzer Code by Kevin http://www.codebykevin.com -- http://mail.python.org/mailman/listinfo/python-list
Re: [TIP] Anyone still using Python 2.5?
In article mailman.3913.1324474710.27778.python-l...@python.org, Tom Davis t...@recursivedream.com wrote: For those of us living the nightmare of AppEngine I've never used AppEngine, just read a little about it. Could you explain why it's a nightmare? -- http://mail.python.org/mailman/listinfo/python-list
Re: [OT] Quick intro to C++ for a Python and C user?
On 2011-12-20, Paul Rubin no.email@nospam.invalid wrote: Grant Edwards invalid@invalid.invalid writes: Oops. I should have mentioned this is for embedded systems programming so templates in general (and STL in particular) are probably off the table. Templates are how C++ does generics and I'd expect them to appear in be used in embedded programming as well as elsewhere. They can bloat up the code if you're not careful (if function f has several parameters, you can end up with a separate, specialized copy of f for every combination of types that f is called with in the program), but in the typical monomorphic situation they don't add any overhead. I'm not sure about the situation with STL. Anyway, templates aren't terribly hard to understand. Moreover, if you don't plan to take advantage of templates or inheritance, then you could as well write C++ compatible C and be pretty happy with the results. -- Neil Cerutti -- http://mail.python.org/mailman/listinfo/python-list
Re: [OT] Quick intro to C++ for a Python and C user?
In article 9le7c5f1l...@mid.individual.net, Neil Cerutti ne...@norwich.edu wrote: On 2011-12-20, Paul Rubin no.email@nospam.invalid wrote: Grant Edwards invalid@invalid.invalid writes: Oops. I should have mentioned this is for embedded systems programming so templates in general (and STL in particular) are probably off the table. Templates are how C++ does generics and I'd expect them to appear in be used in embedded programming as well as elsewhere. They can bloat up the code if you're not careful (if function f has several parameters, you can end up with a separate, specialized copy of f for every combination of types that f is called with in the program), but in the typical monomorphic situation they don't add any overhead. I'm not sure about the situation with STL. Anyway, templates aren't terribly hard to understand. Moreover, if you don't plan to take advantage of templates or inheritance, then you could as well write C++ compatible C and be pretty happy with the results. Well, C++ still gives you constructors, destructors, and the ability to write class-specific operators. But, you'd be missing one of C++'s biggest selling points; safe containers. Even if you never explore anything in STL beyond std:string and std:vector, you will have saved yourself a world of buffer overflow pain. -- http://mail.python.org/mailman/listinfo/python-list
Re: Elementwise -//- first release -//- Element-wise (vectorized) function, method and operator support for iterables in python.
On Tue, Dec 20, 2011 at 8:37 PM, Joshua Landau joshua.landau...@gmail.com wrote: On 21 December 2011 00:24, Nathan Rice nathan.alexander.r...@gmail.com wrote: efoo_res = ((efoo2.capitalize() + little indian).split( ).apply(reversed) * 2).apply(_.join) # note that you could do reversed(...) instead, I just like to read left to right efoo_res.parent.parent.parent # same as ((efoo2.capitalize() + little indian).split( ) in case you need to debug something and want to look at intermediate values How is any of this better than the elementwise operators (~)? People should be able to expect len(x) to always return a number or raise an error. I know it's not part of the spec, but a lot breaks without these guarantees. When str(x) isn't a string, all the formatting code breaks*. And when the other suggestion (~str(x) or str~(x) or something similar) has all the benifits and none of the drawbacks, why should I use this? len() will always return a number or raise an error, just like the type functions (bool/int/etc) return that type or raise an error. The interpreter guarantees that for you. This has a couple of advantages over element-wise operators: 1. Because everything is handled in terms of generator chains, all operations on an ElementwiseProxy are evaluated lazily. With element-wise operator overloading you would need to perform each operation immediately. 2. As a result of #1, you can undo operations you perform on an ElementwiseProxy with the parent property. 3. This still works if the person who created the class you're working with doesn't add support for element-wise operators. Sure, you could monkey patch their code, but that can lead to other problems down the line. 4. There isn't an obvious/intuitive character for element-wise versions of operators, and fewer symbols is better than more IMHO (see: Perl). Also, if you use the ElementwiseProxyMixin, you can sprinkle element-wise stuff in neatly just by using variable.each where you would use ~ in your examples. Upon this implementation I take back my comment on the whole typing thing. Your title just really confused me. * You can't just make functions non-elementwise unless called through .apply either: def str(x): return x.__str__() str is one of the special cases (along with repr, unicode, int, float, long, bool, etc). These can't ever be elementwise in CPython (I don't know that this holds in other interpreters). The idea is that you use ElementwiseProxy(x) or preferably x.each, work with your data in an element-wise capacity as needed, then list() or iter() back out. I think it should be a deliberate change of context. Interleaving the proxy (say via x.each) in mostly scalar expressions works, but wasn't the use case I designed it for, and in those circumstances it doesn't really offer anything above the map function. Nathan -- http://mail.python.org/mailman/listinfo/python-list
Re: Elementwise -//- first release -//- Element-wise (vectorized) function, method and operator support for iterables in python.
Have you seen PyLINQ? It has a similar approach to operating on
collections, returning a PyLINQ object after each call to facilitate
chaining. https://github.com/kalessin/PyLINQ/blob/master/pylinq/linq.py
I hadn't seen it previously. I am a VERY heavy user of SQL Alchemy
though, and I am sure chaining generative ClauseElements/Queries/etc,
has burned some patterns into my subconscious at this point.
This is a personal opinion on the code, but I'd move instantiating the
new ElementwiseProxy out of each method and into its own decorator:
# declare this outside of the class
def chainable(fn):
def _(self, *args, **kwargs):
return ElementwiseProxy(fn(self, *args, **kwargs), self)
return _
This way, each method that is chainable is a little more obvious
without inspecting the code, and the method body itself is only doing
what the method says it does:
@chainable
def __add__(self, other):
return (e + other for e in object.__getattribute__(self,
iterable))
This is a reasonable suggestion and I will play with something along
those lines soon.
Incidentally, displaying an ElementwiseProxy instance doesn't go down
well with iPython:
In [1]: from elementwise import *
In [2]: e = ElementwiseProxy(['one','two','three'])
In [3]: e
Out[3]: ERROR: An unexpected error occurred while tokenizing input
The following traceback may be corrupted or invalid
The error message is: ('EOF in multi-line statement', (6, 0))
I love IPython, but it has had known problems with iterators for
years. A long time ago, I agonized over what I thought was a bug in
my code where itertools.count would skip numbers in IPython, but my
unit tests all passed. Everything should work fine if you tuple() it
first.
Nathan
--
http://mail.python.org/mailman/listinfo/python-list
Re: Learning Python 2.4
On 21 December 2011 20:06, DJC djc@news.invalid wrote: In which case the most important thing is the quality of the book as a text on Programming. If you find the the author's style to your taste, then use that book rather than struggle with a text based on a recent version that you personally find unreadable. This is very good advice. -- Ashton Fagg E-mail: ash...@fagg.id.au Web: http://www.fagg.id.au/~ashton/ Keep calm and call Batman. -- http://mail.python.org/mailman/listinfo/python-list
Re: [OT] Quick intro to C++ for a Python and C user?
On 2011-12-21, Neil Cerutti ne...@norwich.edu wrote: On 2011-12-20, Paul Rubin no.email@nospam.invalid wrote: Grant Edwards invalid@invalid.invalid writes: Oops. I should have mentioned this is for embedded systems programming so templates in general (and STL in particular) are probably off the table. Templates are how C++ does generics and I'd expect them to appear in be used in embedded programming as well as elsewhere. I've only worked on the perphery of a couple embedded projects that used C++, but it seems to be farily common practice to prohibit the use of templates in embedded code. The problem seems to be that people writing C++ code don't really understand the language, how templates work, or (in general) the implications of the code they write. So, you have to prohibit anything that can be easily misused or cause non-obvious problems. For exaple (quoting from http://en.wikipedia.org/wiki/Embedded_C%2B%2B): Embedded C++ is a proper subset of C++. The following language features have been removed: Multiple inheritance Virtual base classes Run-time type information (typeid) New style casts (static_cast, dynamic_cast, reinterpret_cast and const_cast) The mutable type qualifier Namespaces Exceptions Templates Some people go further and prohibit any run-time object creation. They can bloat up the code if you're not careful Bingo. In my experience, many (if not most) C++ programmers don't understand enough of the language to realize what being careful means. (if function f has several parameters, you can end up with a separate, specialized copy of f for every combination of types that f is called with in the program), but in the typical monomorphic situation they don't add any overhead. I'm not sure about the situation with STL. Anyway, templates aren't terribly hard to understand. Moreover, if you don't plan to take advantage of templates or inheritance, then you could as well write C++ compatible C and be pretty happy with the results. Well, there are other C++ features that C doesn't have (e.g. exceptions -- but they're often prohibitted in embedded programming as well). Personally, I think C++ is an awful language in general and a _really_ awful language for embedded systems work. -- Grant Edwards grant.b.edwardsYow! PEGGY FLEMMING is at stealing BASKET BALLS to gmail.comfeed the babies in VERMONT. -- http://mail.python.org/mailman/listinfo/python-list
Re: Pythonification of the asterisk-based collection packing/unpacking syntax
Clarification: where can packing/unpacking syntax be used? It would be great if it were valid essentially anywhere (not limited to parameter passing). What about constructs like: a, @tuple tail, b = sequence? -- http://mail.python.org/mailman/listinfo/python-list
Re: [OT] Quick intro to C++ for a Python and C user?
On 2011-12-21, Grant Edwards invalid@invalid.invalid wrote: On 2011-12-21, Neil Cerutti ne...@norwich.edu wrote: On 2011-12-20, Paul Rubin no.email@nospam.invalid wrote: Grant Edwards invalid@invalid.invalid writes: Oops. I should have mentioned this is for embedded systems programming so templates in general (and STL in particular) are probably off the table. Templates are how C++ does generics and I'd expect them to appear in be used in embedded programming as well as elsewhere. I've only worked on the perphery of a couple embedded projects that used C++, but it seems to be farily common practice to prohibit the use of templates in embedded code. The problem seems to be that people writing C++ code don't really understand the language, how templates work, or (in general) the implications of the code they write. So, you have to prohibit anything that can be easily misused or cause non-obvious problems. I cheerfully agree that programmers ignorant of C++ should not write programs in it. But furthermore, they should also not define a subset of C++ for use in embedded programming. ;) -- Neil Cerutti -- http://mail.python.org/mailman/listinfo/python-list
Re: Elementwise -//- first release -//- Element-wise (vectorized) function, method and operator support for iterables in python.
On 12/21/11 3:15 PM, Nathan Rice wrote:
Incidentally, displaying an ElementwiseProxy instance doesn't go down
well with iPython:
In [1]: from elementwise import *
In [2]: e = ElementwiseProxy(['one','two','three'])
In [3]: e
Out[3]: ERROR: An unexpected error occurred while tokenizing input
The following traceback may be corrupted or invalid
The error message is: ('EOF in multi-line statement', (6, 0))
I love IPython, but it has had known problems with iterators for
years. A long time ago, I agonized over what I thought was a bug in
my code where itertools.count would skip numbers in IPython, but my
unit tests all passed. Everything should work fine if you tuple() it
first.
This is a different problem, actually. The problem is that the recently added
(by me, actually) pretty-printing system tries to dispatch based on the type. In
order to handle old-style classes, it checks for the type using .__class__
first. ElementProxy's __getattribute__() gets in the way here by returning a
generator instead of the ElementProxy class.
--
Robert Kern
I have come to believe that the whole world is an enigma, a harmless enigma
that is made terrible by our own mad attempt to interpret it as though it had
an underlying truth.
-- Umberto Eco
--
http://mail.python.org/mailman/listinfo/python-list
Re: Elementwise -//- first release -//- Element-wise (vectorized) function, method and operator support for iterables in python.
On Wed, Dec 21, 2011 at 11:29 AM, Robert Kern robert.k...@gmail.com wrote:
On 12/21/11 3:15 PM, Nathan Rice wrote:
Incidentally, displaying an ElementwiseProxy instance doesn't go down
well with iPython:
In [1]: from elementwise import *
In [2]: e = ElementwiseProxy(['one','two','three'])
In [3]: e
Out[3]: ERROR: An unexpected error occurred while tokenizing input
The following traceback may be corrupted or invalid
The error message is: ('EOF in multi-line statement', (6, 0))
I love IPython, but it has had known problems with iterators for
years. A long time ago, I agonized over what I thought was a bug in
my code where itertools.count would skip numbers in IPython, but my
unit tests all passed. Everything should work fine if you tuple() it
first.
This is a different problem, actually. The problem is that the recently
added (by me, actually) pretty-printing system tries to dispatch based on
the type. In order to handle old-style classes, it checks for the type using
.__class__ first. ElementProxy's __getattribute__() gets in the way here by
returning a generator instead of the ElementProxy class.
Thanks for the heads up Robert. Given that IPython is awesome and
people should probably be doing an '.apply(type)' in that instance
anyhow, I will corner case that on __getattribute__.
Nathan
--
http://mail.python.org/mailman/listinfo/python-list
Re: Elementwise -//- first release -//- Element-wise (vectorized) function, method and operator support for iterables in python.
On 21 December 2011 15:07, Nathan Rice nathan.alexander.r...@gmail.comwrote: On Tue, Dec 20, 2011 at 8:37 PM, Joshua Landau joshua.landau...@gmail.com wrote: On 21 December 2011 00:24, Nathan Rice nathan.alexander.r...@gmail.com wrote: efoo_res = ((efoo2.capitalize() + little indian).split( ).apply(reversed) * 2).apply(_.join) # note that you could do reversed(...) instead, I just like to read left to right efoo_res.parent.parent.parent # same as ((efoo2.capitalize() + little indian).split( ) in case you need to debug something and want to look at intermediate values How is any of this better than the elementwise operators (~)? People should be able to expect len(x) to always return a number or raise an error. I know it's not part of the spec, but a lot breaks without these guarantees. When str(x) isn't a string, all the formatting code breaks*. And when the other suggestion (~str(x) or str~(x) or something similar) has all the benifits and none of the drawbacks, why should I use this? len() will always return a number or raise an error, just like the type functions (bool/int/etc) return that type or raise an error. The interpreter guarantees that for you. The point wasn't that either way was better, but that with this implementation you get neither choice (len(x) vs len~(x)) or reliability. The reliability point works like this: You want to elementwise a few functions, that before you were doing on a single item. BEFORE: item = foreignfunc1(item) item = foreignfunc2(item) item = foreignfunc3(item) NOW (your method): item = ElementwiseProxy(item) item = foreignfunc1(item) item = foreignfunc2(item) item = foreignfunc3(item) item = list(item) NOW (the PEP): item = foreignfunc1~(item) item = foreignfunc2~(item) item = foreignfunc3~(item) NOW (map): # or imap to do it lazily item = map(foreignfunc1, (item)) item = map(foreignfunc2, (item)) item = map(foreignfunc3, (item)) The PEP is short and quaint, and makes lots of things shorter than map ([1,2,3]~+[5,6,7]), so you can see the advantages. That's why I like the PEP as syntatic sugar. The mapping method works fine. *You might think your method works. *But what if foreignfunc is str? *And you can't blacklist functions.* You can't say everything works bar A, B and C. What if you get: lambda x:str(x)? You can't blacklist that. That makes the ElementwiseProxy version buggy and prone to unstable operation. If it's consistent, fine. But it's not. This has a couple of advantages over element-wise operators: Couple == 2 :P 1. Because everything is handled in terms of generator chains, all operations on an ElementwiseProxy are evaluated lazily. With element-wise operator overloading you would need to perform each operation immediately. I agree this can be a preferred advantage.But you still have to choose one. ~ could be lazy, or it could be eager. But in both implementations you have to choose. That said, you have map and imap, and so you could have ElemetwiseProxy and eElementwiseProxy (eager), and you can have ~ and i~. Remember that the syntax I'm using is just for PEP consistency. Some more creative people can find a syntax that works. 2. As a result of #1, you can undo operations you perform on an ElementwiseProxy with the parent property. Use case? If this is actually a wanted feature, parent could be made a general property of iterators. (x for x in foo).parent == foo I think that's a separate proposal that isn't intrinsic to this idea. 3. This still works if the person who created the class you're working with doesn't add support for element-wise operators. Sure, you could monkey patch their code, but that can lead to other problems down the line. Example? I'm struggling to think of a case where you could do this only with one. 4. There isn't an obvious/intuitive character for element-wise versions of operators, and fewer symbols is better than more IMHO (see: Perl). Also, if you use the ElementwiseProxyMixin, you can sprinkle element-wise stuff in neatly just by using variable.each where you would use ~ in your examples. Obvious/intuitive is meaningless for something so potentially common. ** is far more obscure (* is obscure enough). Why is a double star the exponent character? Because it works. ~ would be easy to learn and consistent, once a standard was agreed. And again, I'm only using that syntax because it's the one in the PEP. We're not going to get to Perl, I hope, with this addition. Explicit Implicit. If someone passes you a variable.each, things go haywire (see: first section of reply). ~ is explicit. It doesn't have these problems. I also think explicit looks nicer. 'Cause it is, y'know :P Upon this implementation I take back my comment on the whole typing thing. Your title just really confused me. * You can't just make functions non-elementwise unless called through .apply either: def str(x): return x.__str__() str is one of the special
Re: Pythonification of the asterisk-based collection packing/unpacking syntax
Neal Becker wrote: Clarification: where can packing/unpacking syntax be used? It would be great if it were valid essentially anywhere (not limited to parameter passing). What about constructs like: a, @tuple tail, b = sequence? You mean like Python 3's: a, *middle, b = sequence ? -- http://mail.python.org/mailman/listinfo/python-list
Re: Pythonification of the asterisk-based collection packing/unpacking syntax
On 21 December 2011 15:48, Neal Becker ndbeck...@gmail.com wrote: Clarification: where can packing/unpacking syntax be used? It would be great if it were valid essentially anywhere (not limited to parameter passing). What about constructs like: a, @tuple tail, b = sequence? a, *b, c = range(10) a, b, c (0, [1, 2, 3, 4, 5, 6, 7, 8], 9) It's just a proposed syntax change, effectively, so yes. However, http://bugs.python.org/issue2292 covers the ones we don't have (that we should :P). This discussion doesn't cover that. -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
Re: Python education survey
+1 for IPython/%edit using the simplest editor that supports syntax highlighting and line numbers. I have found that Exploring/Prototyping in the interpreter has the highest ROI of anything I teach people. Nathan -- http://mail.python.org/mailman/listinfo/python-list
Re: Elementwise -//- first release -//- Element-wise (vectorized) function, method and operator support for iterables in python.
You're reinventing Numeric Python. On Tue, Dec 20, 2011 at 11:45 AM, Nathan Rice nathan.alexander.r...@gmail.com wrote: Elementwise provides a proxy object for iterables which supports chained method calls, as well as elementwise expressions and some built-in functions. Example: class ExampleList(ElementwiseProxyMixin, list): def __new__(cls, iterable): return list.__new__(cls, iterable) foo = ExampleList([1, 2, 3, 4]) # You could also do: efoo = ElementwiseProxy(foo) efoo = foo.each assert list(efoo.bit_length()) == [1, 2, 2, 3] print bit length: , list(efoo.bit_length()) assert list(efoo + 1) == [2, 3, 4, 5] print with addition of 1: , list(efoo + 1) assert list(efoo * 2) == [2, 4, 6, 8] print with multiplication by 2: , list(efoo * 2) assert list(efoo == 2) == [False, True, False, False] print testing equality: , efoo == 2 assert list((efoo + 1) * 2 + 3) == [7, 9, 11, 13] print chaining addition and multiplication: , (efoo + 1) * 2 + 3 Each ElementwiseProxy also has a parent attribute so you can backtrack in the chain as needed rather than store each intermediate value, if you think you might need them. There are still some issues with proper support of things like bool() and int(), which refuse to return things that are not of the correct type. Get it: PyPi: http://pypi.python.org/pypi/elementwise/0.111220 GitHub: https://github.com/nathan-rice/Elementwise This was developed as a proof of concept for expanding the role of element-wise syntax in python, and to that end I welcome comments. Nathan Rice -- http://mail.python.org/mailman/listinfo/python-announce-list Support the Python Software Foundation: http://www.python.org/psf/donations/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Elementwise -//- first release -//- Element-wise (vectorized) function, method and operator support for iterables in python.
On Wed, Dec 21, 2011 at 12:07 PM, Paul Dubois pfdub...@gmail.com wrote: You're reinventing Numeric Python. I prefer to think of it in terms of paying homage to NumPy (and functional programming). A big part of the motivation for this was bringing the elegance of NumPy to other areas of python besides numerical/scientific programming. Nathan -- http://mail.python.org/mailman/listinfo/python-list
Re: Anyone still using Python 2.5?
On 12/21/11 07:07, Roy Smith wrote: In article4ef1b9fa$0$29973$c3e8da3$54964...@news.astraweb.com, Steven D'Apranosteve+comp.lang.pyt...@pearwood.info wrote: Centos and Red Hat production systems still use Python 2.4, so yes, absolutely, 2.5 and 2.4 still need to be supported. Is Python 2.4 destined to be the next IE-6? No...unlike IE6, 2.4 backwards compatibility has a foreseeable death when RHEL+2.6 eventually fall out of support ;-) -tkc -- http://mail.python.org/mailman/listinfo/python-list
Re: Learning Python 2.4
On 2011-12-20 19:31, kimma wrote: I am about to learn python with how to think like a computer scientist. This book is just available for python 2.4. Does it matter for programming? There is also a online-version for Python 3 but there are some differences: http://openbookproject.net/thinkcs/python/english3e/preface3-rle.html Bye, Andreas -- http://mail.python.org/mailman/listinfo/python-list
Re: Why widgets become 'NoneType'?
The error is with the labels not the canvas. All labels will have an id of None as that is what pack() returns. lbl = Label(win, text=astr[i]).pack(side=LEFT ) labels.append(lbl) The error will come up in the config_labels function when the program tries to config a tuple of None, if not before. Other than that, the previous suggestion, post the entire error message so we know where an what is happening, is required to debug further. -- http://mail.python.org/mailman/listinfo/python-list
Re: Elementwise -//- first release -//- Element-wise (vectorized) function, method and operator support for iterables in python.
On Wed, Dec 21, 2011 at 9:48 AM, Joshua Landau joshua.landau...@gmail.com wrote: functions, that before you were doing on a single item. BEFORE: item = foreignfunc1(item) item = foreignfunc2(item) item = foreignfunc3(item) NOW (your method): item = ElementwiseProxy(item) item = foreignfunc1(item) item = foreignfunc2(item) item = foreignfunc3(item) item = list(item) Shouldn't that be: item = ElementwiseProxy(item) item = item.apply(foreignfunc1) item = item.apply(foreignfunc2) item = item.apply(foreignfunc3) item = list(item) You might think your method works. But what if foreignfunc is str? And you can't blacklist functions. You can't say everything works bar A, B and C. What if you get: lambda x:str(x)? You can't blacklist that. That makes the ElementwiseProxy version buggy and prone to unstable operation. If it's consistent, fine. But it's not. I'm not sure I understand this criticism. There is no blacklisting going on that I am aware of. The behavior seems consistent to me: Python 2.7.1 (r271:86832, Nov 27 2010, 18:30:46) [MSC v.1500 32 bit (Intel)] on win32 Type help, copyright, credits or license for more information. from elementwise import * ewp = ElementwiseProxy(range(5)) str(ewp) '0, 1, 2, 3, 4' (lambda x: str(x))(ewp) '0, 1, 2, 3, 4' ewp.apply(str) '0', '1', '2', '3', '4' ewp.apply(lambda x: str(x)) '0', '1', '2', '3', '4' All of which is exactly what I expected to get. Cheers, Ian -- http://mail.python.org/mailman/listinfo/python-list
Re: Elementwise -//- first release -//- Element-wise (vectorized) function, method and operator support for iterables in python.
On 21 December 2011 00:24, Nathan Rice nathan.alexander.r...@gmail.com wrote: efoo2 = ElementwiseProxy([one, two, three, four]) efoo_res = ((efoo2.capitalize() + little indian).split( ).apply(reversed) * 2).apply(_.join) # note that you could do reversed(...) instead, I just like to read left to right efoo_res.parent.parent.parent # same as ((efoo2.capitalize() + little indian).split( ) in case you need to debug something and want to look at intermediate values You can already do: efoo2 = [one, two, three, four] [_.join(reversed((x.capitalize() + little indian).split( )) * 2) for x in efoo2] Note 1: I've ignored the fact that reversed(...)*2 is erroneous Note 2: I wouldn't such code myself, in either form What's the advantage of your elementwise stuff? -- Arnaud -- http://mail.python.org/mailman/listinfo/python-list
Re: Elementwise -//- first release -//- Element-wise (vectorized) function, method and operator support for iterables in python.
Steven D'Aprano wrote: I'm just glad that you've put your money where your mouth is, and released the package, instead of demanding others do the work. Thank you. +1000! ~Ethan~ -- http://mail.python.org/mailman/listinfo/python-list
Re: Elementwise -//- first release -//- Element-wise (vectorized) function, method and operator support for iterables in python.
On Tue, Dec 20, 2011 at 12:45 PM, Nathan Rice nathan.alexander.r...@gmail.com wrote: Elementwise provides a proxy object for iterables which supports chained method calls, as well as elementwise expressions and some built-in functions. It doesn't seem to work correctly when both operands are Elementwise: numerator = ElementwiseProxy(range(5)) denominator = ElementwiseProxy([2, 2, 3, 3, 3]) remainder = numerator % denominator print remainder Traceback (most recent call last): File stdin, line 1, in module File elementwise.py, line 72, in __repr__ return , .join(e.__repr__() for e in object.__getattribute__(self, iterable)) TypeError: sequence item 0: expected string, ElementwiseProxy found list(remainder) [] Cheers, Ian -- http://mail.python.org/mailman/listinfo/python-list
Re: Elementwise -//- first release -//- Element-wise (vectorized) function, method and operator support for iterables in python.
On Tue, Dec 20, 2011 at 8:37 PM, Joshua Landau joshua.landau...@gmail.com wrote: On 21 December 2011 00:24, Nathan Rice nathan.alexander.r...@gmail.com wrote: efoo_res = ((efoo2.capitalize() + little indian).split( ).apply(reversed) * 2).apply(_.join) # note that you could do reversed(...) instead, I just like to read left to right efoo_res.parent.parent.parent # same as ((efoo2.capitalize() + little indian).split( ) in case you need to debug something and want to look at intermediate values How is any of this better than the elementwise operators (~)? People should be able to expect len(x) to always return a number or raise an error. I know it's not part of the spec, but a lot breaks without these guarantees. When str(x) isn't a string, all the formatting code breaks*. And when the other suggestion (~str(x) or str~(x) or something similar) has all the benifits and none of the drawbacks, why should I use this? len() will always return a number or raise an error, just like the type functions (bool/int/etc) return that type or raise an error. The interpreter guarantees that for you. The point wasn't that either way was better, but that with this implementation you get neither choice (len(x) vs len~(x)) or reliability. If len didn't have the hard coded behavior, you would have the choice of len(x) or len(x.each). Since a lot of code relies on len() returning an it, I think it is fine to accept that you have to use x.each.apply(len). I agree that this is a case where some kind of elementwise designation in the syntax would be better; if there was a ∀ character on the keyboard and more people knew what it meant I would have fewer reservations. The reliability point works like this: You want to elementwise a few functions, that before you were doing on a single item. BEFORE: item = foreignfunc1(item) item = foreignfunc2(item) item = foreignfunc3(item) NOW (your method): item = ElementwiseProxy(item) item = foreignfunc1(item) item = foreignfunc2(item) item = foreignfunc3(item) item = list(item) well, I would say it more like: item.each.apply(foreignfunc1).apply(foreignfunc2).apply(foreignfunc3) # I like to read left to right, what can I say? and I wouldn't list() it right away, since it is nice and lazy. You might think your method works. But what if foreignfunc is str? And you can't blacklist functions. You can't say everything works bar A, B and C. What if you get: lambda x:str(x)? You can't blacklist that. That makes the ElementwiseProxy version buggy and prone to unstable operation. If it's consistent, fine. But it's not. I don't need to blacklist anything. Everything that has funny behavior like str goes through special methods on the class (that I know of), and isn't hooked through __getattribute__, so I just handle it somewhat normally. 1. Because everything is handled in terms of generator chains, all operations on an ElementwiseProxy are evaluated lazily. With element-wise operator overloading you would need to perform each operation immediately. I agree this can be a preferred advantage.But you still have to choose one. ~ could be lazy, or it could be eager. But in both implementations you have to choose. That said, you have map and imap, and so you could have ElemetwiseProxy and eElementwiseProxy (eager), and you can have ~ and i~. Remember that the syntax I'm using is just for PEP consistency. Some more creative people can find a syntax that works. From my perspective the strength of operators is that they are intuitive, since we use them constantly in other areas; I can make a good guess about what X * Y or X + Y means in various contexts. When you introduce operators that don't have any well ingrained, standard meaning, you just make the syntax cryptic. 2. As a result of #1, you can undo operations you perform on an ElementwiseProxy with the parent property. Use case? If this is actually a wanted feature, parent could be made a general property of iterators. (x for x in foo).parent == foo I think that's a separate proposal that isn't intrinsic to this idea. One quick use case: I want to debug something big, slow and nasty; . I set breakpoints with conditions where it seems like the issue lies from the stack trace. Unfortunately I missed the root cause, and the variables that would help me debug it have been garbage collected. I can go through the entire process again, try to set better breakpoints and cross my fingers, or iterate over some subset of parent operations right there. I think I'll take the latter. 3. This still works if the person who created the class you're working with doesn't add support for element-wise operators. Sure, you could monkey patch their code, but that can lead to other problems down the line. As I understood it, the elementwise operators in the PEP weren't language magic, but new hooks to special methods. If it is language magic, that will probably
Re: Elementwise -//- first release -//- Element-wise (vectorized) function, method and operator support for iterables in python.
On Wed, Dec 21, 2011 at 12:53 PM, Arnaud Delobelle arno...@gmail.com wrote: You can already do: efoo2 = [one, two, three, four] [_.join(reversed((x.capitalize() + little indian).split( )) * 2) for x in efoo2] Note 1: I've ignored the fact that reversed(...)*2 is erroneous Note 2: I wouldn't such code myself, in either form What's the advantage of your elementwise stuff? Sit two theoretically identical programmers who have a decent grasp of python, understand the basics of ElementwiseProxy and the components of your version down side by side, and see which one can figure out what the output should be first. I will bet real money it is the one working with the ElementwiseProxy code. We have all had a lot of practice reading inside out and backwards in the python community with comprehensions and such, but it is in no way natural or easy. Additionally, everything done via an ElementwiseProxy is lazy, so you only pay for what you eat :) Nathan -- http://mail.python.org/mailman/listinfo/python-list
Re: Elementwise -//- first release -//- Element-wise (vectorized) function, method and operator support for iterables in python.
On 21 December 2011 17:51, Ian Kelly ian.g.ke...@gmail.com wrote: On Wed, Dec 21, 2011 at 9:48 AM, Joshua Landau joshua.landau...@gmail.com wrote: functions, that before you were doing on a single item. BEFORE: item = foreignfunc1(item) item = foreignfunc2(item) item = foreignfunc3(item) NOW (your method): item = ElementwiseProxy(item) item = foreignfunc1(item) item = foreignfunc2(item) item = foreignfunc3(item) item = list(item) Shouldn't that be: item = ElementwiseProxy(item) item = item.apply(foreignfunc1) item = item.apply(foreignfunc2) item = item.apply(foreignfunc3) item = list(item) I was under the impression that these were meant to be interchangeable. This is because functions are just wrappers to non-functions, really. from elementwise import ElementwiseProxy as P (lambda x:x+[1])(P([[0],[0],[0]])) [0, 1], [0, 1], [0, 1] If we have to use .apply, we might as well use map :P. Note that len and dir crash. *Here is a perfect example:* int(P([1,2,3])) Traceback (most recent call last): File stdin, line 1, in module *TypeError: __int__ returned non-int (type ElementwiseProxy)* It's elementwise, *but that breaks it.* An elementwise operator wouldn't have these problems. You might think your method works. But what if foreignfunc is str? And you can't blacklist functions. You can't say everything works bar A, B and C. What if you get: lambda x:str(x)? You can't blacklist that. That makes the ElementwiseProxy version buggy and prone to unstable operation. If it's consistent, fine. But it's not. I'm not sure I understand this criticism. There is no blacklisting going on that I am aware of. The behavior seems consistent to me: Python 2.7.1 (r271:86832, Nov 27 2010, 18:30:46) [MSC v.1500 32 bit (Intel)] on win32 Type help, copyright, credits or license for more information. from elementwise import * ewp = ElementwiseProxy(range(5)) str(ewp) '0, 1, 2, 3, 4' (lambda x: str(x))(ewp) '0, 1, 2, 3, 4' ewp.apply(str) '0', '1', '2', '3', '4' ewp.apply(lambda x: str(x)) '0', '1', '2', '3', '4' All of which is exactly what I expected to get. Again, str(x) in this context is an outlier. It's one of the exceptions to the rule of applying functions = elementwise. -- http://mail.python.org/mailman/listinfo/python-list
Re: Elementwise -//- first release -//- Element-wise (vectorized) function, method and operator support for iterables in python.
It doesn't seem to work correctly when both operands are Elementwise: numerator = ElementwiseProxy(range(5)) denominator = ElementwiseProxy([2, 2, 3, 3, 3]) remainder = numerator % denominator print remainder Traceback (most recent call last): File stdin, line 1, in module File elementwise.py, line 72, in __repr__ return , .join(e.__repr__() for e in object.__getattribute__(self, iterable)) TypeError: sequence item 0: expected string, ElementwiseProxy found list(remainder) [] Cheers, Ian Ian, can you clarify the expected output in that case? My initial guess would be that you want to do a modulo on the cartesian product of parameters from the proxies, sort of like: import itertools numerator = range(5) denominator = [2, 2, 3, 3, 3] remainder = [n % d for (n, d) in itertools.product(numerator, denominator)] Nathan -- http://mail.python.org/mailman/listinfo/python-list
Re: Elementwise -//- first release -//- Element-wise (vectorized) function, method and operator support for iterables in python.
On Wed, Dec 21, 2011 at 1:24 PM, Joshua Landau joshua.landau...@gmail.com wrote: I was under the impression that these were meant to be interchangeable. This is because functions are just wrappers to non-functions, really. from elementwise import ElementwiseProxy as P (lambda x:x+[1])(P([[0],[0],[0]])) [0, 1], [0, 1], [0, 1] If we have to use .apply, we might as well use map :P. Apply is not required, you can use functions. I just hate reading inside out and backwards. compare: func3(func2(func1(x))) # Fine if the chain is short, but quickly gets unreadable x.apply(func1).apply(func2).apply(func3) # More verbose when working with short chains, but infinitely clearer and more readable when things start getting complicated, or for less experienced coders Note that len and dir crash. Here is a perfect example: int(P([1,2,3])) Traceback (most recent call last): File stdin, line 1, in module TypeError: __int__ returned non-int (type ElementwiseProxy) It is alpha software :P Easily fixed though. Nathan -- http://mail.python.org/mailman/listinfo/python-list
Re: Elementwise -//- first release -//- Element-wise (vectorized) function, method and operator support for iterables in python.
On Wed, Dec 21, 2011 at 11:24 AM, Joshua Landau joshua.landau...@gmail.com wrote: I was under the impression that these were meant to be interchangeable. This is because functions are just wrappers to non-functions, really. from elementwise import ElementwiseProxy as P (lambda x:x+[1])(P([[0],[0],[0]])) [0, 1], [0, 1], [0, 1] If we have to use .apply, we might as well use map :P. Agreed. The advantage of .apply here is that when the functions are nested they are written left-to-right. But I wouldn't be using multiple maps or applys on a single line anyway -- my goal is to write clear code, not great one-liners. :-D -- http://mail.python.org/mailman/listinfo/python-list
Re: Elementwise -//- first release -//- Element-wise (vectorized) function, method and operator support for iterables in python.
On Wed, Dec 21, 2011 at 11:27 AM, Nathan Rice nathan.alexander.r...@gmail.com wrote: Ian, can you clarify the expected output in that case? My initial guess would be that you want to do a modulo on the cartesian product of parameters from the proxies, sort of like: import itertools numerator = range(5) denominator = [2, 2, 3, 3, 3] remainder = [n % d for (n, d) in itertools.product(numerator, denominator)] I expected the equivalent of: remainder = [n % d for (n, d) in zip(numerator, denominator)] which is what numpy does. -- http://mail.python.org/mailman/listinfo/python-list
Multiprocessing.Pipe in a daemon
So, I'm running into a somewhat crazy bug.
I am running several workers using multiprocessing to handle gearman
requests. I'm using pipes to funnel log messages from each of the
workers back to the controlling process, which iterates over the other
end of the pipe, looking for messages with poll(), and logging them
using the parent's log handler.
This works really well when I'm not daemonizing the entire thing.
However, when I daemonize the process (which happens well prior to any
setup of the pipes multiprocess.Process'es), a pipe which has
nothing in it return True for the poll(), and then blocks on the
pipe.recv() command. The gearman workers are still operational and
responsive, and only starting one worker resolves the problem.
Has anybody seen anything like this?
#Trim
# Create all of the end points
endpoints = []
log_pipes = []
for w_num in range(5):
(recv, snd) = multiprocessing.Pipe(False)
# Start the worker
logger.debug(Creating the worker {0}.format(w_num))
worker = Worker(w_num, job_name, gm_servers, snd)
# Add the worker to the list of endpoints so it can be started
endpoints.append(worker)
log_pipes.append(recv)
# Trim starting endpoints
try:
while True:
time.sleep(1)
pipe_logger(logger, log_pipes)
except (KeyboardInterrupt, SignalQuit):
pass
# Trim cleanup
def pipe_logger(logger_obj, pipes):
done =
False
while not done:
done =
True
for p in
pipes:
if p.poll(): # -- Returning true after a previous
pipe actually had data
try:
log_level, log_msg = p.recv() # -- Hanging
here
except EOFError:
continue
done = False
--
http://mail.python.org/mailman/listinfo/python-list
Re: Elementwise -//- first release -//- Element-wise (vectorized) function, method and operator support for iterables in python.
On 21 December 2011 18:32, Nathan Rice nathan.alexander.r...@gmail.comwrote: On Wed, Dec 21, 2011 at 1:24 PM, Joshua Landau joshua.landau...@gmail.com wrote: I was under the impression that these were meant to be interchangeable. This is because functions are just wrappers to non-functions, really. from elementwise import ElementwiseProxy as P (lambda x:x+[1])(P([[0],[0],[0]])) [0, 1], [0, 1], [0, 1] If we have to use .apply, we might as well use map :P. Apply is not required, you can use functions. I just hate reading inside out and backwards. compare: func3(func2(func1(x))) # Fine if the chain is short, but quickly gets unreadable x.apply(func1).apply(func2).apply(func3) # More verbose when working with short chains, but infinitely clearer and more readable when things start getting complicated, or for less experienced coders I wan't disagreeing with that, hence the word if. I was just making a counter-counter point to a misunderstanding of my post. Note that len and dir crash. Here is a perfect example: int(P([1,2,3])) Traceback (most recent call last): File stdin, line 1, in module TypeError: __int__ returned non-int (type ElementwiseProxy) It is alpha software :P Easily fixed though. If fix means return number then no. This inconsistency between elementwise operations and 'normal' ones is the problem. Again, explicit elementwise-ifying through ~ fixes that. You need to tell me why this is worth the confusion over that. -- http://mail.python.org/mailman/listinfo/python-list
Re: Elementwise -//- first release -//- Element-wise (vectorized) function, method and operator support for iterables in python.
On Wed, Dec 21, 2011 at 9:48 AM, Joshua Landau joshua.landau...@gmail.com wrote: NOW (the PEP): item = foreignfunc1~(item) item = foreignfunc2~(item) item = foreignfunc3~(item) Just a note: PEP 225 does not actually include this syntax for arbitrary function calls. It only proposes to augment the arithmetic and assignment operators. -- http://mail.python.org/mailman/listinfo/python-list
Re: Elementwise -//- first release -//- Element-wise (vectorized) function, method and operator support for iterables in python.
On 21 December 2011 18:57, Ian Kelly ian.g.ke...@gmail.com wrote: On Wed, Dec 21, 2011 at 9:48 AM, Joshua Landau joshua.landau...@gmail.com wrote: NOW (the PEP): item = foreignfunc1~(item) item = foreignfunc2~(item) item = foreignfunc3~(item) Just a note: PEP 225 does not actually include this syntax for arbitrary function calls. It only proposes to augment the arithmetic and assignment operators. Not quite. They never seem to have come to an agreement (the whole thing is deferred) but they do touch upon ~f(x): 5. Using ~ as generic elementwise meta-character to replace map ~f(a, b) # map(f, a, b) ~~f(a, b) # map(lambda *x:map(f, *x), a, b) More generally, def ~f(*x): return map(f, *x) def ~~f(*x): return map(~f, *x) ... I used f~(x) because it's not ambiguous with the current binary not operator. -- http://mail.python.org/mailman/listinfo/python-list
Why does this launch an infinite loop of new processes?
I am trying to understand the multiprocessing module, and I tried some
simple code:
import multiprocessing
def f():
print('bla bla')
p = multiprocessing.Process(target=f)
p.start()
p.join()
And the result is a new process that spawns a new process that spawns a
new process ad infinitum until I log out and the OS forcefully
terminates all my user processes. I have no idea what is happening; I
expected it to just print the string and terminate.
--
CPython 3.2.2 | Windows NT 6.1.7601.17640 | Thunderbird 7.0
--
http://mail.python.org/mailman/listinfo/python-list
Re: Elementwise -//- first release -//- Element-wise (vectorized) function, method and operator support for iterables in python.
On 21 December 2011 19:00, Joshua Landau joshua.landau...@gmail.com wrote: On 21 December 2011 18:57, Ian Kelly ian.g.ke...@gmail.com wrote: On Wed, Dec 21, 2011 at 9:48 AM, Joshua Landau joshua.landau...@gmail.com wrote: NOW (the PEP): item = foreignfunc1~(item) item = foreignfunc2~(item) item = foreignfunc3~(item) Just a note: PEP 225 does not actually include this syntax for arbitrary function calls. It only proposes to augment the arithmetic and assignment operators. Not quite. They never seem to have come to an agreement (the whole thing is deferred) but they do touch upon ~f(x): 5. Using ~ as generic elementwise meta-character to replace map ~f(a, b) # map(f, a, b) ~~f(a, b) # map(lambda *x:map(f, *x), a, b) More generally, def ~f(*x): return map(f, *x) def ~~f(*x): return map(~f, *x) ... I used f~(x) because it's not ambiguous with the current binary not operator. Apologies for the double post but I think it's worth mentioning that I did make up the list~.method syntax. -- http://mail.python.org/mailman/listinfo/python-list
Re: Elementwise -//- first release -//- Element-wise (vectorized) function, method and operator support for iterables in python.
On Wed, Dec 21, 2011 at 1:41 PM, Ian Kelly ian.g.ke...@gmail.com wrote: I expected the equivalent of: remainder = [n % d for (n, d) in zip(numerator, denominator)] which is what numpy does. I do want to come up with a nice way to do that... However: if numerator and denominator are plain lists that magically have an each method... each_numerator = numerator.each each_denominator = denominator.each each_numerator % each_denominator see where I'm going with the mismatch on the semantics? I know the example is a bit contrived, sorry. Expanding iterators by default might be a worth a shot though, since passing around iterators like that is pretty rare. Nathan -- http://mail.python.org/mailman/listinfo/python-list
Re: Why does this launch an infinite loop of new processes?
On 12/21/2011 1:07 PM, Joshua Landau wrote: Eh? It works for me. Python 3.2 + 2.7 Is this the full code? That is the full code. -- CPython 3.2.2 | Windows NT 6.1.7601.17640 | Thunderbird 7.0 -- http://mail.python.org/mailman/listinfo/python-list
Re: Why does this launch an infinite loop of new processes?
On 21 December 2011 18:59, Andrew Berg bahamutzero8...@gmail.com wrote:
I am trying to understand the multiprocessing module, and I tried some
simple code:
import multiprocessing
def f():
print('bla bla')
p = multiprocessing.Process(target=f)
p.start()
p.join()
And the result is a new process that spawns a new process that spawns a
new process ad infinitum until I log out and the OS forcefully
terminates all my user processes. I have no idea what is happening; I
expected it to just print the string and terminate.
Eh? It works for me. Python 3.2 + 2.7
Is this the full code?
--
http://mail.python.org/mailman/listinfo/python-list
Newbie OOP Question Code Snippet
Hi All,
I'm a newbie just learning Python, using a couple of books to learn the
language. (Books: Visual Quickstart Guide - Python, 2nd Ed, Practical
Programming - An Intro to Computer Science using Python). I'm just now
learning OOP material as presented in both books -- I'm new to this
approach -- the last formal language I learned was Fortran77 -- :o) I am
running Python 3.2.1 on Mac OS/X 10.6.8.
My problem stems from a simple example in the Visual Quickstart book. The
code is:
#person.py
class Person:
Class to represent a person
def __init__(self):
self.name=' '
self.age=0
def display(self):
print(Person('%s', age) %
(self.name, self.age))
-
When I run this, the shell presents thus:
RESTART
p=Person()
p.name='Bob'
p.age=24
p.display()
Traceback (most recent call last):
File pyshell#33, line 1, in module
p.display()
File /Volumes/dean_richardson/GoFlex Home Personal/Dean's
Code/Python3.x/Person.py, line 9, in display
(self.name, self.age))
TypeError: not all arguments converted during string formatting
---
I'm sure this is something simple, but I can't see it. Any help appreciated!
Regards,
Dean
--
http://mail.python.org/mailman/listinfo/python-list
Need advice on the design of my application
I am writing a hull-wave simulator for the design of boat hulls as they are affected by waves. This application is composed of 2 main parts, the part that renders the waves and its impact on the hull, and a GUI that controls the hull shape, waves, and other factors. The two parts of the application will need to exchange data, for example, the GUI will set the hull shape and this will be displayed by the renderer. The renderer will show the waves and it will tell the GUI statistics about the waves as they are being animated. This application will run on Windows. The Renderer part of the application must be written in C because it needs to do very fast numerical calculations and requires the use of OpenGL and must render very quickly. The GUI part of the application will be wxPython. The options for constructing the application that I have thought of are: 1) The wxPython part launches the Renderer on a thread, and the Renderer is a DLL (provided a DLL can display graphics). 2) The Renderer starts a thread where the Python interpreter is embedded, which launches wxPython. 3) The Renderer and the GUI are actually two separate applications that communicate with each other over a socket. My last resort is Option 3 because communications can be a hassle. Option 1 seems to be the easiest but will be very difficult to debug the Renderer using my IDE because it is a DLL, if a DLL can display graphics at all. Option 2 seems to be the most feasible both in terms of debugging and displaying graphics. I have concerns about the Python GIL and how that will affect the way this program will work. The Renderer is going to be running a tight loop. The GUI under wxPython also runs a main loop internally, but has the ability to put function calls on a sort of stack to be executed without interrupting its main loop. In my experience implementing Option 1 in another project, I know that Python suspends execution until the DLL function calls return, but I did not launch the DLL on a thread. I expect that if the DLL were launched on a thread, a function call into the DLL will still suspend Python. Maybe someone can tell me if this is true? Option 2 is of most interest to me, but how shall I handle the Python GIL when the Renderer runs its main loop? Will the main loop be unaffected because Python interpreter is embedded in a thread? -- http://mail.python.org/mailman/listinfo/python-list
Re: Newbie OOP Question Code Snippet
On 21/12/2011 19:12, Dean Richardson P.Eng wrote:
Hi All,
I'm a newbie just learning Python, using a couple of books to learn the
language. (Books: Visual Quickstart Guide - Python, 2nd Ed, Practical
Programming - An Intro to Computer Science using Python). I'm just now
learning OOP material as presented in both books -- I'm new to this
approach -- the last formal language I learned was Fortran77 -- :o) I
am running Python 3.2.1 on Mac OS/X 10.6.8.
My problem stems from a simple example in the Visual Quickstart book.
The code is:
#person.py
class Person:
Class to represent a person
def __init__(self):
self.name=' '
self.age=0
def display(self):
print(Person('%s', age) %
(self.name, self.age))
-
When I run this, the shell presents thus:
RESTART
p=Person()
p.name http://p.name='Bob'
p.age=24
p.display()
Traceback (most recent call last):
File pyshell#33, line 1, in module
p.display()
File /Volumes/dean_richardson/GoFlex Home Personal/Dean's
Code/Python3.x/Person.py, line 9, in display
(self.name http://self.name, self.age))
TypeError: not all arguments converted during string formatting
---
I'm sure this is something simple, but I can't see it. Any help appreciated!
It should be:
print(Person('%s', %s) % (self.name, self.age))
As it is, you're giving it 2 values but only %s placeholder.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Need advice on the design of my application
On Wed, Dec 21, 2011 at 11:19 AM, hbd666 happybrown...@hotmail.com wrote: snip In my experience implementing Option 1 in another project, I know that Python suspends execution until the DLL function calls return, but I did not launch the DLL on a thread. I expect that if the DLL were launched on a thread, a function call into the DLL will still suspend Python. Maybe someone can tell me if this is true? Option 2 is of most interest to me, but how shall I handle the Python GIL when the Renderer runs its main loop? Will the main loop be unaffected because Python interpreter is embedded in a thread? When extending Python (as option 1 would do), the extension would block all Python threads if called from Python (though c-threads created by the module would not block Python). You can explicitly release the GIL during your C code's execution, which would cause only the thread actually making the call to be blocked (as it is actually running the C code), but other Python threads would still be able to run. When embedding Python (as option 2 would do), the embedding program will not be affected by the GIL unless it explicitly acquires the GIL (which is must do before accessing Python). Via the Python API functions you can acquire and release the Python GIL as needed. The only rule is that you must hold the Python GIL should you wish to access any part of the Python interpreter (function calls, variables, etc) [note: technically you don't HAVE to, but you run a high risk of data corruption and segfaults from the race conditions which would exist]. Either option should work fine. In case of option 1: 1. Import the C module. 2. The C module sets up some defaults for the render. 3. The C module creates its render thread (which is unaffected by the GIL, but probably needs other locks around global variables). 4. The C module returns to Python. 5. The Python GUI calls into the C module to change settings (which probably need to acquire short-term locks) An alternative would be: 1. Import the C module. 2. The C module setups up some defaults. 3. Create a Python thread to call the C module's render loop. 4. The render loop thread releases the GIL and continues as above. 5. The main Python thread continues as above. For option 2: 1. Initialize any needed variables for the system. 2. Start a new thread for loading and executing Python. 3. Have the main thread start the render loop. 4. Have the Python thread startup up Python. 5. Continue as in the first case above. -- http://mail.python.org/**mailman/listinfo/python-listhttp://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
Re: Newbie OOP Question Code Snippet
On 21 December 2011 19:12, Dean Richardson P.Eng d...@red-spanner.comwrote:
Hi All,
I'm a newbie just learning Python, using a couple of books to learn the
language. (Books: Visual Quickstart Guide - Python, 2nd Ed, Practical
Programming - An Intro to Computer Science using Python). I'm just now
learning OOP material as presented in both books -- I'm new to this
approach -- the last formal language I learned was Fortran77 -- :o) I am
running Python 3.2.1 on Mac OS/X 10.6.8.
My problem stems from a simple example in the Visual Quickstart book. The
code is:
#person.py
class Person:
Class to represent a person
def __init__(self):
self.name=' '
self.age=0
def display(self):
print(Person('%s', age) %
(self.name, self.age))
The % (self.name, self.age) means that two arguments are given in. You
only have one %s in the string (untested, so I may be completely off).
Additionally, use str.format now:
Person({}, {}).format(self.name, self.age)
-
When I run this, the shell presents thus:
RESTART
p=Person()
p.name='Bob'
p.age=24
p.display()
Traceback (most recent call last):
File pyshell#33, line 1, in module
p.display()
File /Volumes/dean_richardson/GoFlex Home Personal/Dean's
Code/Python3.x/Person.py, line 9, in display
(self.name, self.age))
TypeError: not all arguments converted during string formatting
---
I'm sure this is something simple, but I can't see it. Any help
appreciated!
--
http://mail.python.org/mailman/listinfo/python-list
Re: Elementwise -//- first release -//- Element-wise (vectorized) function, method and operator support for iterables in python.
Ian Kelly wrote: my goal is to write clear code, not great one-liners. :-D +1 QOTW -- http://mail.python.org/mailman/listinfo/python-list
Re: Why does this launch an infinite loop of new processes?
Andrew Berg wrote:
I am trying to understand the multiprocessing module, and I tried some
simple code:
import multiprocessing
def f():
print('bla bla')
p = multiprocessing.Process(target=f)
p.start()
p.join()
And the result is a new process that spawns a new process that spawns a
new process ad infinitum until I log out and the OS forcefully
terminates all my user processes. I have no idea what is happening; I
expected it to just print the string and terminate.
Anything that runs at import time should be protected by the `if
__name__ == '__main__'` idiom as the children will import the __main__
module.
8---
import multiprocessing
def f():
print('bla bla')
if __name__ == '__main__':
p = multiprocessing.Process(target=f)
p.start()
p.join()
8---
~Ethan~
--
http://mail.python.org/mailman/listinfo/python-list
Re: Why does this launch an infinite loop of new processes?
On 12/21/2011 1:29 PM, Ethan Furman wrote: Anything that runs at import time should be protected by the `if __name__ == '__main__'` idiom as the children will import the __main__ module. So the child imports the parent and runs the spawn code again? That makes sense. -- CPython 3.2.2 | Windows NT 6.1.7601.17640 | Thunderbird 7.0 -- http://mail.python.org/mailman/listinfo/python-list
Re: [TIP] Anyone still using Python 2.5?
On 2011-12-21T07:15:46+, Chris Withers wrote: Hi All, What's the general consensus on supporting Python 2.5 nowadays? Do people still have to use this in commercial environments or is everyone on 2.6+ nowadays? 2.5, how modern. SUSE Linux Enterprise Server 10 comes with 2.4.2 Will be moving to a RHEL derivative running 2.6, though. The conservative enterprise will probably run py3k by y3k. :-( -- Chris pgpQUloG0TcPC.pgp Description: PGP signature -- http://mail.python.org/mailman/listinfo/python-list
Re: [OT] Quick intro to C++ for a Python and C user?
On 2011-12-21, Neil Cerutti ne...@norwich.edu wrote: On 2011-12-21, Grant Edwards invalid@invalid.invalid wrote: Templates are how C++ does generics and I'd expect them to appear in be used in embedded programming as well as elsewhere. I've only worked on the perphery of a couple embedded projects that used C++, but it seems to be farily common practice to prohibit the use of templates in embedded code. The problem seems to be that people writing C++ code don't really understand the language, how templates work, or (in general) the implications of the code they write. So, you have to prohibit anything that can be easily misused or cause non-obvious problems. I cheerfully agree that programmers ignorant of C++ should not write programs in it. But furthermore, they should also not define a subset of C++ for use in embedded programming. ;) I fully agree that programmers ignorant of C++ should not write programs in it. However C++ is a vast, complex, and dangerous language -- and industry doesn't seem to be willing to limit itself to using the seven people on the planet who understand it. I'm only half joking... :) It seems to me that you need to know far more about C++ to use it safely than you need to know about most other languages to use them safely. -- Grant Edwards grant.b.edwardsYow! Hey, waiter! I want at a NEW SHIRT and a PONY TAIL gmail.comwith lemon sauce! -- http://mail.python.org/mailman/listinfo/python-list
Re: [OT] Quick intro to C++ for a Python and C user?
Grant Edwards wrote: On 2011-12-21, Neil Cerutti ne...@norwich.edu wrote: I cheerfully agree that programmers ignorant of C++ should not write programs in it. But furthermore, they should also not define a subset of C++ for use in embedded programming. ;) I fully agree that programmers ignorant of C++ should not write programs in it. However C++ is a vast, complex, and dangerous language -- and industry doesn't seem to be willing to limit itself to using the seven people on the planet who understand it. I'm only half joking... :) Ah -- so there's actually 14? ;) ~Ethan~ -- http://mail.python.org/mailman/listinfo/python-list
Re: [TIP] Anyone still using Python 2.5?
On Wed, Dec 21, 2011 at 05:57, Jim Fulton j...@zope.com wrote: On Wed, Dec 21, 2011 at 2:15 AM, Chris Withers ch...@simplistix.co.uk wrote: Hi All, What's the general consensus on supporting Python 2.5 nowadays? Do people still have to use this in commercial environments or is everyone on 2.6+ nowadays? I'm finally getting some continuous integration set up for my packages and it's highlighting some 2.5 compatibility issues. I'm wondering whether to fix those (lots of ugly from __future__ import with_statement everywhere) or just to drop Python 2.5 support. What do people feel? Google app engine is still Python 2.5, as is Jython. But App Engine also supports Python 2.7: http://code.google.com/appengine/docs/python/python27/ (currently experimental, but then again App Engine itself was in preview mode until just this past month). -- http://mail.python.org/mailman/listinfo/python-list
Re: Elementwise -//- first release -//- Element-wise (vectorized) function, method and operator support for iterables in python.
On 21/12/11 01:03:26, Ian Kelly wrote: As type conversion functions, bool(x) and int(x) should *always* return bools and ints respectively (or raise an exception), no matter what you pass in for x. That doesn't always happen in 2.x: type(int(1e42)) type 'long' This was fixed in 3.0. -- HansM -- http://mail.python.org/mailman/listinfo/python-list
Re: Need advice on the design of my application
I'd say go with option 1. Pass the window handler (or DC) to the rendered thread. To overcome the GIL problem, you can use Py_BEGIN_ALLOW_THREADS (see http://docs.python.org/release/1.5.2/api/threads.html) -- http://mail.python.org/mailman/listinfo/python-list
Re: Need advice on the design of my application
On Wed, Dec 21, 2011 at 2:10 PM, carlos choy happybrown...@hotmail.comwrote: Thank you for your great advice. It is detailed and tells me what I need to know, I wasn't expecting such an accurate response from anyone for some time. I think Option 2 is the way I will go. Having never embedded before, I think it will be interesting, besides then my IDE can help me debug more easily than Option 1. Either way is a bit of a mixed bag. Going with extending, it will (generally) be harder to debug and test the C side of the code, as it is more difficult to get the C debugger attached. Depending on what IDE you are using (I am most used to Visual Studio 2010), you can probably set it up to execute a Python instance with command-line arguments for automatic attachment. You can also manually attach to the debugger that way. If you go with embedding, you will likely have a harder time debugging the Python side, unless you're very careful in your implementation (which you will need to be anyways) of the embedding. It will also, likely, be harder to actually step into and debug the code (I use Wing, and at work we have it setup to be attachable from any process via 2 lines of code). In either case, it should not be too hard to setup the IDEs to make debugging easy, but either way, you do not really get automatic support for one of the two languages. Note that this is generally a problem anytime you mix multiple languages. -- http://mail.python.org/mailman/listinfo/python-list
what does 'a=b=c=[]' do
Is it true that if I want to create an array or arbitrary size such as: for a in range(n): x.append(some function...) I must do this instead? x=[] for a in range(n): x.append(some function...) Now to my actual question. I need to do the above for multiple arrays (all the same, arbitrary size). So I do this: x=y=z=[] for a in range(n): x.append(some function...) y.append(some other function...) z.append(yet another function...) Except it seems that I didn't create three different arrays, I created one array that goes by three different names (i.e. x[], y[] and z[] all reference the same pile of numbers, no idea which pile). This surprises me, can someone tell me why it shouldn't? I figure if I want to create and initialize three scalars the just do a=b=c=7, for example, so why not extend it to arrays. Also, is there a more pythonic way to do x=[], y=[], z=[]? It's a slick language but I still have trouble wrapping my brain around some of the concepts. TIA, eric -- http://mail.python.org/mailman/listinfo/python-list
Re: what does 'a=b=c=[]' do
On 21 December 2011 22:25, Eric einazaki...@yahoo.com wrote: Is it true that if I want to create an array or arbitrary size such as: for a in range(n): x.append(some function...) I must do this instead? x=[] for a in range(n): x.append(some function...) Now to my actual question. I need to do the above for multiple arrays (all the same, arbitrary size). So I do this: x=y=z=[] for a in range(n): x.append(some function...) y.append(some other function...) z.append(yet another function...) Except it seems that I didn't create three different arrays, I created one array that goes by three different names (i.e. x[], y[] and z[] all reference the same pile of numbers, no idea which pile). This surprises me, can someone tell me why it shouldn't? I figure if I want to create and initialize three scalars the just do a=b=c=7, 7 is 7 = True They're the same 7. You won't notice it though, as numbers are immutable. for example, so why not extend it to arrays. Also, is there a more pythonic way to do x=[], y=[], z=[]? a, b, c = [], [], [] It's a slick language but I still have trouble wrapping my brain around some of the concepts. TIA, eric -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
Re: what does 'a=b=c=[]' do
On Wed, Dec 21, 2011 at 2:25 PM, Eric einazaki...@yahoo.com wrote: Is it true that if I want to create an array or arbitrary size such as: for a in range(n): x.append(some function...) I must do this instead? x=[] for a in range(n): x.append(some function...) You can also use a list comprehension: x = [some function... for a in range(n)] Or extend and a generator expression: x = [] x.extend(some function... for a in range(n)) Or map and a generator function: map(x.append, (some function... for a in range(n))) I would recommend either your way, the first of, or the second of my ways, depending on the full context. Now to my actual question. I need to do the above for multiple arrays (all the same, arbitrary size). So I do this: x=y=z=[] This creates a new object, then assigns the labels x, y, and z to that object. for a in range(n): x.append(some function...) y.append(some other function...) z.append(yet another function...) Then this appends the items to each of those labels, which, as they pointing to the same object, appends to all of the labels. The variables in Python are merely labels, and assigning to different labels does not automatically copy the object. Consider: a = [] b = a a.append(1) print b [1] Except it seems that I didn't create three different arrays, I created one array that goes by three different names (i.e. x[], y[] and z[] all reference the same pile of numbers, no idea which pile). This surprises me, can someone tell me why it shouldn't? I figure if I want to create and initialize three scalars the just do a=b=c=7, for example, so why not extend it to arrays. Also, is there a more pythonic way to do x=[], y=[], z=[]? The above rules apply in all cases, however are generally invisible on immutable objects (strings, ints, floats, tuples). In the case of a=b=c=7, you will find that all of a, b, and c point to the same object (try the id function or is operator). Doing the operation a += 1 after a=7 will create a new int* with the value 7+1 and assign it to the label a. * In CPython, there exists an optimization where small ints are cached, namely from -7 to 255 (the lower bound I stated may be wrong). This improved performance in most cases, but is CPython specific - other implementations such as PyPy or IronPython may behave differently. It's a slick language but I still have trouble wrapping my brain around some of the concepts. TIA, eric -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
Re: what does 'a=b=c=[]' do
On Wed, 21 Dec 2011 14:25:17 -0800, Eric wrote: Is it true that if I want to create an array or arbitrary size such as: for a in range(n): x.append(some function...) x is not defined, so you will get a NameError unless by some lucky fluke something else has created x AND it happens to be a list. Either way, it is unlikely to do what you want. I must do this instead? x=[] for a in range(n): x.append(some function...) Yes, you should create your lists before trying to append to them. But you aren't forced to use a for-loop. You can use a list comprehension: x = [some_function(a) for a in range(n)] Notice that here you don't need x to pre-exist, because the list comp creates a brand new list, which then gets assigned directly to x. Now to my actual question. I need to do the above for multiple arrays (all the same, arbitrary size). So I do this: x=y=z=[] This creates one empty list object, and gives it three names, x, y and z. Every time you append to the list, all three names see the same change, because they refer to a single list. [...] Except it seems that I didn't create three different arrays, I created one array that goes by three different names (i.e. x[], y[] and z[] all reference the same pile of numbers, no idea which pile). Exactly. This surprises me, can someone tell me why it shouldn't? Because that's the way Python works. Python is an object-oriented, name binding language. This is how OO name binding works: you have a single object, with three names bound to it. The above line is short-cut for: a = [] b = a c = a Python does not make a copy of the list unless you specifically instruct it to. I figure if I want to create and initialize three scalars the just do a=b=c=7, That creates a single integer object with value 7, and binds three names to it, *exactly* the same as the above. If you could modify int objects in place, like you can modify lists in place, you would see precisely the same effect. But ints are immutable: all operations on ints create new ints. Lists are mutable, and can be changed in place. for example, so why not extend it to arrays. Also, is there a more pythonic way to do x=[], y=[], z=[]? Well that literally won't work, you can't separate them by commas. Newlines or semicolons will work. Or: x, y, z = [], [], [] Either is pretty Pythonic. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: what does 'a=b=c=[]' do
On Wed, 21 Dec 2011 18:20:16 -0500, Dennis Lee Bieber wrote: For the amount of typing, it's easier to just do a straight line tuple unpack a,b,c = ([],[],[]) Note that tuples are created by the comma, not the round brackets (or parentheses for any Americans reading). So the round brackets there are strictly redundant: a, b, c = [], [], [] The only times you need the brackets around a tuple is to control the precedence of operations, or for an empty tuple. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: what does 'a=b=c=[]' do
On Dec 22, 8:25 am, Eric einazaki...@yahoo.com wrote:
This surprises me, can someone tell me why it shouldn't? I figure if
I want to create and initialize three scalars the just do a=b=c=7,
for example, so why not extend it to arrays.
The thing to remember is that everything is an object, and that it's
better to think of variables as labels on an object.
So: a=b=c=7 means that _one_ integer object with the value of 7 can be
referenced using any of the labels a, b or c. x=y=z=[] means that
_one_ empty list can be referenced using x, y or z.
The difference is that the value of a number object _cannot be
changed_ ('immutable') while a list can be modified to add or remove
items ('mutable'). a=10 just reassigns the label a to an integer
object of value 10. x.append(foo) _modifies_ the list referred to by
x, which is the same list known as y z.
Also, is there a more pythonic way to do x=[], y=[], z=[]?
I'd say that _is_ the most pythonic way, it's very obvious in its
intent (or would be with appropriate names). If it bothers you that
much:
def listgen(count, default=[]):
for _ in xrange(count):
yield default[:]
x, y, z = listgen(3)
--
http://mail.python.org/mailman/listinfo/python-list
Re: [OT] Quick intro to C++ for a Python and C user?
In article jcthh3$8vd$1...@reader1.panix.com, Grant Edwards invalid@invalid.invalid wrote: C++ is a vast, complex, and dangerous language -- and industry doesn't seem to be willing to limit itself to using the seven people on the planet who understand it. I'm only half joking... :) Half joking, indeed. I happen to know for a fact that there are *fourteen* people on the planet who understand it. -- http://mail.python.org/mailman/listinfo/python-list
Re: [TIP] Anyone still using Python 2.5?
On Wed, Dec 21, 2011 at 2:57 AM, Jim Fulton j...@zope.com wrote: On Wed, Dec 21, 2011 at 2:15 AM, Chris Withers ch...@simplistix.co.uk wrote: Hi All, What's the general consensus on supporting Python 2.5 nowadays? Do people still have to use this in commercial environments or is everyone on 2.6+ nowadays? I'm finally getting some continuous integration set up for my packages and it's highlighting some 2.5 compatibility issues. I'm wondering whether to fix those (lots of ugly from __future__ import with_statement everywhere) or just to drop Python 2.5 support. What do people feel? Google app engine is still Python 2.5, as is Jython. There's work being done to change that on the app engine front: http://code.google.com/appengine/docs/python/python27/newin27.html -gps -- http://mail.python.org/mailman/listinfo/python-list
Re: [TIP] Anyone still using Python 2.5?
Just because the default python version on a server is 2.4 doesn't mean you can't install 2.7.2... If the admins that run the machine are too lazy/stupid to install a second copy of Python let them rot. Of course, if by some nightmare scenario you have code that can't be upgraded for whatever reason, I'm so sorry. Nathan -- http://mail.python.org/mailman/listinfo/python-list
Re: Why widgets become 'NoneType'?
On Dec 21, 6:59 am, Muddy Coder cosmo_gene...@yahoo.com wrote: Hi Folks, I was driven nuts by this thing: widgets lost their attributes, then I can't configure them. Please take a look at the codes below: The problem is here... labels = [] for i in range(len(astr)): lbl = Label(win, text=astr[i]).pack(side=LEFT ) label.pack() returns None. So you are creating a variable named lbl the value of which is None. Don't believe me? Try this... from Tkinter import * root = Tk() label = Label(root).pack() label['bg'] Traceback (most recent call last): File pyshell#12, line 1, in module label['bg'] TypeError: 'NoneType' object is not subscriptable type(label) type 'NoneType' # # Now we separate the packing from the instancing. # label = Label(root) label.pack() type(label) type 'instance' label['bg'] 'SystemButtonFace' Same with list.sort. lst = range(5) lst [0, 1, 2, 3, 4] var = lst.sort() repr(var) 'None' -- http://mail.python.org/mailman/listinfo/python-list
Re: [TIP] Anyone still using Python 2.5?
On Wed, 21 Dec 2011 21:15:31 -0500, Nathan Rice wrote: Just because the default python version on a server is 2.4 doesn't mean you can't install 2.7.2... If the admins that run the machine are too lazy/stupid to install a second copy of Python let them rot. If any of my sys admins installed non-supported software on one of my production servers without permission, they'd be looking for a new job. Just because some guy with root privileges can install software doesn't mean that he should. Having vendor support and security patches is far more important than the ability to write one-liner if statements. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Generator Question
Hi, I am wondering what would be the best way to return an iterator that has zero items. I just noticed the following two are different: def f(): pass def g(): if 0: yield 0 pass for x in f(): print x Traceback (most recent call last): File string, line 1, in fragment TypeError: 'NoneType' object is not iterable for x in g(): print x #loop exits without any errors Now the question here is this: def h(): if condition=true: #I would like to return an itereator with zero length else: for ...: yield x In other words, when certain condition is met, I want to yield nothing. How to do? Thanks, gz -- http://mail.python.org/mailman/listinfo/python-list
Re: Generator Question
On Wed, 21 Dec 2011 21:45:13 -0800, GZ wrote: Hi, I am wondering what would be the best way to return an iterator that has zero items. return iter([]) I just noticed the following two are different: def f(): pass That creates a function that does nothing, and then returns None (because Python doesn't have Pascal procedures or C void function). def g(): if 0: yield 0 pass The pass is redundant. This creates a generator function which, when called, doesn't yield anything, then raises StopIteration. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Generator Question
On Thu, Dec 22, 2011 at 4:45 PM, GZ zyzhu2...@gmail.com wrote: def h(): if condition=true: #I would like to return an itereator with zero length else: for ...: yield x Easy. Just 'return' in the conditional. def h(): if condition: return for i in range(4): yield i condition=False h() generator object h at 0x01913E68 for i in h(): print(i) 0 1 2 3 condition=True h() generator object h at 0x01079E40 for i in h(): print(i) A generator object is returned since the function contains a 'yield'. On one of the branches, nothing will ever be yielded and StopIteration will be raised immediately. You could probably also raise StopIteration directly, but it's not necessary. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Generator Question
On Wed, 21 Dec 2011 21:45:13 -0800, GZ wrote: Now the question here is this: def h(): if condition=true: #I would like to return an itereator with zero length else: for ...: yield x In other words, when certain condition is met, I want to yield nothing. How to do? Actually, there's an even easier way. def h(): ... if not condition: ... for c in abc: ... yield c ... condition = False list(h()) ['a', 'b', 'c'] condition = True list(h()) [] -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Anyone still using Python 2.5?
Dennis Lee Bieber, 21.12.2011 17:48: On Wed, 21 Dec 2011 07:15:46 +, Chris Withers wrote: What's the general consensus on supporting Python 2.5 nowadays? Do people still have to use this in commercial environments or is everyone on 2.6+ nowadays? I was recently laid-off from a program that is still using Python 2.3 [...] That reminds me: we shouldn't forget about embedded Python installations. They are usually somewhere between very hard and impossible to upgrade, also because they often use vendor supplied binary packages for plugin APIs. I've recently seen that in a FrontArena installation (basically a trading platform) that had an embedded Py2.3 for scripting. It wasn't exactly the cutting-edge release, but the users of these platforms tend to be pretty conservative with their upgrades, and the time it takes the vendor to upgrade to a new embedded Python version can be similarly long. That means it can take several years before an embedded 2.7 hits the end users, during which anything can happen, from vendor switches from Python to Lua to vendor goes bankrupt (or maybe just one after the other). Stefan -- http://mail.python.org/mailman/listinfo/python-list
[issue13643] 'ascii' is a bad filesystem default encoding
Changes by vila v.ladeuil+bugs-pyt...@free.fr: -- nosy: +vila ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13643 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13627] Python SSL stack doesn't support Elliptic Curve ciphers
Antoine Pitrou pit...@free.fr added the comment: Can you post the exact compiler errors you encountered? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13627 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13627] Python SSL stack doesn't support Elliptic Curve ciphers
Antoine Pitrou pit...@free.fr added the comment: Nevermind, I've found them on the Fedora buildbot. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13627 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13627] Python SSL stack doesn't support Elliptic Curve ciphers
Roundup Robot devn...@psf.upfronthosting.co.za added the comment: New changeset ec44f2e82707 by Antoine Pitrou in branch 'default': Fix ssl module compilation if ECDH support was disabled in the OpenSSL build. http://hg.python.org/cpython/rev/ec44f2e82707 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13627 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13627] Python SSL stack doesn't support Elliptic Curve ciphers
Antoine Pitrou pit...@free.fr added the comment: Since we're at it, do you know if Redhat also disables regular Diffie-Hellman? See issue13626. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13627 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13627] Python SSL stack doesn't support Elliptic Curve ciphers
Antoine Pitrou pit...@free.fr added the comment: ec44f2e82707 fixed compilation on Fedora and test_ssl passed fine. -- status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13627 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13581] help() appears to be broken; doesn't display __doc__ for class type when called as help(type)
Roundup Robot devn...@psf.upfronthosting.co.za added the comment: New changeset 902f694a7b0e by Antoine Pitrou in branch '3.2': Issue #1785: Fix inspect and pydoc with misbehaving descriptors. http://hg.python.org/cpython/rev/902f694a7b0e New changeset b08bf8df8eec by Antoine Pitrou in branch 'default': Issue #1785: Fix inspect and pydoc with misbehaving descriptors. http://hg.python.org/cpython/rev/b08bf8df8eec -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13581 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1785] inspect gets broken by some descriptors
Roundup Robot devn...@psf.upfronthosting.co.za added the comment: New changeset 902f694a7b0e by Antoine Pitrou in branch '3.2': Issue #1785: Fix inspect and pydoc with misbehaving descriptors. http://hg.python.org/cpython/rev/902f694a7b0e New changeset b08bf8df8eec by Antoine Pitrou in branch 'default': Issue #1785: Fix inspect and pydoc with misbehaving descriptors. http://hg.python.org/cpython/rev/b08bf8df8eec -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1785 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11638] python setup.py sdist --formats tar* crashes if version is unicode
Lars Gustäbel l...@gustaebel.de added the comment: Is there a good reason why the tarfile mode that is used is w|gz? It seems to me that this is not necessary, w:gz should be enough. w|gz is for special operations only (see the tarfile docs). -- nosy: +lars.gustaebel Added file: http://bugs.python.org/file24065/distutils_tarfile_fix.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11638 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1785] inspect gets broken by some descriptors
Roundup Robot devn...@psf.upfronthosting.co.za added the comment: New changeset 13f56cd8dec1 by Antoine Pitrou in branch '2.7': Issue #1785: Fix inspect and pydoc with misbehaving descriptors. http://hg.python.org/cpython/rev/13f56cd8dec1 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1785 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13581] help() appears to be broken; doesn't display __doc__ for class type when called as help(type)
Roundup Robot devn...@psf.upfronthosting.co.za added the comment: New changeset 13f56cd8dec1 by Antoine Pitrou in branch '2.7': Issue #1785: Fix inspect and pydoc with misbehaving descriptors. http://hg.python.org/cpython/rev/13f56cd8dec1 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13581 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
