Announce: LDTP 3.0 - Linux GUI test automation tool
Hello, Highlights: * Java / C# / VB.NET http://vb.net/ / PowerShell / Ruby are now officially supported LDTP scripting languages other than Python New Features: * Firefox have check / uncheck as actions for check box New APIs: * selectpanel * selectpanelname * selectpanelindex Bug fix: * Simplified the implementation verifyselect for combobox menuitem * Fix QT related accessibility issue * Bug#673931 - Python-ldtp has issues if the application calls an env or other program to run Credit: * Ubuntu QA team members (Dave Morley, Ara Pulido) * VMware desktop QA team members * Kartik Mistry (Debian package maintainer) * Thanks to all others who have reported bugs through forum / email / in-person / IRC About LDTP: Cross Platform GUI Automation tool Linux version is LDTP, Windows version is Cobra and Mac version is PyATOM (Work in progress). * Linux version is known to work on GNOME / KDE (QT = 4.8) / Java Swing / LibreOffice / Mozilla application on all major Linux distribution. * Windows version is known to work on application written in .NET / C++ / Java / QT on Windows XP SP3 / Windows 7 / Windows 8 development version. * Mac version is currently under development and verified only on OS X Lion. Where ever PyATOM runs, LDTP should work on it. Download source: https://github.com/ldtp/ldtp2 Download binary (RPM / DEB): http://download.opensuse.org/repositories/home:/anagappan:/ldtp2:/ Documentation references: For detailed information on LDTP framework and latest updates visit http://ldtp.freedesktop.org For information on various APIs in LDTP including those added for this release can be got from http://ldtp.freedesktop.org/user-doc/index.html Java doc - http://ldtp.freedesktop.org/javadoc/ Report bugs - http://ldtp.freedesktop.org/wiki/Bugs To subscribe to LDTP mailing lists, visit http://ldtp.freedesktop.org/wiki/Mailing_20list IRC Channel - #ldtp on irc.freenode.net Thanks Nagappan -- Linux Desktop (GUI Application) Testing Project - http://ldtp.freedesktop.org Cobra - Windows GUI Automation tool - https://github.com/ldtp/cobra http://nagappanal.blogspot.com -- http://mail.python.org/mailman/listinfo/python-announce-list Support the Python Software Foundation: http://www.python.org/psf/donations/
PythonOnWheels (PoW)
Hi, I am announcing PythonOnWheels. (short PoW) Projectname: PythonOnWheels Motto: We are only on wheels but it feels like having wings ;) A quick and easy to use generative Web framework for python. STOP: I know what you are thinking: What the world doen't need are more lawyers and python web frameworks And you are right. But I am announcing this mostly to get feedback from the community. Any feedback is welcome. Some years ago I saw a screencast about ruby on rails and that really blew my mind. I Searched something equivalant for python but found only micro or mega frameworks. So I think there is even some space for PoW. Besides the fun I had and have developing it ;) The idea is to make the developer focus on his/her App instead of the framework. List of Features (not complete) - * Model View Controller * Uses the well proven Ruby On Rails principles ** convention over configuration ** generate_model, generate_controller, generate_migration * Scaffolding dabei ** generate_scaffold * JQuery integration * AJAX * Responsive Layout based on Twitter Bootstrap * Lightweight - simple and easy to use * Nose Tests * automatically generate for you. runtest script to run them * Database Migrations * web app generation with batteries included: ** Session support ** basic authentication (Beta 2) * Runs with Apache mod_wsgi * includes a ready to run simple_server * full environment on your laptop, mac or pc Coming for Beta 1: - * Observer pattern * Validation (as a plugin) Screencast: - Weblog with PythonOnWheels in 10 minutes. - http://bit.ly/QAmoxX Homepage: -- http://www.pythononwheels.org Get it on Github: -- https://github.com/pythononwheels/pow_devel/tree/beta1 (Be sure to take the beta1 branch (as of 03.08.20120)) Prerequsites: I did not reinvent the wheel but rely on the brilliant and proven standards out there so PoW (and you) will need: webob (pip or easy_install) Mako (pip or easy_install) Beaker (pip or easy_install) SQLAlchemy (pip or easy_install) nose (pip or easy_install) So, that's all folks ;) I am really appreciating any feedback. reply to this or email to k...@pythononwheels.org. best regards, Klaas -- http://mail.python.org/mailman/listinfo/python-announce-list Support the Python Software Foundation: http://www.python.org/psf/donations/
On-topic: alternate Python implementations
Most people are aware, if only vaguely, of the big Four Python implementations: CPython, or just Python, the reference implementation written in C. IronPython, written in .NET. Jython, written in Java. PyPy, the optimizing implementation written in Python (actually, it's written in a subset of Python, RPython). But the Python ecosystem is a lot bigger than just those four. Here are just a few other implementations that you might be interested in: Stackless - the forgetten Python, Stackless is, I believe, the oldest implementation behind only CPython itself. It's a fork of CPython with the calling stack removed and fast and lightweight microthreads, and is used extensively in EVE Online. http://www.stackless.com/ Nuitka - optimising Python compiler written in C++, supports Python 2.6 and 2.7, claims to be up to twice as fast as CPython. http://nuitka.net/pages/overview.html WPython - another optimizing version of Python with wordcodes instead of bytecodes. http://code.google.com/p/wpython/ CLPython, an implementation of Python written in Common Lisp. http://common-lisp.net/project/clpython/ CapPython is an experimental restricted version of Python with capabilities. http://plash.beasts.org/wiki/CapPython http://en.wikipedia.org/wiki/Object-capability_model Berp - a compiler which works by translating Python to Haskell and compiling that. https://github.com/bjpop/berp/wiki Give them some love! -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: On-topic: alternate Python implementations
On Sat, Aug 4, 2012 at 4:15 PM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: CLPython, an implementation of Python written in Common Lisp. Berp - a compiler which works by translating Python to Haskell and compiling that. Okay. WHY? CLPython gives some reason, but how often do you need to bridge that particular pair of languages? And why compile Python via Haskell, when C is available as a high level assembly language? The mind boggles... ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: On-topic: alternate Python implementations
Steven D'Aprano, 04.08.2012 08:15: Most people are aware, if only vaguely, of the big Four Python implementations: CPython, or just Python, the reference implementation written in C. IronPython, written in .NET. Jython, written in Java. PyPy, the optimizing implementation written in Python (actually, it's written in a subset of Python, RPython). But the Python ecosystem is a lot bigger than just those four. Here are just a few other implementations that you might be interested in: Stackless - the forgetten Python, Stackless is, I believe, the oldest implementation behind only CPython itself. It's a fork of CPython with the calling stack removed and fast and lightweight microthreads, and is used extensively in EVE Online. http://www.stackless.com/ Nuitka - optimising Python compiler written in C++, supports Python 2.6 and 2.7, claims to be up to twice as fast as CPython. http://nuitka.net/pages/overview.html WPython - another optimizing version of Python with wordcodes instead of bytecodes. http://code.google.com/p/wpython/ CLPython, an implementation of Python written in Common Lisp. http://common-lisp.net/project/clpython/ CapPython is an experimental restricted version of Python with capabilities. http://plash.beasts.org/wiki/CapPython http://en.wikipedia.org/wiki/Object-capability_model Berp - a compiler which works by translating Python to Haskell and compiling that. https://github.com/bjpop/berp/wiki And not to forget Cython, which is the only static Python compiler that is widely used. Compiles and optimises Python to C code that uses the CPython runtime and allows for easy manual optimisations to get C-like performance out of it. http://cython.org/ Stefan -- http://mail.python.org/mailman/listinfo/python-list
Re: Eclipse and the Python plugin
On 04/08/12 00:29, Cousin Stanley wrote: lipska the kat wrote: I can now create, debug and test a simple IRC server written in Java and an IRC Bot that I am attempting to build in Python For a bit of inspiration python-irc-bot-wise you might look at supybot Yep, it's there (here). Thanks for the heads up lipska -- Lipska the Kat: Troll hunter, sandbox destroyer and farscape dreamer of Aeryn Sun -- http://mail.python.org/mailman/listinfo/python-list
Re: On-topic: alternate Python implementations
On Sat, 04 Aug 2012 08:40:16 +0200, Stefan Behnel wrote: And not to forget Cython, which is the only static Python compiler that is widely used. Compiles and optimises Python to C code that uses the CPython runtime and allows for easy manual optimisations to get C-like performance out of it. http://cython.org/ Cython is great, but I question that it is a *Python* implementation. That's not a criticism of Cython, but it is different from Python. Take this example code from the tutorial: from libc.math cimport sin cdef double f(double x): return sin(x*x) If that's Python code, then I'm Ethel the Aardvark. Cython is very Python-like, but there is no doubt in my mind that it is a superset of Python and therefore a different language. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: python pynotify with textbox input
On 03/08/2012 23:50, dark.k...@gmail.com wrote: how can i made a notification for gnome-shell with a textbox input ?? library: pynotify? Write some code and when you get problems with it post the code here and we'll gladly answer your questions. -- Cheers. Mark Lawrence. -- http://mail.python.org/mailman/listinfo/python-list
Re: On-topic: alternate Python implementations
Steven D'Aprano, 04.08.2012 09:49: On Sat, 04 Aug 2012 08:40:16 +0200, Stefan Behnel wrote: And not to forget Cython, which is the only static Python compiler that is widely used. Compiles and optimises Python to C code that uses the CPython runtime and allows for easy manual optimisations to get C-like performance out of it. http://cython.org/ Cython is great, but I question that it is a *Python* implementation. That's not a criticism of Cython, but it is different from Python. Take this example code from the tutorial: from libc.math cimport sin cdef double f(double x): return sin(x*x) If that's Python code, then I'm Ethel the Aardvark. We never met in person, so I can't comment on the last part. However, the above is Cython code and, yes, that's a different language. Note that it uses a different file extension: .pyx. Try putting the above code into a .py file and compiling that. Cython will reject it and tell you that cimport is not valid Python syntax. Cython is very Python-like, but there is no doubt in my mind that it is a superset of Python and therefore a different language. As long as you don't use any features of the Cython language, it's plain Python. That makes it a Python compiler in my eyes. The fact that you can easily use C features to optimise your code (also in Python syntax, BTW) doesn't impact that. You mentioned a couple of other implementations and I'm sure they have features (and bugs) that CPython doesn't have. Interaction with Lisp code in CLPython, for example. I don't think additional features or language implementation bugs make a Python implementation non-Python per se. Also note that most of the less widely known alternative Python implementations do not even publish their results of running the CPython test suite, so how do you actually know they can run Python code? Stefan -- http://mail.python.org/mailman/listinfo/python-list
Re: On-topic: alternate Python implementations
On 04/08/2012 08:49, Steven D'Aprano wrote: On Sat, 04 Aug 2012 08:40:16 +0200, Stefan Behnel wrote: And not to forget Cython, which is the only static Python compiler that is widely used. Compiles and optimises Python to C code that uses the CPython runtime and allows for easy manual optimisations to get C-like performance out of it. http://cython.org/ Cython is great, but I question that it is a *Python* implementation. That's not a criticism of Cython, but it is different from Python. Take this example code from the tutorial: from libc.math cimport sin cdef double f(double x): return sin(x*x) If that's Python code, then I'm Ethel the Aardvark. Cython is very Python-like, but there is no doubt in my mind that it is a superset of Python and therefore a different language. I agree so it's off topic and can't be discussed here. Isn't that right, Stefan? -- Cheers. Mark Lawrence. -- http://mail.python.org/mailman/listinfo/python-list
Re: On-topic: alternate Python implementations
On Sat, 04 Aug 2012 16:34:17 +1000, Chris Angelico wrote: On Sat, Aug 4, 2012 at 4:15 PM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: CLPython, an implementation of Python written in Common Lisp. Berp - a compiler which works by translating Python to Haskell and compiling that. Okay. WHY? CLPython gives some reason, but how often do you need to bridge that particular pair of languages? And why compile Python via Haskell, when C is available as a high level assembly language? For much the same reason that PyPy uses RPython when C is available. Because Haskell is available as a high level non-assembly language. Berp is based on the Glasgow Haskell Compiler, which is a modern, efficient, optimizing compiler capable of producing excellent quality machine code on Windows, Mac, Linux and many Unixes. It gives you all the advantages of a high-level language with high-level data structures, type inference, and a compiler capable of generating optimized, fast, machine code. Who would want to deal with C's idiosyncrasies, low-powered explicit type system, difficult syntax, and core-dumps, when you could use something better? Apart from C programmers, of course. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: On-topic: alternate Python implementations
Mark Lawrence, 04.08.2012 12:05: I agree so it's off topic and can't be discussed here. Isn't that right, Stefan? Hmm, in case you are referring to a recent friendly and diplomatic request of mine regarding a couple of people who were burdening a public high volume mailing list with a purely private back-and-forth chat about having beer and getting drunk - then, no, I don't think the discussion in this thread qualifies as yet another example for that so far. Stefan -- http://mail.python.org/mailman/listinfo/python-list
Re: On-topic: alternate Python implementations
Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: Who would want to deal with C's idiosyncrasies, low-powered explicit type system, difficult syntax, and core-dumps, when you could use something better? In the free software world, apparently many people like C. C is also quite popular in the zero-fault software world: Several verification tools do exist and Leroy et al. are writing a certified compiler for C to plug the hole between the verified source code and the generated assembly. Stefan Krah -- http://mail.python.org/mailman/listinfo/python-list
Re: On-topic: alternate Python implementations
Steven D'Aprano, 04.08.2012 12:54: Berp is based on the Glasgow Haskell Compiler, which is a modern, efficient, optimizing compiler capable of producing excellent quality machine code on Windows, Mac, Linux and many Unixes. It gives you all the advantages of a high-level language with high-level data structures, type inference, and a compiler capable of generating optimized, fast, machine code. Although all those optimisations don't mean that Python code would run fast on top of it. Just because you translate Python to another language and platform doesn't mean that there's any benefit from the underlying platform optimisations. Both PyPy and Cython run Python code faster than CPython, but not because they eventually translate it into machine code but because they optimise and specialise it along the way, based on its high-level code constructs. One big success of the Unladen Swallow project was to show that bare JIT compilation is mostly worthless for high level languages. Who would want to deal with C's idiosyncrasies, low-powered explicit type system, difficult syntax, and core-dumps, when you could use something better? The core developers of both CPython and Cython aim for exactly that. They write C so you don't have to. But keep in mind that C is still *the* lingua franca of software development. A major reason why Python is (slowly) catching up these days is that the main implementation is written in C and makes it easy to interface with C code. Stefan -- http://mail.python.org/mailman/listinfo/python-list
Re: On-topic: alternate Python implementations
Am 04.08.2012 11:10 schrieb Stefan Behnel: As long as you don't use any features of the Cython language, it's plain Python. That makes it a Python compiler in my eyes. Tell that the C++ guys. C++ is mainly a superset of C. But nevertheless, C and C++ are distinct languages and so are Python and Cython. Thomas -- http://mail.python.org/mailman/listinfo/python-list
Re: On-topic: alternate Python implementations
The first time I did reply not 'reply all', so I'm posting again. ;-) I think Cython is a Python implementation because you can only use the Python features, not the extra features. C++ is different because of the different rules (C was in a time of assembly and costly computers, C++ was made in the time of (relatively) cheaper computers and computers doing more things) On 4 August 2012 18:21, Thomas Rachel nutznetz-0c1b6768-bfa9-48d5-a470-7603bd3aa...@spamschutz.glglgl.de wrote: Am 04.08.2012 11:10 schrieb Stefan Behnel: As long as you don't use any features of the Cython language, it's plain Python. That makes it a Python compiler in my eyes. Tell that the C++ guys. C++ is mainly a superset of C. But nevertheless, C and C++ are distinct languages and so are Python and Cython. Thomas -- http://mail.python.org/**mailman/listinfo/python-listhttp://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
Re: avlhqw avlhqeavlhqino ovfqalmw avlhqei avlhqeaivscunqw
Is this spam?
If not, can you please explain the message better (I don't get it)
and *Please* change the title, it look like spam.
On 3 August 2012 21:58, Martin Michael Musatov musatovatattdot...@gmail.com
wrote:
Thanks to technology, a memorandum of understanding (thanks from Tel
Aviva / s, F `u / n (I [I TO rotate HM), and try to think, nature is
E | .. (no offense to kiloton preparation. .. has C, E (Visor / s
Chest on Tuesday Kin \ 2 I auto. Hi Lasso, Wilson vest / Na` martin /
NH MW `. brought / \ n VIEW goals WT / NH, RAN, not (I all, or [that
load / Samoa ...) I think the WT DR 3 Μάη | . gown or some [even
in auto Cayman S (j eventual auto Arabia will not bar / threw / a) L
4 Oh, BAG, Gen auto, n (oil. raj Anatole’s auto / threw HM / s (Tao,
she vest (EDA Kai May that | Hall and hold LEIA ovum .. \ 5] 505 A
thru / |? auto / ton, John (avlhqw / DVDs eggs MAY Tues | H, the pH of
WAIT May / U / Eyelet) EN May two | gown or some [aunt EN his / | even
\ LO 6` EN aunt BAG / | .. I over Ni (Kama’s evoke / NO perinea, U
(and auto [Peripatetic To /) 7 Adelaide (n ovum Ventolin.n akin
graphite, F I '/ S (all Ventolin.n Palau an (10] not PULL arch / s \
from H vesting Vent Olin not clear, Greek] is Zhukov PULL arch / d)
eight times a year, Lin Ventolin.n akin No Thanks, I `F u / n (or
[vesting avlhqe.j EN aunt / | .. (EDA Mr. Kai N / A \ [paragraph` t
Scottie (oil. F / 500 .. for avlhqino NH, N DH SIP) Get 9 or 50, BAG
EN WT / ... | wit Chennai is = (oil. ton Adolfo.n auto / miss / s (EN
and / | Scottie |. vest to [WK with RS) agape or 10 / n ton Adolfo
auto n / EDA (VA / |. wit I (EDA Yolanda aunt Kai Ski / | ovum
resist ...) The 11-misw / s ton Adolfo.n auto / (EN and / |. of
Scottie | vest (EN and Kai / |. Scottie, |. reputation / (1000 = ovum
want and / u-PA Gay (or [`t Scottie in veto, flues you’d goalmouth
auto / s) 12 degrees , F U / (technical., 1 (or [I AVE, entail I` u /
n Martin, all comments. what auto .. N / A 13 °), F U I / O (open, RE
( or [cover even. PULL arch n / graphite), F MIL `U / N (, SK spin (or
[enrich coverage ton poncho, B) from 14 degrees, F u / n (payment (or
[I even , violation of ton, CA), Ms. Gray MIL / V (e, RE (or [even.
PULL arch n / d) and covering gray / 500 (rotation of the earth (or [I
chiaroscuro, vest (Okay., May Beautiful / U / u `EN MIL / n, the game
will cover (.. Kai does not enrich poncho n .. n), BR 15 agape / O.
MADE EN dispute a / VA |. SEW PM | ) Eva agape / | ton difference
(ovum times are eggs, the pH can parent / EN aunt J / |. \ 16 or [/ n,
EN VA / |. KB, SEW | (MK pique / and Nark. CK (b pique-Kai, has / the
ovfqalmw N / S (H Kai emblazon organic unity / straight (and keep ..
ovum EVE, May / June protection. all SAP or requests vest Additional
Protocol to the Agreement), I 17 He was not, smog parameters, Get
(oil. pique` H, E and auto / \ O `poi / s .. May LAMA / U / read evil
ton avid / N) 18 (escape, O [ RA vest (oil. Kama’s Zhukov, and sat
down, or [O `ante, God. retail (Shoat. / ante there, students Ego
Crista, however, and \ or R [N and gown or some [escape you [PR vest,
n), '19 VEX MW / n vex / lion (San all ovum VEX H = H ', w / w \ AV
garb San VEX = b, w / w (moment, An Keenan me B MW / n \ all I [/ Na
fawner or sin [e-IT ovum ease net VEX-In. MW / N) 20, I / cry / of
ADM. whales ... digestive ALPO Director / ovum `, (O Kai, gave
permission, s) and -21 000 Gray `u / n (or [O ovum given than all,
wean (all or O [which aunt, N (or Kai. [PA-IT / Tao n / EVE and
avlhqei M / d, and AGE tablespoons ovum). March 22 vesting of Tao, she
(IV US memo avenue # in Visor [u / ovum, hold, or God, or S *, where
he was the Messiah ante vesting (avenue, memo ton GS, I think. HO N)
23 AP / avenue onion. memo is ovule. ton food and energy \ 'O' or
'swimming mellow / s. No, I think. ton food, and RA, ICE) 24 B / ovum
J] Zhukov, PULL is arch / s or EN / N, I, you) even miles EN` u / n,
New Hampshire | no] PULL arch / d Zhukov ('You / I EN WT / | .. HO
`w / |. EN Kai WT / | .. Heritage Manor / h) 25, I think [Stevie. NH
Evangelic P.D., Ah] and' I. hip hungers auto barn / (no, a thousand
degrees avid help when. N) 26 t / h is the salary my gray / WT / n
plan, known Sat K / day) I think 27 - true / cry / or MA] VELA , Beta
PULL ... auto / EN mail `u / n, we have (CRED VIEW and, and ... [the
color of nature, SH |. children` s / \ Tao salary / M (BRED `Kai caw.
I . C `Q Dale all auto MA / color is finally Skein /, known (oil.
avlhqe, vest (Kai ovum and cry / day (Tourism / DR aunt / |.) 28, I
think now / is not (technically, ( EDA that Nate aunt / |. \ I [or
Narcotics Anonymous [Only fawner / | E Miscellaneous / parish space
(oil. aivscunqw / male PULL auto / (EN and / |. Peruse, | auto /) 29
even avid or and / [u, Kayo, vest (gown, Barker, or [AP / 50 poi / s
than Dionysus, NAN (VEX. auto / Gage, Naphtali) M a r t i n M u s a
t o v 8 1 8 4 3 0 4 5 8 6 S M S m u s a t o v a t a t t d o t n
Re: On-topic: alternate Python implementations
Thomas Rachel, 04.08.2012 14:51: Am 04.08.2012 11:10 schrieb Stefan Behnel: As long as you don't use any features of the Cython language, it's plain Python. That makes it a Python compiler in my eyes. Tell that the C++ guys. C++ is mainly a superset of C. But nevertheless, C and C++ are distinct languages and so are Python and Cython. So, if a C++ compiler takes a .c file and compiles it with C language semantics, it doesn't qualify as a C compiler? That implies a rather weird definition of a C compiler, I'd say. Stefan -- http://mail.python.org/mailman/listinfo/python-list
Re: On-topic: alternate Python implementations
Stefan Behnel, 04.08.2012 15:53: Thomas Rachel, 04.08.2012 14:51: Am 04.08.2012 11:10 schrieb Stefan Behnel: As long as you don't use any features of the Cython language, it's plain Python. That makes it a Python compiler in my eyes. Tell that the C++ guys. C++ is mainly a superset of C. But nevertheless, C and C++ are distinct languages and so are Python and Cython. So, if a C++ compiler takes a .c file and compiles it with C language semantics, it doesn't qualify as a C compiler? That implies a rather weird definition of a C compiler, I'd say. Ah, sorry. Got it. You were again talking about Cython the language. Sure, Cython the language is different from Python the language. Cython the compiler can compile both. Stefan -- http://mail.python.org/mailman/listinfo/python-list
Re: trouble with pyplot in os x
On Aug 3, 2012, at 11:12 PM, Eric einazaki...@yahoo.com wrote: I'm just starting to futz around with matplotlib and I tried to run this example from the matplotlib doc page (it's the imshow() example): import numpy as np import matplotlib.cm as cm import matplotlib.mlab as mlab import matplotlib.pyplot as plt delta = 0.025 x = y = np.arange(-3.0, 3.0, delta) X, Y = np.meshgrid(x, y) Z1 = mlab.bivariate_normal(X, Y, 1.0, 1.0, 0.0, 0.0) Z2 = mlab.bivariate_normal(X, Y, 1.5, 0.5, 1, 1) Z = Z2-Z1 # difference of Gaussians im = plt.imshow(Z, interpolation='bilinear', cmap=cm.gray, origin='lower', extent=[-3,3,-3,3]) plt.show() OK I get the following error: Exception in Tkinter callback Traceback (most recent call last): File /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-tk/Tkinter.py, line 1410, in __call__ return self.func(*args) File /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/matplotlib/backends/backend_tkagg.py, line 248, in resize self.show() File /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/matplotlib/backends/backend_tkagg.py, line 252, in draw tkagg.blit(self._tkphoto, self.renderer._renderer, colormode=2) File /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/matplotlib/backends/tkagg.py, line 19, in blit tk.call(PyAggImagePhoto, photoimage, id(aggimage), colormode, id(bbox_array)) TclError This looks as though you are running the latest python from python.org, not the pre-installed python from Apple (that's good). I'm using Python 2.7.3 on OS X 10.6.8 and I'm invoking python by doing arch -i386 python because matplotlib doesn't do 64-bit. Has anyone else seen this? Does anyone know why this is happening? It looks like a problem with tkinter but beyond that I haven't a clue. And, finally, any ideas as to how to make it behave? I DON'T know how tk is getting mixed into this, it shouldn't be. But I think I can tell you how to get matplotlib working... Matplotlib DOES do 64-bit, the problem is numpy, which as you download in binary form does not. But, if you copy the bash script here: https://raw.github.com/fonnesbeck/ScipySuperpack/master/install_superpack.sh it will download the sources and build a 64-bit numpy, which will then give you a default 64-bit full package of python, numpy, and matplotlib. That's what I've done, and my system runs the demo you listed in your post with no problems. TIA, eric -- http://mail.python.org/mailman/listinfo/python-list Good luck, -Bill -- http://mail.python.org/mailman/listinfo/python-list
keyerror '__repr__'
hi
i have this class book
class book:
def __init__(self,name,price):
self.name = name
self.price = price
def __getattr__(self,attr):
if attr == '__str__':
print 'intercepting in-built method call '
return '%s:%s' %
(object.__getattribute__(self,'name'),object.__getattribute___(self,'price'))
else:
return self.__dict__[attr]
b = book('the tempest',234)
b
Traceback (most recent call last):
File console, line 1, in module
File console, line 11, in __getattr__
KeyError: '__repr__'
i am missing on a concept here. please enlighten me.
--
http://mail.python.org/mailman/listinfo/python-list
Re: keyerror '__repr__'
On Sat, Aug 4, 2012 at 7:48 AM, vijay shanker vshanker...@gmail.com wrote:
hi
i have this class book
class book:
def __init__(self,name,price):
self.name = name
self.price = price
def __getattr__(self,attr):
if attr == '__str__':
print 'intercepting in-built method call '
return '%s:%s' %
(object.__getattribute__(self,'name'),object.__getattribute___(self,'price'))
else:
return self.__dict__[attr]
b = book('the tempest',234)
b
Traceback (most recent call last):
File console, line 1, in module
File console, line 11, in __getattr__
KeyError: '__repr__'
i am missing on a concept here. please enlighten me.
A. You ought to be subclassing the `object` class so that your class
is new-style (see
http://docs.python.org/reference/datamodel.html#new-style-and-classic-classes
); classic classes are deprecated. Incidentally, you can't intercept
special method lookups on new-style classes like you do in your code
snippet (see
http://docs.python.org/reference/datamodel.html#special-method-lookup-for-new-style-classes
). You'll need to define actual __repr__() and/or __str__() methods.
B. The interactive interpreter uses repr(), rather than str(), to
stringify results.
$ python
Python 2.7.2 (default, Jun 20 2012, 16:23:33)
class Foo(object):
... def __str__(self): return bar
... def __repr__(self): return qux
...
Foo()
qux
See http://docs.python.org/reference/datamodel.html#object.__repr__
Cheers,
Chris
--
http://rebertia.com
--
http://mail.python.org/mailman/listinfo/python-list
[newbie] Looking for a good introduction to object oriented programming with Python
I'm looking for a good introduction to object oriented programming with Python. I am looking for an introduction which only refers to Python. I have seen introductions where the authors make comparisons to other languages such as C++ and Java, but as I don't know these languages that doesn't help me further much, it rather confuses me. I also found an introduction in which the author started by telling that object oriented programming is weird, such a statement did stop me reading further as I think an author should at least believe in the topic he is going to present as being logical. If someone here has a link or title to such an intro, I'd appreciate that very much regards, Jean p.s. People who don't like my style of asking questions, please neglect this message -- http://mail.python.org/mailman/listinfo/python-list
Re: On-topic: alternate Python implementations
Stefan Krah stefan-use...@bytereef.org writes: In the free software world, apparently many people like C. C is also quite popular in the zero-fault software world: Several verification tools do exist and Leroy et al. are writing a certified compiler for C to plug the hole between the verified source code and the generated assembly. C is pretty poor as a compiler target: how would you translate Python generators into C, for example? How would you handle garbage collection? C isn't so great for high-assurance stuff either, compared to (say) Ada. People do use it in critical apps, but that's just because it is (or anyway used to be) so ubiquitous. I'm wondering what you mean about verification tools, other than analyzers like Coverity that mainly check for bugs that in a safer language would be caught by the compiler. Compcert is not all that C-specific it has been adapted to compile a Haskell-derived language (Habit). Haskell doesn't sound all that great as a translation target for Python either, unfortunately, because its execution semantics are so different. GHC is a very powerful compiler but it was made to compile Haskell code that people actually write, and may do less good of a job with compiler output from an imperative language like Python. Compiling Python to Scheme and then using a Scheme compiler might be a more natural fit. But, compiling to Haskell was probably pretty convenient for that particular project. Finally, Python itself isn't all that well suited for compilation, given its high dynamicity. It will be interesting to see if the language evolves due to PyPy. -- http://mail.python.org/mailman/listinfo/python-list
Re: On-topic: alternate Python implementations
Paul Rubin, 04.08.2012 17:59: Stefan Krah writes: In the free software world, apparently many people like C. C is also quite popular in the zero-fault software world: Several verification tools do exist and Leroy et al. are writing a certified compiler for C to plug the hole between the verified source code and the generated assembly. C is pretty poor as a compiler target: how would you translate Python generators into C, for example? Depends. If you have CPython available, that'd be a straight forward extension type. Otherwise, I guess you'd either have a class for them in C++ or a struct in C. Not exactly complex. For the yielding, you can use labels and goto. Given that you generate the code, that's pretty straight forward as well. How would you handle garbage collection? CPython does it automatically for us at least. Lacking that, you'd use one of the available garbage collection implementations, or provide none at all. Haskell doesn't sound all that great as a translation target for Python either, unfortunately, because its execution semantics are so different. GHC is a very powerful compiler but it was made to compile Haskell code that people actually write, and may do less good of a job with compiler output from an imperative language like Python. Compiling Python to Scheme and then using a Scheme compiler might be a more natural fit. But, compiling to Haskell was probably pretty convenient for that particular project. You'd have some kind of emulation layer that does most of the translation at runtime. That's why I said that you shouldn't expect too much of a performance gain from what the platform gives you for the underlying implementation. It can optimise the emulator, but it won't see enough of the Python code to make anything efficient out of it. Jython is an example for that. Finally, Python itself isn't all that well suited for compilation, given its high dynamicity. You can get pretty far with static code analysis, optimistic optimisations and code specialisation. We've decided against whole program analysis in Cython not only for compiler complexity reasons but also because it would let the normal compilation time explode for gains that you can much easier get by manual optimisation. Obviously, optimising JIT compilers can do much more here (because they actually have to do less), although they won't always be able to figure out the right thing to do either. That's where manual optimisation wins again. Stefan -- http://mail.python.org/mailman/listinfo/python-list
Re: python pynotify with textbox input
how can i made a notification for gnome-shell with a textbox input ?? library: pynotify? You can do it in many ways. You can use one of the Python GUI frameworks - Qt, wx, GTK ... You can use utilities like zenity ... -- http://mail.python.org/mailman/listinfo/python-list
Re: On-topic: alternate Python implementations
Stefan Behnel stefan...@behnel.de writes: C is pretty poor as a compiler target: how would you translate Python generators into C, for example? Depends. If you have CPython available, that'd be a straight forward extension type. Calling CPython hardly counts as compiling Python into C. For the yielding, you can use labels and goto. Given that you generate the code, that's pretty straight forward as well. You're going to compile the whole Python program into a single C function so that you can do gotos inside of it? What happens if the program imports a generator? How would you handle garbage collection? CPython does it automatically for us at least. You mean you're going to have all the same INCREF/DECREF stuff on every operation in compiled data? Ugh. Lacking that, you'd use one of the available garbage collection implementations, What implementations would those be? There's the Boehm GC which is useful for some purposes but not really suitable at large scale, from what I can tell. Is there something else? or provide none at all. You're going to let the program just leak memory until it crashes?? you shouldn't expect too much of a performance gain from what the platform gives you for the underlying implementation. It can optimise the emulator, but it won't see enough of the Python code to make anything efficient out of it. Jython is an example for that. Compare that to the performance gain of LuaJIT and it starts to look like something is wrong with that approach, or maybe some issue inherent in Python itself. You can get pretty far with static code analysis, optimistic optimisations and code specialisation. It seems very hard to do reasonable optimizations in the presence of standard Python techniques like dynamically poking class instance attributes. I guess some optimizations are still possible, like storing attributes named as literals in the program in fixed slots, saving some dictionary lookups even though the slot contents would have to still be mutable. -- http://mail.python.org/mailman/listinfo/python-list
Re: On-topic: alternate Python implementations
On 04/08/2012 11:59, Stefan Behnel wrote: Mark Lawrence, 04.08.2012 12:05: I agree so it's off topic and can't be discussed here. Isn't that right, Stefan? Hmm, in case you are referring to a recent friendly and diplomatic request of mine regarding a couple of people who were burdening a public high volume mailing list with a purely private back-and-forth chat about having beer and getting drunk - then, no, I don't think the discussion in this thread qualifies as yet another example for that so far. Stefan With arrogance like that German by any chance? -- Cheers. Mark Lawrence. -- http://mail.python.org/mailman/listinfo/python-list
Re: On-topic: alternate Python implementations
On Sat, 04 Aug 2012 19:24:12 +0100, Mark Lawrence breamore...@yahoo.co.uk wrote: On 04/08/2012 11:59, Stefan Behnel wrote: Mark Lawrence, 04.08.2012 12:05: I agree so it's off topic and can't be discussed here. Isn't that right, Stefan? Hmm, in case you are referring to a recent friendly and diplomatic request of mine regarding a couple of people who were burdening a public high volume mailing list with a purely private back-and-forth chat about having beer and getting drunk - then, no, I don't think the discussion in this thread qualifies as yet another example for that so far. Stefan With arrogance like that German by any chance? Hey now, cool it with the passive-aggression. We're here to discuss code, right? If you want to fight it out, you can gladly do it by e-mail. ~Temia -- Invective! Verb your expletive nouns! -- http://mail.python.org/mailman/listinfo/python-list
Re: On-topic: alternate Python implementations
: On 4 August 2012 14:24, Mark Lawrence breamore...@yahoo.co.uk wrote: With arrogance like that German by any chance? I didn't give a monkeys about the beer conversation personally, but can we leave the national stereotypes out of it? -[]z. -- http://mail.python.org/mailman/listinfo/python-list
Re: On-topic: alternate Python implementations
From: Zero Piraeus sche...@gmail.com To: Mark Lawrence breamore...@yahoo.co.uk Cc: python-list@python.org Sent: Saturday, 4 August 2012, 19:42 Subject: Re: On-topic: alternate Python implementations : On 4 August 2012 14:24, Mark Lawrence breamore...@yahoo.co.uk wrote: With arrogance like that German by any chance? I didn't give a monkeys about the beer conversation personally, but can we leave the national stereotypes out of it? -[]z. No. Next question?-- http://mail.python.org/mailman/listinfo/python-list
Re: On-topic: alternate Python implementations
: On 4 August 2012 14:50, Mark Lawrence breamore...@yahoo.co.uk wrote: No. Next question? *plonk* -[]z. -- http://mail.python.org/mailman/listinfo/python-list
Re: On-topic: alternate Python implementations
Paul Rubin, 04.08.2012 20:18: Stefan Behnel writes: C is pretty poor as a compiler target: how would you translate Python generators into C, for example? Depends. If you have CPython available, that'd be a straight forward extension type. Calling CPython hardly counts as compiling Python into C. CPython is written in C, though. So anything that CPython does can be done in C. It's not like the CPython project used a completely unusual way of writing C code. Besides, I find your above statement questionable. You will always need some kind of runtime infrastructure when you compile Python into C, so you can just as well use CPython for that instead of reimplementing it completely from scratch. Both Cython and Nuitka do exactly that, and one of the major advantages of that approach is that they can freely interact with arbitrary code (Python or not) that was written for CPython, regardless of its native dependencies. What good would it be to throw all of that away, just for the sake of having pure C code generation? For the yielding, you can use labels and goto. Given that you generate the code, that's pretty straight forward as well. You're going to compile the whole Python program into a single C function so that you can do gotos inside of it? What happens if the program imports a generator? No, you are going to compile only the generator function into a function that uses gotos, maybe with an additional in-out struct parameter that holds its state. Then, on entry, you read the label (or its ID) from the previous state, reset local variables and jump to the label. On exit, you store the state back end return. Cython does it that way. Totally straight forward, as I said. How would you handle garbage collection? CPython does it automatically for us at least. You mean you're going to have all the same INCREF/DECREF stuff on every operation in compiled data? Ugh. If you don't like that, you can experiment with anything from a dedicated GC to transactional memory. Lacking that, you'd use one of the available garbage collection implementations, What implementations would those be? There's the Boehm GC which is useful for some purposes but not really suitable at large scale, from what I can tell. Is there something else? No idea - I'll look it up when I need one. Last I heard, PyPy had a couple of GCs to choose from, but I don't know how closely the are tied into its infrastructure. or provide none at all. You're going to let the program just leak memory until it crashes?? Well, it's not like CPython leaks memory until it crashes, now does it? And it's written in C. So there must be ways to handle this also in C. Remember that CPython didn't even have a GC before something around 2.0, IIRC. That worked quite ok in most cases and simply left the tricky cases to the programmers. It really depends on what your requirements are. Small embedded systems, time critical code and real-time systems are often much better off without garbage collection. It's pure convenience, after all. you shouldn't expect too much of a performance gain from what the platform gives you for the underlying implementation. It can optimise the emulator, but it won't see enough of the Python code to make anything efficient out of it. Jython is an example for that. Compare that to the performance gain of LuaJIT and it starts to look like something is wrong with that approach, or maybe some issue inherent in Python itself. Huh? LuaJIT is a reimplementation of Lua that uses an optimising JIT compiler specifically for Lua code. How is that similar to the Jython runtime that runs *on top of* the JVM with its generic byte code based JIT compiler? Basically, LuaJIT's JIT compiler works at the same level as the one in PyPy, which is why both can theoretically provide the same level of performance gains. You can get pretty far with static code analysis, optimistic optimisations and code specialisation. It seems very hard to do reasonable optimizations in the presence of standard Python techniques like dynamically poking class instance attributes. I guess some optimizations are still possible, like storing attributes named as literals in the program in fixed slots, saving some dictionary lookups even though the slot contents would have to still be mutable. Sure. Even when targeting the CPython runtime with the generated C code (like Cython or Nuitka), you can still do a lot. And sure, static code analysis will never be able to infer everything that a JIT compiler can see. Stefan -- http://mail.python.org/mailman/listinfo/python-list
Re: On-topic: alternate Python implementations
On 04/08/2012 20:06, Stefan Behnel wrote: Paul Rubin, 04.08.2012 20:18: Stefan Behnel writes: C is pretty poor as a compiler target: how would you translate Python generators into C, for example? Depends. If you have CPython available, that'd be a straight forward extension type. Calling CPython hardly counts as compiling Python into C. CPython is written in C, though. So anything that CPython does can be done in C. It's not like the CPython project used a completely unusual way of writing C code. Besides, I find your above statement questionable. You will always need some kind of runtime infrastructure when you compile Python into C, so you can just as well use CPython for that instead of reimplementing it completely from scratch. Both Cython and Nuitka do exactly that, and one of the major advantages of that approach is that they can freely interact with arbitrary code (Python or not) that was written for CPython, regardless of its native dependencies. What good would it be to throw all of that away, just for the sake of having pure C code generation? For the yielding, you can use labels and goto. Given that you generate the code, that's pretty straight forward as well. You're going to compile the whole Python program into a single C function so that you can do gotos inside of it? What happens if the program imports a generator? No, you are going to compile only the generator function into a function that uses gotos, maybe with an additional in-out struct parameter that holds its state. Then, on entry, you read the label (or its ID) from the previous state, reset local variables and jump to the label. On exit, you store the state back end return. Cython does it that way. Totally straight forward, as I said. How would you handle garbage collection? CPython does it automatically for us at least. You mean you're going to have all the same INCREF/DECREF stuff on every operation in compiled data? Ugh. If you don't like that, you can experiment with anything from a dedicated GC to transactional memory. Lacking that, you'd use one of the available garbage collection implementations, What implementations would those be? There's the Boehm GC which is useful for some purposes but not really suitable at large scale, from what I can tell. Is there something else? No idea - I'll look it up when I need one. Last I heard, PyPy had a couple of GCs to choose from, but I don't know how closely the are tied into its infrastructure. or provide none at all. You're going to let the program just leak memory until it crashes?? Well, it's not like CPython leaks memory until it crashes, now does it? And it's written in C. So there must be ways to handle this also in C. Remember that CPython didn't even have a GC before something around 2.0, IIRC. That worked quite ok in most cases and simply left the tricky cases to the programmers. It really depends on what your requirements are. Small embedded systems, time critical code and real-time systems are often much better off without garbage collection. It's pure convenience, after all. [snip] CPython relied entirely on reference counting, so memory could leak you if inadvertently created a cycle of memory references. That problem was fixed when a mark-and-sweep mechanism was added (it's called occasionally to collect any unreachable cycles). -- http://mail.python.org/mailman/listinfo/python-list
when an iterable object is exhausted or not
Two similar iterable objects but with a different behavior : $$$ i = range(2,5) $$$ for x in i : print(x,end=' ') 2 3 4 $$$ for x in i : print(x,end=' ')# i is not exhausted 2 3 4 - Compare with : $$$ i = filter(lambda c : c.isdigit(), 'a1b2c3') $$$ for x in i : print(x,end=' ') 1 2 3 $$$ for x in i : print(x,end=' ')# i is exhausted $$$ IMHO, this should not happen in Py3k. What is the rationale of this (bad ?) design, which forces the programmer to memorize which one is exhaustable and which one is not ?... franck -- http://mail.python.org/mailman/listinfo/python-list
Re: when an iterable object is exhausted or not
Franck Ditter fra...@ditter.org wrote: Two similar iterable objects but with a different behavior : $$$ i = range(2,5) $$$ for x in i : print(x,end=' ') 2 3 4 $$$ for x in i : print(x,end=' ')# i is not exhausted 2 3 4 - Compare with : $$$ i = filter(lambda c : c.isdigit(), 'a1b2c3') $$$ for x in i : print(x,end=' ') 1 2 3 $$$ for x in i : print(x,end=' ')# i is exhausted $$$ IMHO, this should not happen in Py3k. It's interesting that it DOESN'T happen in Python 2. The first i is of type list, the second i is of type string, and both are restartable. What's the type of i in the second case in Python 3? -- Tim Roberts, t...@probo.com Providenza Boekelheide, Inc. -- http://mail.python.org/mailman/listinfo/python-list
Re: On-topic: alternate Python implementations
Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: Most people are aware, if only vaguely, of the big Four Python implementations: CPython, or just Python, the reference implementation written in C. IronPython, written in .NET. Technicality: .NET is not a language, it is a run-time framework. IronPython is written in C#. It generates code that runs in the .NET Framework. -- Tim Roberts, t...@probo.com Providenza Boekelheide, Inc. -- http://mail.python.org/mailman/listinfo/python-list
Re: when an iterable object is exhausted or not
On 04/08/2012 20:20, Franck Ditter wrote: Two similar iterable objects but with a different behavior : $$$ i = range(2,5) $$$ for x in i : print(x,end=' ') 2 3 4 $$$ for x in i : print(x,end=' ')# i is not exhausted 2 3 4 - Compare with : $$$ i = filter(lambda c : c.isdigit(), 'a1b2c3') $$$ for x in i : print(x,end=' ') 1 2 3 $$$ for x in i : print(x,end=' ')# i is exhausted $$$ IMHO, this should not happen in Py3k. What is the rationale of this (bad ?) design, which forces the programmer to memorize which one is exhaustable and which one is not ?... 'range' returns a 'range' object: i = range(2,5) i range(2, 5) The 'for' loop passes it to 'iter' to get an iterator: iter(i) range_iterator object at 0x0135DB30 More importantly: iter(i) is i False In other words, when asked for an iterator, the 'range' object always creates a new one. On the other hand, 'filter' returns a 'filter' object: i = filter(lambda c : c.isdigit(), 'a1b2c3') i filter object at 0x01360B30 The 'for' loop passes it to 'iter' to get an iterator: iter(i) filter object at 0x01360B30 More importantly: iter(i) is i True In other words, the 'filter' object returns _itself_ as the iterator. -- http://mail.python.org/mailman/listinfo/python-list
Re: when an iterable object is exhausted or not
On 08/04/12 14:20, Franck Ditter wrote:
Two similar iterable objects but with a different behavior :
$$$ i = range(2,5)
$$$ for x in i : print(x,end=' ')
2 3 4
$$$ for x in i : print(x,end=' ')# i is not exhausted
2 3 4
- Compare with :
$$$ i = filter(lambda c : c.isdigit(), 'a1b2c3')
$$$ for x in i : print(x,end=' ')
1 2 3
$$$ for x in i : print(x,end=' ')# i is exhausted
$$$
IMHO, this should not happen in Py3k.
What is the rationale of this (bad ?) design, which forces the programmer
to memorize which one is exhaustable and which one is not ?...
I can't speak to the rationale, but it seems that a range() object
has some extra features that a normal iter doesn't:
i = iter(range(2,5))
for x in i: print (x, end=' ')
...
2 3 4 for x in i: print (x, end=' ')
...
(your 2nd behavior, and what I'd expect).
So my guess would be that the for {var} in {thing} triggers a
re-calling of range.__iter__ since it's not an iterator to begin with.
-tkc
--
http://mail.python.org/mailman/listinfo/python-list
Re: On-topic: alternate Python implementations
Stefan Behnel stefan...@behnel.de writes: Calling CPython hardly counts as compiling Python into C. CPython is written in C, though. So anything that CPython does can be done in C. It's not like the CPython project used a completely unusual way of writing C code. CPython is a relatively simple interpreter, and executing code by invoking such an interpreter IMHO doesn't count as compiling it in any meaningful way. You will always need some kind of runtime infrastructure when you compile Python into C, so you can just as well use CPython for that instead of reimplementing it completely from scratch. Maybe there's parts of Cpython you can re-use, but having the CPython interpreter be the execution engine for compiled Python generators again fails the seriousness test of what it means to compile code. If you mean something other than that, you might explain more clearly. Both Cython and Nuitka do exactly that, I didn't know about Nuitka; it looks interesting but (at least after a few minutes looking) I don't have much sense of how it works. No, you are going to compile only the generator function into a function that uses gotos, maybe with an additional in-out struct parameter that holds its state. Yeah, ok, I guess that can work, given python generators are limited to returning through just one stack level. You might want to avoid copying locals by just putting everything into a struct, that has to be retained across entries/exits. If you don't like that, you can experiment with anything from a dedicated GC to transactional memory. OK, but then CPython is no longer managing the memory. Last I heard, PyPy had a couple of GCs to choose from, PyPy doesn't compile to C, but I guess compiling to C doesn't preclude precise GC, as long as the generated C code carefully tracks what C objects can contain GC-able pointers, and follows some constraints about when the GC can run. Some other compilers do this so it's not as big a deal as it sounded like at first. OK. or provide none at all. You're going to let the program just leak memory until it crashes?? Well, it's not like CPython leaks memory until it crashes... I was counting CPython's reference counting as a rudimentary form of GC, though I guess that's terminology that not everyone agrees on. Huh? LuaJIT is a reimplementation of Lua that uses an optimising JIT compiler specifically for Lua code. How is that similar to the Jython runtime that runs *on top of* the JVM with its generic byte code based JIT compiler? I thought LuaJIT compiles the existing Lua VM code, but I haven't looked at it closely or used it. It seems very hard to do reasonable optimizations in the presence of standard Python techniques Sure. Even when targeting the CPython runtime with the generated C code (like Cython or Nuitka), you can still do a lot. And sure, static code analysis will never be able to infer everything that a JIT compiler can see. I think even a JIT can't avoid a lot of pain and slowdown, without complex whole-program analysis and requiring the application to follow some special conventions, like never importing at runtime. -- http://mail.python.org/mailman/listinfo/python-list
Re: trouble with pyplot in os x
On Saturday, August 4, 2012 8:11:44 AM UTC-5, William R. Wing (Bill Wing) wrote: On Aug 3, 2012, at 11:12 PM, Eric wrote: I'm just starting to futz around with matplotlib and I tried to run this example from the matplotlib doc page (it's the imshow() example): import numpy as np import matplotlib.cm as cm import matplotlib.mlab as mlab import matplotlib.pyplot as plt delta = 0.025 x = y = np.arange(-3.0, 3.0, delta) X, Y = np.meshgrid(x, y) Z1 = mlab.bivariate_normal(X, Y, 1.0, 1.0, 0.0, 0.0) Z2 = mlab.bivariate_normal(X, Y, 1.5, 0.5, 1, 1) Z = Z2-Z1 # difference of Gaussians im = plt.imshow(Z, interpolation='bilinear', cmap=cm.gray, origin='lower', extent=[-3,3,-3,3]) plt.show() OK I get the following error: Exception in Tkinter callback Traceback (most recent call last): File /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-tk/Tkinter.py, line 1410, in __call__ return self.func(*args) File /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/matplotlib/backends/backend_tkagg.py, line 248, in resize self.show() File /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/matplotlib/backends/backend_tkagg.py, line 252, in draw tkagg.blit(self._tkphoto, self.renderer._renderer, colormode=2) File /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/matplotlib/backends/tkagg.py, line 19, in blit tk.call(PyAggImagePhoto, photoimage, id(aggimage), colormode, id(bbox_array)) TclError This looks as though you are running the latest python from python.org, not the pre-installed python from Apple (that's good). I'm using Python 2.7.3 on OS X 10.6.8 and I'm invoking python by doing arch -i386 python because matplotlib doesn't do 64-bit. Has anyone else seen this? Does anyone know why this is happening? It looks like a problem with tkinter but beyond that I haven't a clue. And, finally, any ideas as to how to make it behave? I DON'T know how tk is getting mixed into this, it shouldn't be. But I think I can tell you how to get matplotlib working... Matplotlib DOES do 64-bit, the problem is numpy, which as you download in binary form does not. But, if you copy the bash script here: https://raw.github.com/fonnesbeck/ScipySuperpack/master/install_superpack.sh it will download the sources and build a 64-bit numpy, which will then give you a default 64-bit full package of python, numpy, and matplotlib. That's what I've done, and my system runs the demo you listed in your post with no problems. TIA, eric -- http://mail.python.org/mailman/listinfo/python-list Good luck, -Bill Yes, I got the Python 2.7 (and 3.2) distributions from python.org and I also got Tcl/Tk per their directions. I still have all the old Apple installed stuff too plus some older Tcl/Tk. Doesn't matplotlib use Tk (Tkinter) to do its graphs and what-not? I also have at least two different versions of Tcl/Tk (8.5.7 and 8.5.12) and I'm wondering if that may not be causing problems. I'll give that bash script a try. Thanks, eric -- http://mail.python.org/mailman/listinfo/python-list
Re: when an iterable object is exhausted or not
On 8/4/2012 4:24 PM, Tim Chase wrote:
On 08/04/12 14:20, Franck Ditter wrote:
Two similar iterable objects but with a different behavior :
$$$ i = range(2,5)
$$$ for x in i : print(x,end=' ')
2 3 4
$$$ for x in i : print(x,end=' ')# i is not exhausted
2 3 4
- Compare with :
$$$ i = filter(lambda c : c.isdigit(), 'a1b2c3')
$$$ for x in i : print(x,end=' ')
1 2 3
$$$ for x in i : print(x,end=' ')# i is exhausted
$$$
IMHO, this should not happen in Py3k.
What is the rationale of this (bad ?) design, which forces the programmer
to memorize which one is exhaustable and which one is not ?...
I can't speak to the rationale, but it seems that a range() object
has some extra features that a normal iter doesn't:
i = iter(range(2,5))
for x in i: print (x, end=' ')
...
2 3 4 for x in i: print (x, end=' ')
...
(your 2nd behavior, and what I'd expect).
So my guess would be that the for {var} in {thing} triggers a
re-calling of range.__iter__ since it's not an iterator to begin with.
range produces a re-iterable range object because it can. The result is
self-contained with 3 data attributes, so it can create rangeiterators
on demand.
filter, on the other hand, depends on an external iterable and it cannot
depend on that external object being re-iterable. So even if we
programmed filter() to produce a filter object that produced
filteriterators, the latter would often only work for the first. Also,
If you want the filtered collection more than once, you should just save
it. On the other hand, reproducing counts with a rangeiterator is nearly
as fast as looking them up in a saved list, and much more memory efficient.
--
Terry Jan Reedy
--
http://mail.python.org/mailman/listinfo/python-list
Re: On-topic: alternate Python implementations
Paul Rubin, 04.08.2012 22:43: Stefan Behnel writes: Calling CPython hardly counts as compiling Python into C. CPython is written in C, though. So anything that CPython does can be done in C. It's not like the CPython project used a completely unusual way of writing C code. CPython is a relatively simple interpreter, and executing code by invoking such an interpreter IMHO doesn't count as compiling it in any meaningful way. Oh, CPython is substantially more than an interpreter. The eval loop is only *one* way to use the runtime environment. Remember that it has many builtin types and functions as well as a huge standard library. Much of the runtime environment is already written in C or can be compiled down to C. If you compile Python code into C code that avoids the eval loop and only uses the CPython runtime environment (which is what Cython does), I think that qualifies as compiling Python code to C. It's definitely the most practical and user friendly way to do it. You will always need some kind of runtime infrastructure when you compile Python into C, so you can just as well use CPython for that instead of reimplementing it completely from scratch. Maybe there's parts of Cpython you can re-use, but having the CPython interpreter be the execution engine for compiled Python generators again fails the seriousness test of what it means to compile code. If you mean something other than that, you might explain more clearly. See above. Both Cython and Nuitka do exactly that, I didn't know about Nuitka; it looks interesting but (at least after a few minutes looking) I don't have much sense of how it works. It's mostly like Cython but without the type system, i.e. without all the stuff that makes it useful in real life. Just a bare Python-to-C++-in-CPython compiler, without much of a way to make it do what you want. Last I heard, PyPy had a couple of GCs to choose from, PyPy doesn't compile to C RPython (usually) does, though, and my guess is that the memory management part of the runtime is written in RPython. but I guess compiling to C doesn't preclude precise GC, as long as the generated C code carefully tracks what C objects can contain GC-able pointers, and follows some constraints about when the GC can run. Some other compilers do this so it's not as big a deal as it sounded like at first. OK. Yep, C really becomes a lot nicer when you generate it. Huh? LuaJIT is a reimplementation of Lua that uses an optimising JIT compiler specifically for Lua code. How is that similar to the Jython runtime that runs *on top of* the JVM with its generic byte code based JIT compiler? I thought LuaJIT compiles the existing Lua VM code, but I haven't looked at it closely or used it. Ok. It obviously reuses code, but the VM part of it is really different from standard Lua. Stefan -- http://mail.python.org/mailman/listinfo/python-list
Re: On-topic: alternate Python implementations
On Friday, August 3, 2012 11:15:20 PM UTC-7, Steven D'Aprano wrote: WPython - another optimizing version of Python with wordcodes instead of bytecodes. http://code.google.com/p/wpython/ I remember reading about this a while ago. I thought this was eventually going to be committed to CPython... =\ -- http://mail.python.org/mailman/listinfo/python-list
Re: On-topic: alternate Python implementations
On Sat, Aug 04, 2012 at 08:40:16AM +0200, Stefan Behnel wrote: Steven D'Aprano, 04.08.2012 08:15: Most people are aware, if only vaguely, of the big Four Python implementations: And not to forget Cython, which is the only static Python compiler that is widely used. Compiles and optimises Python to C code that uses the CPython runtime and allows for easy manual optimisations to get C-like performance out of it. Cython is certainly *not* a Python *implementation*, since it always uses the CPython runtime (and compiling Cython C files requires Python.h). None of the other implementations require Python for actually compiling or running Python source. Oh, yes, you can create a stand-alone... wait, a stand-alone app. By embedding the Python runtime (dynamic linking with libpythonX.Y... maybe static too? Didn't test, because it's irrelevant for making the point). Grits, J -- http://mail.python.org/mailman/listinfo/python-list
Object Models - decoupling data access - good examples ?
I'm interested in best practice approaches to : decoupling data access code from application code; and translations between database structures and domain objects. For some time I've done database access by in a particular way and while I think it's OK it's not very pythonic so I'd be interested in hearing of other approaches - even better if there are open source examples whose code might be read. I should say I'm talking relational database here and, for various reasons, ORMs are not involved. So this is what I do (in a one class project call 'bar') in order to allow objects of type foo to be fetched/inserted/updated bar/foo.py bar/bardb/bardbConnection.py bar/bardb/BusinessLogic/fooManager.py bar/bardb/BusinessObject/foo.py bar/bardb/DataAccess/fooDB.py And this is what they actually do : bar/foo.py The class as the outside world knows it bar/bardb/bardbConnection.py Manages database connection bar/bardb/BusinessLogic/fooManager.py Exposes methods used by bar/foo.py such as 'save'/'update' etc and implements necessary validation etc bar/bardb/BusinessObject/foo.py A collection of getters/setters which does any translation between types necessary on the way to/from the rdbms bar/bardb/DataAccess/fooDB.py Implements the actual SQL necessary for the relevant interactions with the database As I say this works OK for me but I'd be interested to hear of what others do. Thanks Richard. -- http://mail.python.org/mailman/listinfo/python-list
Re: [newbie] Looking for a good introduction to object oriented programming with Python
One reason you may be having difficulty is that unlike some languages (C++/Java) object-orientation is not a be all and end all in Python, in fact you could work with Python for a long time without really 'doing it' at all (well other than calling methods/properties on existing API's). Having said that here's what I would suggest ... Could do worse than this : http://www.diveintopython.net/object_oriented_framework/index.html and this http://docs.python.org/tutorial/classes.html read together. Judging by your question this is a probably a little advanced for now but you could bookmark it for the future: http://www.catonmat.net/blog/learning-python-design-patterns-through-video-lectures/ Here's the corresponding PDF to go with the video: http://assets.en.oreilly.com/1/event/45/Practical%20Python%20Patterns%20Presentation.pdf -- http://mail.python.org/mailman/listinfo/python-list
Re: when an iterable object is exhausted or not
On Sat, 04 Aug 2012 12:44:07 -0700, Tim Roberts wrote: $$$ i = filter(lambda c : c.isdigit(), 'a1b2c3') $$$ for x in i : print(x,end=' ') 1 2 3 $$$ for x in i : print(x,end=' ')# i is exhausted $$$ IMHO, this should not happen in Py3k. It's interesting that it DOESN'T happen in Python 2. The first i is of type list, the second i is of type string, and both are restartable. What's the type of i in the second case in Python 3? In Python 3, filter returns a lazy iterator, a filter object. It generates items on demand. In Python 2, filter is eager, not lazy, and generates items all up-front. If the input is a string, it generates a string; if the input is a tuple, it generates a tuple; otherwise it generates a list. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: On-topic: alternate Python implementations
On Sat, 04 Aug 2012 08:59:18 -0700, Paul Rubin wrote: C isn't so great for high-assurance stuff either, compared to (say) Ada. People do use it in critical apps, but that's just because it is (or anyway used to be) so ubiquitous. And then they are shocked, SHOCKED I say!, when their app has enough buffer overflow security vulnerabilities to sink a battleship. [half a wink] Haskell doesn't sound all that great as a translation target for Python either, unfortunately, because its execution semantics are so different. I have no opinion on that either way, except to say that if some developer wants to experiment with Python-in-Haskell, good on him or her. Trying something new is how progress is made. [...] Finally, Python itself isn't all that well suited for compilation, given its high dynamicity. It will be interesting to see if the language evolves due to PyPy. Python is a dynamic language, but most Python code is relatively static. Runtime optimizations that target the common case, but fall back to unoptimized code in the rare cases that the optimization doesn't apply, offer the opportunity of big speedups for most code at the cost of trivial slowdowns when you do something unusual. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Object Models - decoupling data access - good examples ?
In article ebb88ade-7598-46b1-8fb6-fd7f7430b...@googlegroups.com, shearich...@gmail.com wrote: I should say I'm talking relational database here and, for various reasons, ORMs are not involved. Just out of curiosity, why do you eschew ORMs? On the other hand, you really haven't. All you've done is rolled your own. So, the real question is, why do you want to roll your own ORM instead of using some existing one? -- http://mail.python.org/mailman/listinfo/python-list
Re: On-topic: alternate Python implementations
Steven D'Aprano steve+comp.lang.pyt...@pearwood.info writes: Runtime optimizations that target the common case, but fall back to unoptimized code in the rare cases that the optimization doesn't apply, offer the opportunity of big speedups for most code at the cost of trivial slowdowns when you do something unusual. The problem is you can't always tell if the unusual case is being exercised without an expensive dynamic check, which in some cases must be repeated in every iteration of a critical inner loop, even though it turns out that the program never actually uses the unusual case. -- http://mail.python.org/mailman/listinfo/python-list
Re: when an iterable object is exhausted or not
On Sat, 04 Aug 2012 21:20:36 +0200, Franck Ditter wrote:
Two similar iterable objects but with a different behavior :
[...]
IMHO, this should not happen in Py3k. What is the rationale of this (bad
?) design, which forces the programmer to memorize which one is
exhaustable and which one is not ?...
What makes you say that they are similar iterable objects? Except that
they are both iterable, they are very different. You might as well say
that lists and dicts are similar iterable objects.
filter objects are iterators, and so obey the intentionally simple
iterator protocol. range objects are iterable but not iterators, and do
not obey the iterator protocol.
py it = filter(lambda x: x, set('abc'))
py iter(it) is it
True
py x = range(1, 15, 2)
py iter(x) is x
False
filter relies on its input, which it consumes as it does. Since the input
may not be restartable, filter cannot be restartable either. For
simplicity, filter does not try to be clever and guess when the input
argument is restartable. Instead, it simply and consistently behaves the
same for any iterable input.
range is a specialist iterable data structure that does not consume
anything. It computes its output lazily, but that is the only similarity
with iterators. There's no need to limit range objects to the simple
iterator protocol, since they don't consume their input -- a single
object can easily compute its output as often as you want. range objects
are indexable and sliceable:
py x = range(1, 15, 2)
py x[4]
9
py x[2:4]
range(5, 9, 2)
Why artificially make range objects unrestartable just to satisfy
compatibility with iterators?
The caller already has to remember that range and filter take different
arguments, do different things, and return different objects. Why is it
hard to remember that range is restartable and filter is not?
--
Steven
--
http://mail.python.org/mailman/listinfo/python-list
Re: On-topic: alternate Python implementations
On Sat, 04 Aug 2012 18:38:33 -0700, Paul Rubin wrote: Steven D'Aprano steve+comp.lang.pyt...@pearwood.info writes: Runtime optimizations that target the common case, but fall back to unoptimized code in the rare cases that the optimization doesn't apply, offer the opportunity of big speedups for most code at the cost of trivial slowdowns when you do something unusual. The problem is you can't always tell if the unusual case is being exercised without an expensive dynamic check, which in some cases must be repeated in every iteration of a critical inner loop, even though it turns out that the program never actually uses the unusual case. I never said optimizing Python was easy :) Obviously if the check is expensive enough, the optimization isn't going to be worth doing. But often the check is not so expensive, or is just a matter of tedious and careful book-keeping. I don't wish to dispute that optimizing Python is hard, but it's not a Hard Problem like factorizing huge integers, or solving the Palestine/ Israeli conflict. It's hard like cleaning your house after a gang of drunken frat boys have partied all weekend. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: dbf.py API question
On Thu, Aug 2, 2012 at 5:55 PM, Ethan Furman et...@stoneleaf.us wrote: SQLite has a neat feature where if you give it a the file-name of ':memory:' the resulting table is in memory and not on disk. I thought it was a cool feature, but expanded it slightly: any name surrounded by colons results in an in-memory table. I'm looking at the same type of situation with indices, but now I'm wondering if the :name: method is not pythonic and I should use a flag (in_memory=True) when memory storage instead of disk storage is desired. Thoughts? I agree that the flag would be more pythonic in dbf.py. I was not aware that you are adding sqlite functionality to your library. This is very cool! I have been through the same questions with my own DBF library, and I've come to some conclusions: First, I decided to make the library read-only and in-memory. That is all we need in-house anyway. Second, I decided to make an external tool for converting DBF files to sqlite: https://github.com/olemb/dbfget/blob/master/extras/dbf2sqlite (To anyone reading: I have not yet made a public announcement of dbfget, but I will shortly. Consider this an informal announcement: https://github.com/olemb/dbfget/ ) I am considering adding a streaming=True flag which would make the table class a record generator, and a save() method which would allow you to save data back to the file, or to a new file if you provide an optional file name. In fact, I had this functionality in earlier versions, but decided to chuck it out in order to make the API as clean as possible. I hope this can help you somehow in your decision making process. -- http://mail.python.org/mailman/listinfo/python-list
Re: Object Models - decoupling data access - good examples ?
Just out of curiosity, why do you eschew ORMs? Good question ! I'm not anti-ORM (in fact in many circs I'm quite pro-ORM) but for some time I've been working with a client who doesn't want ORMs used (they do have quite good reasons for this although probably not as good as they think). I was interested to know, given that was the case, how you might - in Python, go about structuring an app which didn't use an ORM but which did use a RDBMS fairly intensively. I take your point about having rolled my own ORM - lol - but I can assure you what's in that 'bardb' is a pretty thin layer over the SQL and nothing like the, pretty amazing, functionality of, for instance, SQLAlchemy. -- http://mail.python.org/mailman/listinfo/python-list
conditional running of code portion
Hi, How can I implement something like C++'s conditional compile. if VERBOSE_MODE: print debug information else: do nothing But I don't want this condition to be checked during runtime as it will slow down the code. Thanks in advance. -- http://mail.python.org/mailman/listinfo/python-list
Re: conditional running of code portion
Try pypreprocessor http://code.google.com/p/pypreprocessor/ . Better idea: You should be using the logginghttp://docs.python.org/library/logging.htmlmodule if you want to print debug information quickly.It uses threads and is optimized to run fast. On 5 August 2012 09:46, JW Huang ngc...@gmail.com wrote: Hi, How can I implement something like C++'s conditional compile. if VERBOSE_MODE: print debug information else: do nothing But I don't want this condition to be checked during runtime as it will slow down the code. Thanks in advance. -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
Re: when an iterable object is exhausted or not
An important use of range repeating.
one_to_10 = range(1,10)
one_to_5 = range(1,5)
for x in one_to_5:
for x in one_to_10:pass
if range wasn't repeatable, range would have to be called 5 times compared
with 1!
On 5 August 2012 07:43, Steven D'Aprano
steve+comp.lang.pyt...@pearwood.info wrote:
On Sat, 04 Aug 2012 21:20:36 +0200, Franck Ditter wrote:
Two similar iterable objects but with a different behavior :
[...]
IMHO, this should not happen in Py3k. What is the rationale of this (bad
?) design, which forces the programmer to memorize which one is
exhaustable and which one is not ?...
What makes you say that they are similar iterable objects? Except that
they are both iterable, they are very different. You might as well say
that lists and dicts are similar iterable objects.
filter objects are iterators, and so obey the intentionally simple
iterator protocol. range objects are iterable but not iterators, and do
not obey the iterator protocol.
py it = filter(lambda x: x, set('abc'))
py iter(it) is it
True
py x = range(1, 15, 2)
py iter(x) is x
False
filter relies on its input, which it consumes as it does. Since the input
may not be restartable, filter cannot be restartable either. For
simplicity, filter does not try to be clever and guess when the input
argument is restartable. Instead, it simply and consistently behaves the
same for any iterable input.
range is a specialist iterable data structure that does not consume
anything. It computes its output lazily, but that is the only similarity
with iterators. There's no need to limit range objects to the simple
iterator protocol, since they don't consume their input -- a single
object can easily compute its output as often as you want. range objects
are indexable and sliceable:
py x = range(1, 15, 2)
py x[4]
9
py x[2:4]
range(5, 9, 2)
Why artificially make range objects unrestartable just to satisfy
compatibility with iterators?
The caller already has to remember that range and filter take different
arguments, do different things, and return different objects. Why is it
hard to remember that range is restartable and filter is not?
--
Steven
--
http://mail.python.org/mailman/listinfo/python-list
--
http://mail.python.org/mailman/listinfo/python-list
Re: On-topic: alternate Python implementations
Paul Rubin, 05.08.2012 03:38: Steven D'Aprano writes: Runtime optimizations that target the common case, but fall back to unoptimized code in the rare cases that the optimization doesn't apply, offer the opportunity of big speedups for most code at the cost of trivial slowdowns when you do something unusual. The problem is you can't always tell if the unusual case is being exercised without an expensive dynamic check, which in some cases must be repeated in every iteration of a critical inner loop, even though it turns out that the program never actually uses the unusual case. Cython does a lot of optimistic optimisations. That's where a large part of that huge C file comes from that Cython generates from even simple Python code. For example, in CPython, C function calls are so ridiculously faster than Python function calls that it's worth some effort if it saves you from packing an argument tuple to call into a Python function. In fact, we've been thinking about ways to export C signatures from Python function objects, so that code implemented in C (or a C compatible language) can be called directly from other code implemented in C. That's very common in the CPython ecosystem. There are a lot of simple things that quickly add up into a much better performance on average. Stefan -- http://mail.python.org/mailman/listinfo/python-list
Re: On-topic: alternate Python implementations
Jürgen A. Erhard, 05.08.2012 01:25: On Sat, Aug 04, 2012 at 08:40:16AM +0200, Stefan Behnel wrote: Steven D'Aprano, 04.08.2012 08:15: Most people are aware, if only vaguely, of the big Four Python implementations: And not to forget Cython, which is the only static Python compiler that is widely used. Compiles and optimises Python to C code that uses the CPython runtime and allows for easy manual optimisations to get C-like performance out of it. Cython is certainly *not* a Python *implementation*, since it always uses the CPython runtime (and compiling Cython C files requires Python.h). Yes, it avoids an unnecessary duplication of effort as well as a substantial loss of compatibility that all non-CPython based implementations suffer from. You'd be surprised to see how much of Python we implement, though, including some of the builtins. You might want to revise your opinion once you start digging into it. It's always easy to disagree at the surface. None of the other implementations require Python for actually compiling or running Python source. Nuitka was on the list as well. Oh, yes, you can create a stand-alone... wait, a stand-alone app. By embedding the Python runtime (dynamic linking with libpythonX.Y... maybe static too? Sure, that works. Stefan -- http://mail.python.org/mailman/listinfo/python-list
[issue15546] Iteration breaks with bz2.open(filename,'rt')
Serhiy Storchaka added the comment: I encountered this when implemented bzip2 support in zipfile (issue14371). I solved this also by rewriting read and read1 to make as many reads from the underlying file as necessary to return a non-empty result. -- nosy: +storchaka ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15546 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15522] impove 27 percent performance on stringpbject.c( by prefetch and loop optimization)
abael added the comment:
added my implement( with some enhancement, got better performance, at less
for my apps. ).
test result:
with small chunk of str, got double performanc,
and 111% for big chunks; it
## Util funcion for text definition:
def pf(f,n):
a=time()
for i in xrange(n):
f()
b=time()
print n/(b-a)
#
s=['abcd',u'\u548c\u6613\u541b'] * 1000
pf(lambda:''.join(s), 1)
2289.28293164
pf(lambda:text.join('',s), 1)
4457.27947763
s=['abcd'*1000,u'\u548c\u6613\u541b'*1000] * 1000
pf(lambda:''.join(s), 100)
15.2374868484
pf(lambda:text.join('',s), 100)
16.939913023
##
2012/8/1 Antoine Pitrou rep...@bugs.python.org
Antoine Pitrou added the comment:
Hi, several points:
- Python 2.7 is in bugfix mode; you need to work from the default
Mercurial branch as explained in http://docs.python.org/devguide/ . In
practice, this means your patch will target the future Python 3.4, and
therefore either PyUnicode_Join or _PyBytes_Join.
- please provide an actual patch (a Mercurial diff, probably)
- please provide benchmarks (using e.g. timeit) which demonstrate the
performance improvement you are proposing
--
nosy: +pitrou
versions: +Python 3.4 -Python 2.7
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15522
___
--
Added file: http://bugs.python.org/file26681/stringjoin.c
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15522
___# Author: Abael Heyijunhyj...@gmail.com
# Date: 2012-08-02
static PyObject *py_join(PyObject *self, PyObject *args){
PyObject *seprator=NULL; PyObject *sequence=NULL;
PyArg_ParseTuple(args, OO:join, seprator, sequence);
register PyObject *seq =PySequence_Fast(sequence, join() only accept list/tuple arguments );
const Py_ssize_t seqlen = PySequence_Fast_GET_SIZE(sequence);
if (seq == NULL || !PyString_Check(seprator) || seqlen 0)return NULL;
if (seqlen == 0){
Py_DECREF(seq);
return PyString_FromString();
}
register PyObject * item=NULL;
item = PySequence_Fast_GET_ITEM(seq, 0);
if (!PyString_Check(item)){
if (PyUnicode_Check(item)){
item=pyEncodeUTF8(self, item);
if (!PyString_Check(item))return PyErr_Format(PyExc_TypeError,sequence item %zd: expected string, %.80s found,0, Py_TYPE(item)-tp_name);
}else{
PyErr_Format(PyExc_TypeError,sequence item %zd: expected string, %.80s found,0, Py_TYPE(item)-tp_name);
Py_DECREF(seq);
return NULL;
}
}
if(seqlen == 1){
Py_INCREF(item);
return item;
}
const Py_ssize_t seplen = PyString_GET_SIZE(seprator);
const char *sep = PyString_AS_STRING(seprator);
register size_t isz=PyString_GET_SIZE(item);
size_t usz=isz, alloc=isz8192?isz:8192;
PyObject *res=PyString_FromStringAndSize(NULL, alloc);
register char *p =(char *)PyString_AS_STRING(res);
if(p==NULL)return NULL;
if (isz){
Py_MEMCPY(p, (char *)PyString_AS_STRING(item),isz);
p+=isz;
}
register Py_ssize_t i;
for (i=1; iseqlen; i++){
item = PySequence_Fast_GET_ITEM(seq,i);
if (!PyString_Check(item)){
if (PyUnicode_Check(item)){
item=pyEncodeUTF8(self, item);
if (!PyString_Check(item)){
PyErr_Format(PyExc_TypeError,sequence item %zd: transfer unicode to string, %.80s found,i, Py_TYPE(item)-tp_name);
return NULL;
}
}else{
PyErr_Format(PyExc_TypeError,sequence item %zd: expected string, %.80s found,i, Py_TYPE(item)-tp_name);
return NULL;
}
}
isz=PyString_GET_SIZE(item);
if(isz){
if (usz + seplen +iszalloc){
do {
alloc+=8192;
if (alloc1){
PyErr_SetString(PyExc_OverflowError,join() result is too long for a Python string);
return NULL;
}
}while (usz + seplen +iszalloc);
if (_PyString_Resize(res, alloc)0){
PyErr_SetString(PyExc_OverflowError,join() result is too long for a Python string);
return NULL;
}
p=(char *)PyString_AS_STRING(res)+usz;
}
if(seplen){
Py_MEMCPY(p, sep, seplen);
p+=seplen;
usz+=seplen;
}
Py_MEMCPY(p, (char *)PyString_AS_STRING(item),isz);
p +=isz;
usz +=isz;
}
}
Py_DECREF(seq);
if (_PyString_Resize(res, usz) 0){
PyErr_SetString(PyExc_OverflowError,join() result is too long for a Python string);
return NULL;
}
return res;
}
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15522] impove 27 percent performance on stringpbject.c( by prefetch and loop optimization)
Serhiy Storchaka added the comment: Please port your code to Python 3.3 and compare with it. Python 3.3 implementation of str.join() already more than twice faster then Python 2.7. Maybe your optimization will have no effect. -- nosy: +storchaka ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15522 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13498] os.makedirs exist_ok documentation is incorrect, as is some of the behavior
Hynek Schlawack added the comment: do you want it by default or a new flag? default sounds like a source for obscure bugs to me. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13498 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12655] Expose sched.h functions
Antoine Pitrou added the comment: Here is a patch removing cpu_set and using sets of integers instead. -- Added file: http://bugs.python.org/file26682/cpuset.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12655 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12655] Expose sched.h functions
Changes by Antoine Pitrou pit...@free.fr: Removed file: http://bugs.python.org/file26682/cpuset.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12655 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12655] Expose sched.h functions
Changes by Antoine Pitrou pit...@free.fr: Added file: http://bugs.python.org/file26683/cpuset.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12655 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14565] is_cgi doesn't function as documented for cgi_directories
Oscar Campos added the comment: Greetings, I did a diff patch based on the previous work of Glenn Linderman and Pierre Quentel. I did some test and is working well so now the implementation is doing what the docstring says. I already passed the full test suite without problems. I add two patches: CGIHTTPServer.patch is for Python 2.7 http-server.patch is for Python 3.2 This is my first contribution to the Python Core althrough I did follow the Developers Gruide and I already send my Contributor Agreement to the PSF maybe there is something I did wrong, if this is the case just tell me, I'm here to help and learn. Regards. Oscar Campos. -- keywords: +patch nosy: +oscar.campos Added file: http://bugs.python.org/file26684/CGIHTTPServer.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14565 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14565] is_cgi doesn't function as documented for cgi_directories
Changes by Oscar Campos oscar.cam...@member.fsf.org: Added file: http://bugs.python.org/file26685/http-server.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14565 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12655] Expose sched.h functions
STINNER Victor added the comment: sched_getaffinity() does not fail if the set is smaller than the number of CPU. Try with an initial value of ncpus=1. So we cannot start the heuristic with ncpus=16, because it would only return 16 even if the computer has more cpus. Instead of this heuristic, why not simply alway using ncpus = CPU_SETSIZE? I don't know if CPU_SETSIZE is part of the standard (POSIX?). You may also use a constant size (CPU_SETSIZE) of the set used by sched_setaffinity() to simplify the code. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12655 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14565] is_cgi doesn't function as documented for cgi_directories
Changes by Oscar Campos oscar.cam...@member.fsf.org: Added file: http://bugs.python.org/file26686/http-server.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14565 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12655] Expose sched.h functions
Antoine Pitrou added the comment:
Try with an initial value of ncpus=1.
Well, I've tried and it works:
os.sched_getaffinity(0)
{0, 1, 2, 3}
I don't know if CPU_SETSIZE is part of the standard (POSIX?).
These are Linux-specific functions.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12655
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12655] Expose sched.h functions
STINNER Victor added the comment:
Try with an initial value of ncpus=1.
Well, I've tried and it works:
Oh, you're right :-) I only checked ncpus (1), not the final result.
It works because CPU_ALLOC_SIZE() rounds the size using
sizeof(unsigned long) (64 bits on my CPU). So CPU_ALLOC_SIZE(1)
returns 8, and sched_getaffinity() takes the size of the set in bytes,
and not the number of CPU.
sched_getaffinity(0) returns {0, 1, 2, 3, 4, 5, 6, 7} with ncpus=1 and
setsize=8.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12655
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12655] Expose sched.h functions
Giampaolo Rodola' added the comment: +1 for Antoine's patch/approach: it's more usable and pythonic. I think documentation should mention and link the existence of: http://docs.python.org/library/multiprocessing.html#multiprocessing.cpu_count -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12655 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15546] Iteration breaks with bz2.open(filename,'rt')
Roundup Robot added the comment: New changeset cdf27a213bd2 by Nadeem Vawda in branch 'default': #15546: Fix BZ2File.read1()'s handling of pathological input data. http://hg.python.org/cpython/rev/cdf27a213bd2 -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15546 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15546] Iteration breaks with bz2.open(filename,'rt')
Nadeem Vawda added the comment: OK, BZ2File should now be fixed. It looks like LZMAFile and GzipFile may be susceptible to the same problem; I'll push fixes for them shortly. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15546 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12655] Expose sched.h functions
Serhiy Storchaka added the comment: You may also use a constant size (CPU_SETSIZE) of the set used by sched_setaffinity() to simplify the code. As Antoine pointed out to me (and I was convinced itself, experimented with an example from man:CPU_SET(3)) the cpu_set functions work with a sets of more than CPU_SETSIZE processors. -- nosy: +storchaka ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12655 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1859] textwrap doesn't linebreak on \n
Changes by Jesús Cea Avión j...@jcea.es: -- nosy: +jcea ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1859 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12655] Expose sched.h functions
Roundup Robot added the comment: New changeset d6745ddbccbd by Antoine Pitrou in branch 'default': Issue #12655: Instead of requiring a custom type, os.sched_getaffinity and http://hg.python.org/cpython/rev/d6745ddbccbd -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12655 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12655] Expose sched.h functions
Antoine Pitrou added the comment: Ok, I've improved the default ncpus value and committed. -- resolution: - fixed status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12655 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1859] textwrap doesn't linebreak on \n
Serhiy Storchaka added the comment:
I believe that the method of work with newlines is too application specific.
Someone may prefer empty line separated paragraphs, here is another recipe:
def wrap_paragraphs(text, width=70, **kwargs):
return [line for para in re.split(r'\n\s*\n', text) for line in
(textwrap.wrap(para, width, **kwargs) + [''])][:-1]
And here is another application-specific recipe:
def format_html_paragraphs(text, width=70, **kwargs):
return ''.join('p%s/p' % 'br'.join(textwrap.wrap(html.escape(para),
width, **kwargs)) para in re.split(r'\n\s*\n', text))
I don't see a one obvious way to solve this problem, so I suggest a recipe, not
a patch. In any case the specialized text-processing applications are not
likely to use textwrap because most output now uses non-monowidth fonts.
Textwrap is only for the simplest applications.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1859
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15555] Default newlines of io.TextIOWrapper
New submission from Atsuo Ishimoto: In http://docs.python.org/dev/library/io.html: if newline is None, any '\n' characters written are translated to the system default line separator, os.linesep. But os.linesep is not referred at all. On Windows default newline is always '\r\n' on Windows, '\n' otherwise. -- assignee: docs@python components: Documentation messages: 167413 nosy: docs@python, ishimoto priority: normal severity: normal status: open title: Default newlines of io.TextIOWrapper ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15556] os.stat fails for file pending delete on Windows
New submission from Jeremy Kloth: os.stat fails when called on a file that is pending delete but is still in the directory listing. This in turn causes os.path.exists to return the wrong result. Attached is a test case demonstrating this broken behavior. -- components: Library (Lib), Windows files: stat-bug.py messages: 167414 nosy: jkloth priority: normal severity: normal status: open title: os.stat fails for file pending delete on Windows versions: Python 3.3, Python 3.4 Added file: http://bugs.python.org/file26687/stat-bug.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15556 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15556] os.stat fails for file pending delete on Windows
Changes by Jeremy Kloth jeremy.kloth+python-trac...@gmail.com: -- nosy: +brian.curtin, loewis, pitrou, tim.golden -jkloth ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15556 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15556] os.stat fails for file pending delete on Windows
Changes by Jeremy Kloth jeremy.kloth+python-trac...@gmail.com: -- nosy: +jkloth ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15556 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15556] os.stat fails for file pending delete on Windows
Antoine Pitrou added the comment: How does it fail? Please paste the precise exception. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15556 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15556] os.stat fails for file pending delete on Windows
Jeremy Kloth added the comment:
Traceback (most recent call last):
File stat-bug.py, line 12, in module
print('stat', os.stat(pathname))
PermissionError: [Error 5] Access is denied: '\\Users\\Jeremy\\test.tmp'
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15556
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15556] os.stat fails for file pending delete on Windows
Martin v. Löwis added the comment: Why do you think the behavior is broken? It looks right to me - it's not possible to get file information for a file that is scheduled for deletion. ISTM that rather os.path.exists has non-intuitive behavior; it shouldn't infer from the PermissionError that the file does not exist, but that it is not able to tell. However, this is not a bug, but documented behavior, see http://docs.python.org/library/os.path.html#os.path.exists -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15556 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15528] Better support for finalization with weakrefs
Serhiy Storchaka added the comment: I don't quite understand the purpose of your suggestions. What can you do with it help, what you can not do with contextlib.ExitStack, atexit, __del__ method, weakref.WeakKeyDictionary or weakref.ref? I read the documentation, but the meaning eludes me. -- nosy: +storchaka ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15528 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15556] os.stat fails for file pending delete on Windows
Jeremy Kloth added the comment: Why do you think the behavior is broken? It looks right to me - it's not possible to get file information for a file that is scheduled for deletion. However you can when using MSVCRT's stat() function or even FindFirstFile directly. -- nosy: +jeremy.kloth ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15556 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14565] is_cgi doesn't function as documented for cgi_directories
Glenn Linderman added the comment: Thanks for the patch, Oscar, I've not had more time to follow up on this issue, and haven't yet learned how to generate the patches. While you dropped the return False line, which surprised me, the implicit return None is sufficiently false, that there no real concern with the correctness of the code in the patch. Hopefully, with your contribution, this issue can progress to completion. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14565 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15556] os.stat fails for file pending delete on Windows
Changes by Chris Jerdonek chris.jerdo...@gmail.com: -- nosy: +cjerdonek ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15556 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15550] Trailing white spaces
Chris Jerdonek added the comment: There already is a hook in place for the main python.org repository that checks for and rejects changesets that include files with space issues: If there is already a hook, then why do some files have spurious white space (i.e. at the end of a line)? Is that because those issues were present prior to putting the hook in place? -- nosy: +cjerdonek ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15550 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15544] math.isnan fails with some Decimal NaNs
Mark Dickinson added the comment: Why not add a is_nan() method to float numbers instead? That could work. The duplication of float.is_nan and math.isnan (not to mention the different spellings) would be a bit ugly, but perhaps worth it. It would make sense to add float.is_infinite and (possibly) float.is_finite methods at the same time. Looks like we've got two separate issues here, that should probably be split into two separate bug reports. The first issue is that Decimal.__float__ is brain-dead when it comes to NaNs with payloads; I consider that a clear bug, and Steven's patch fixes it nicely for the Python version of decimal. The second has to do with finding a nice type-agnostic way of determing whether something is a NaN---anyone mind if I open a separate issue for this? W.r.t. the first issue: Steven, thanks for the patch; looks fine to me at first glance. Two questions: (1) What would you think about raising ValueError explicitly for the signaling NaN case rather than falling back to the ValueError coming from the string-to-float conversion. I think the intentions of the code would be a little clearer that way; and we get to choose a more informative error message that way, too. (2) Should we apply the fix to 2.7 and/or 3.2 as well? I'll look at extending Steven's fix to the cdecimal code, unless Stefan really wants to do it (which would be fine with me :-). -- assignee: - mark.dickinson versions: +Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15544 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15557] Tests for webbrowser module
New submission from Anton Barkovsky: Attaching a patch with some tests for webbrowser module. The tests fail unless #15509 is fixed. They also print lots of warnings unless #15447 is fixed. -- components: Tests files: test_webbrowser.patch keywords: patch messages: 167423 nosy: anton.barkovsky, r.david.murray priority: normal severity: normal status: open title: Tests for webbrowser module versions: Python 3.3 Added file: http://bugs.python.org/file26688/test_webbrowser.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15557 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15447] A file is not properly closed by webbrowser._invoke
Anton Barkovsky added the comment: Added tests in #15557. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15447 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15509] webbrowser.open sometimes passes zero-length argument to the browser.
Anton Barkovsky added the comment: Added tests in #15557. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15509 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13052] IDLE: replace ending with '\' causes crash
Roundup Robot added the comment: New changeset 0f38948cc6df by Andrew Svetlov in branch '3.2': Issue #13052: Fix IDLE crashing when replace string in Search/Replace dialog ended with '\'. http://hg.python.org/cpython/rev/0f38948cc6df New changeset 9dcfba4d0357 by Andrew Svetlov in branch 'default': Issue #13052: Fix IDLE crashing when replace string in Search/Replace dialog ended with '\'. http://hg.python.org/cpython/rev/9dcfba4d0357 New changeset 44c00de723b3 by Andrew Svetlov in branch '2.7': Issue #13052: Fix IDLE crashing when replace string in Search/Replace dialog ended with '\'. http://hg.python.org/cpython/rev/44c00de723b3 -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13052 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15544] math.isnan fails with some Decimal NaNs
Stefan Krah added the comment:
Mark Dickinson rep...@bugs.python.org wrote:
Looks like we've got two separate issues here, that should probably be
split into two separate bug reports. The first issue is that
Decimal.__float__ is brain-dead when it comes to NaNs with payloads;
I consider that a clear bug, and Steven's patch fixes it nicely for
the Python version of decimal.
If we are viewing the whole issue in terms of decimal - float conversion,
I'm not so sure anymore: Not all Decimal payloads have a meaning for floats
(and payloads get lost in the conversion).
On the other hand it doesn't matter since I doubt anyone is using payloads. :)
The second has to do with finding a nice type-agnostic way of determing
whether something is a NaN---anyone mind if I open a separate issue for this?
Yes, that should probably be another issue.
Two questions: (1) What would you think about raising ValueError explicitly
for the signaling NaN case rather than falling back to the ValueError coming
from the string-to-float conversion.
If we use your latest rationale for raising in case of
Decimal('snan').__float__(),
I think that indeed __float__() should raise like Decimal.to_integral() does
for example.
If we are aiming for sNaN support in floats in the long term and at some point
allow carrying over sNaNs from decimal to float, then perhaps the error message
could say that sNaN conversion is currently not supported.
(2) Should we apply the fix to 2.7 and/or 3.2 as well?
Yes, I think so.
I'll look at extending Steven's fix to the cdecimal code, unless Stefan
really wants to do it (which would be fine with me :-).
Please go ahead! For this year, I've seen more than enough of _decimal.c
already. :)
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15544
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12655] Expose sched.h functions
Roundup Robot added the comment: New changeset fb975cb8fb45 by Victor Stinner in branch 'default': Issue #12655: Mention multiprocessing.cpu_count() in os.sched_getaffinity() doc http://hg.python.org/cpython/rev/fb975cb8fb45 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12655 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
