Removing an attribute from html with Regex
Hi all,
I have some HTML string which I would like to feed to BeautifulSoup.
But, One malformed attribute breaks BeautifulSoup.
My String
I would like it to replace all the occurances of that attribute with an
empty string.
I am unable to figure out the exact regex, which can do this job.
This is what, I have managed so far,
m = re.compile("rml_except='([^']*)")
As you see, it will stop at the first occurance of single quote.
Any suggestions will be useful.
--
Regards,
S.Selvam
SG E-ndicus Infotech Pvt Ltd.
http://e-ndicus.com/
" I am because we are "
--
http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter: The good, the bad, and the ugly!
On Wed, 29 Dec 2010 15:58:53 -0800, rantingrick wrote: > Tkinter: The good, the bad, and the ugly! > - > An expose by rantingrick Your ideas are intriguing to me and I wish to subscribe to your newsletter. > The answer is simple. We need a 100% Python GUI. A GUI coded in Python > from top to bottom. A GUI that is cross platform to the big three > (Windows, Linux, and Mac). A GUI that not only is easy as Tkinter but > also a GUI that can be manipulated by the average python programmer. A > GUI that not only teaches the fundamentals of using a GUI, but also a > GUI that teaches how a GUI works under the hood I look forward to seeing this software of yours. Let us know when you've got some code, and not just empty talk. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Building sys.path at run-time?
In article <87k4irhpoa@benfinney.id.au>, Ben Finney wrote: > Roy Smith writes: > > > I've got a problem that I'm sure many people have solved many times. > > > > Our project has a bunch of python scripts > > A very common problem. The solution is to switch to Perl. > > (Merry solstice silliness, everyone :-) I have another problem. I hit the "Post" button by accident. Please ignore. -- http://mail.python.org/mailman/listinfo/python-list
Re: Building sys.path at run-time?
Roy Smith writes: > I've got a problem that I'm sure many people have solved many times. > > Our project has a bunch of python scripts A very common problem. The solution is to switch to Perl. (Merry solstice silliness, everyone :-) -- \ “An idea isn't responsible for the people who believe in it.” | `\ —Donald Robert Perry Marquis | _o__) | Ben Finney -- http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter: The good, the bad, and the ugly!
1) pyjamas has a desktop version. 2) I don't consider JSONRpc to be a deal-breaker, and since that's what pyjamas uses naturally, and since it's incredibly easy to use the Python middleware of your choice for the JSONRpc server, running in different browsers is unlikely to be an issue. 3) I don't think legacy apps should be a consideration in deciding what tooling is going to be built today: building for all the yesterdays is a recipe for stagnation. Besides, the legacy apps have their own toolsets for maintenance: if they are to be converted, converting them to a form that can run anywhere (using, e.g., PhoneGap to access native UI hooks) seems to me the best choice. That said, pyjamas has only the beginnings of a visual designer (pyjsglade at http://sourceforge.net/projects/pyjsglade/). It's being written in Python, too, which should please you (as it does me -- so much so that I volunteered to be a documenter for the project). I think pyjamas combined with pyjsglade could be the foundation for a pythonic ui development environment that could carry us forward for many years to come, unlike those available today in Python. Hank PS: At first I thought you were going to do a riff on "The Plan" from years ago. I had broken 5 ribs in multiple places in a bicycling accident 2 days before when a friend faxed it to me (it was that far back): I can't tell you how much it hurt to laugh so hard. But this isn't a laughing matter: I see it as the main impediment to opening up Python to the kinds of programmers who used Access, VB6 and VFP to build the kinds of domain-knowledge-specific apps that continue to enhance many workplaces. -- http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter: The good, the bad, and the ugly!
On 30-12-2010 02:03, rantingrick wrote: > On Dec 29, 6:41 pm, Gerry Reno wrote: >> wxPython looks good but I don't see anyone developing support for things >> like smartphones. > No wx is not the answer to our problems Just partial ;-) Why not write a (Pythonic) wrapper and choose what will be under neat it ? My personal situation at this moment: * for desktop applications we basically use wxPython * the use of sizers in wxPython is not easy and full of cross-pointers with useless names. Therefor we already used a wrapper for wxPython. * for components missing in wxPython, we embed PySide-QT and Delphi components in wxPython * for server-side web applications we use web2py * for client-side web applications we use PyJamas * for mobile devices we use PocketPyGUI * as PySide-QT is making a huge progress at the moment and has improved licenses, (and might be usable for mobile devices) we might want to move gradually from wxPython to PySide-QT Right at this moment, I'm writing a new wrapper, that already can handle (in a simple way) wxPython and PySide-QT(partial). After this works fully, PyJamas and Web2pY will be added (PockectPyGui can probably fully be replaced by QT) cheers, Stef -- http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter: The good, the bad, and the ugly!
From: "Katie T" > What's your opinion of the other gui toolkits with Python bindings > like PyQt and PyGtk? > > Katie > -- They are not accessible at all for screen readers, so the programs that still use them won't be accessible to all potential users. Octavian -- http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter: The good, the bad, and the ugly!
From: "rantingrick" > Back in the early days of Python --when this simplistic beauty of > programming bliss we enjoy today was just a tiny glimmer of hope in a > archaic world plagued by dark forest of braces and jagged caverns of > cryptic syntaxes-- our beloved dictator (Mr. Van Rossum) had the > foresight to include a simplistic GUI toolkit that we call Tkinter > into the stdlib. And he saw that it was great, and that it was good, > and so he rested. Yes, for that time it was good. > Life was good, people were happy...but darkness loomed on the > horizon... Not all the people were happy because the darkness disappeared partially for some of them and more and more blind people started to use a computer, and discovered that the Tk interfaces are absolutely inaccessible for them. > The answer is simple. We need a 100% Python GUI. A GUI coded in Python > from top to bottom. A GUI that is cross platform to the big three > (Windows, Linux, and Mac). A GUI that not only is easy as Tkinter but > also a GUI that can be manipulated by the average python programmer. A > GUI that not only teaches the fundamentals of using a GUI, but also a > GUI that teaches how a GUI works under the hood So it should be a kind of SWING library made in Python, right? It is a good idea, but it should not have the problems of SWING and in that case it would be very hard to do. First, the interface should look exactly as the native interfaces for each system named, and it should provide the same features, because otherwise the interface would look strange for all the users on all the operating systems. And of course, it should not only look OK, but it should also follow the accessibility standards for beeing accessible for screen readers also. WxPython is the best GUI because it is fast, even though it is bloated, it uses the native GUI elements on all those 3 operating systems and a relatively good accessibility for screen readers. But WxPython still have problems because not all operating systems native GUIS offer the same widgets and features and those features custom-made don't respect the accessibility standards. WxPython is fast because it is made in C - it uses the native GUI elements of the OS which are also made in C. Would a Python - only GUI have the same speed? If yes, it would be great. Octavian -- http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter: The good, the bad, and the ugly!
On Dec 29, 6:41 pm, Gerry Reno wrote: > wxPython looks good but I don't see anyone developing support for things > like smartphones. No wx is not the answer to our problems > Also, what do you think about frameworks such as pyjamas? It lets you > write in python and compiles everything down to Javascript so it can be > used across the Web as well as on the desktop. Hmm, this is like two double edged swords smashing one another in battle. Sword One: On one hand web frameworks are going to be really big soon -- however legacy GUI's are not going away any time soon! Sword Two: On the other hand web frameworks provide awesome cross platform ability that is surly only going to get better as time goes -- however i utterly hate JavaScript (although much worse web languages exist!). And sending requests back and forth between Python, JavaScript, and BrowserX is also a real PITA. Because even though everyone knows this is coming all the major browsers are trying to insert their API into the mix. So that Joe Scripter has to write code that is compatible between many browsers. Until the world agrees on a unified API --AND IMPLEMENTS IT SERIOUSLY-- we are at the mercy of drunken sailors at the helm. I believe pyjamas has a bright future in the web playground, however we still need to focus our community efforts towards a Python based GUI. I can see a pythonGUI and pyjamas existing side by side in mutual harmony for many years. -- http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter: The good, the bad, and the ugly!
On 30 December 2010 00:58, rantingrick wrote: > > Tkinter: The good, the bad, and the ugly! > - > An expose by rantingrick > > > -- > The Good > -- > Back in the early days of Python --when this simplistic beauty of > programming bliss we enjoy today was just a tiny glimmer of hope in a > archaic world plagued by dark forest of braces and jagged caverns of > cryptic syntaxes-- our beloved dictator (Mr. Van Rossum) had the > foresight to include a simplistic GUI toolkit that we call Tkinter > into the stdlib. And he saw that it was great, and that it was good, > and so he rested. > > And when the first python programmers used this gift handed down from > the gods they were pleased. They could see that all of the heavy work > of cross-platform-ism landed square on the shoulders of TCL/Tk and all > Python had to do was wrap a few methods to wield the beast we all know > as graphical user interfaces. > > Life was good, people were happy...but darkness loomed on the > horizon... > > > > Enter the Bad > > However as we all know there exists no real Utopian bliss without many > pitfalls and snares. Since Tkinter is just a wrapping of some TclTk > calls the people realized that they are now at the perilous mercy of > another group of developers (psst: thats the TCL folks!) who have only > their own goals and dreams in mind and could care less for the > troubles of others. They realized that Tkinter was lacking. However > this lacking was not Tkinters fault, no, the fault lye with TclTk. And > to compound these problems they also realized that in order to fix the > design problems inherit in TclTk they must learn an obscure and mostly > useless language... TclTk!! > > > Utterly destroyed by the Ugly! > > And then the people became very angry... "What a double cross!" they > chanted. Why should we learn a language like TclTk just to fix > problems that the TclTk folks need to fix themselves? Would not that > time be more wisely spent in looking over code that is 100% Python and > modifying it? Not only would our community benefit but we can > propagate the maintainece and/or improvements to a wider group of > folks by removing the high entrance requirements. When we elevate > every python programmer to a PythonGUI maintainer then we will have > achieved community nirvana! > > We have now reached a point where the very simplicity we have embraced > (Tkinter) has become a stumbling block not only for the users of > Tkinter, but more devastating is the damage this TCL/Tk monkey has > done to keep our fellow Python brothers and sisters from learning how > a GUI kit works (behind the scenes) with each OS to bring all this > graphical stuff to life. > > > So what should we do? > > The answer is simple. We need a 100% Python GUI. A GUI coded in Python > from top to bottom. A GUI that is cross platform to the big three > (Windows, Linux, and Mac). A GUI that not only is easy as Tkinter but > also a GUI that can be manipulated by the average python programmer. A > GUI that not only teaches the fundamentals of using a GUI, but also a > GUI that teaches how a GUI works under the hood > > Then and only then will Python be truly what GvR intended. I want > everyone here to consider what i am proposing and offer some opinions > because it is time for change. > -- > http://mail.python.org/mailman/listinfo/python-list > A lot of ranting indeed... I agree that Tk has a few shortcomings (I never use it myself), but since many people are currently using it, I don't see an easy way of replacing Tk with anything else. FWIW, I like the ideas of FLTK (very lightweight, just draw all widgets itself + has good OpenGl support), although the project seems to have lost its momentum. I think that you are suggesting something like that, but written in Python. Almar -- http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter: The good, the bad, and the ugly!
wxPython looks good but I don't see anyone developing support for things like smartphones. Also, what do you think about frameworks such as pyjamas? It lets you write in python and compiles everything down to Javascript so it can be used across the Web as well as on the desktop. -- http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter: The good, the bad, and the ugly!
On 30.12.2010 00:58, rantingrick preached: Tkinter: The good, the bad, and the ugly! - An expose by rantingrick You are seriously starting to sound like Xah Lee. our beloved dictator (Mr. Van Rossum) had the foresight to include a simplistic GUI toolkit that we call Tkinter into the stdlib. And he saw that it was great, and that it was good, and so he rested. For a technocrat (and that's an insult, in my book), you have a really annoying bible-style type of speech (or do you just play too much WoW?). Would you please stop to consider your own, what 4 or 5, years of programming experience to be enough to judge on such reasons? Some thought-food for you: What other GUI toolkit even just *could* had been included by Pan, Jesus, Mohammed, Budda, or God herself? (it's *your* wording that makes me include such names) The answer is simple. We need a 100% Python GUI. How many times did you say that now? Have you done anything to archive that goal? Have you even tried to support existing projects? I'm going to bet my right arm, that you haven't. Then and only then will Python be truly what GvR intended. I must admit, you keep true with yourself and even advance on that. Now you not only claim to speech for the whole Python community, but for Guide himself. Sorry, but how megalomaniac are you? -- http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter: The good, the bad, and the ugly!
On Dec 29, 6:07 pm, Katie T wrote: > On Wed, Dec 29, 2010 at 11:58 PM, rantingrick wrote: > > What's your opinion of the other gui toolkits with Python bindings > like PyQt and PyGtk? Hello KateT, Well i like wxPython as it is quite well rounded but we all know it has some shortcomings too and wx is far too bloated for the stdlib! pyQt and pyGtk i cannot comment on because i have no experience with them. However i need to stress that my intention is towards a 100% Python GUI. Not a binding, not a wrapping (except for OS calls!) but a *real* Python GUI. The only thing that i know of at this point is pyGUI although there are probably others. Allowing the average Python programmer the ability to read OS specific calls written in Python would not only benefit their GUI knowledge, but also there knowledge of OS's in general. I guess you could sum it as "Getting the most bang for your community buck". -- http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter: The good, the bad, and the ugly!
On Wed, Dec 29, 2010 at 11:58 PM, rantingrick wrote: > > Then and only then will Python be truly what GvR intended. I want > everyone here to consider what i am proposing and offer some opinions > because it is time for change. What's your opinion of the other gui toolkits with Python bindings like PyQt and PyGtk? Katie -- CoderStack http://www.coderstack.co.uk/perl-jobs The Software Developer Job Board -- http://mail.python.org/mailman/listinfo/python-list
Tkinter: The good, the bad, and the ugly!
Tkinter: The good, the bad, and the ugly! - An expose by rantingrick -- The Good -- Back in the early days of Python --when this simplistic beauty of programming bliss we enjoy today was just a tiny glimmer of hope in a archaic world plagued by dark forest of braces and jagged caverns of cryptic syntaxes-- our beloved dictator (Mr. Van Rossum) had the foresight to include a simplistic GUI toolkit that we call Tkinter into the stdlib. And he saw that it was great, and that it was good, and so he rested. And when the first python programmers used this gift handed down from the gods they were pleased. They could see that all of the heavy work of cross-platform-ism landed square on the shoulders of TCL/Tk and all Python had to do was wrap a few methods to wield the beast we all know as graphical user interfaces. Life was good, people were happy...but darkness loomed on the horizon... Enter the Bad However as we all know there exists no real Utopian bliss without many pitfalls and snares. Since Tkinter is just a wrapping of some TclTk calls the people realized that they are now at the perilous mercy of another group of developers (psst: thats the TCL folks!) who have only their own goals and dreams in mind and could care less for the troubles of others. They realized that Tkinter was lacking. However this lacking was not Tkinters fault, no, the fault lye with TclTk. And to compound these problems they also realized that in order to fix the design problems inherit in TclTk they must learn an obscure and mostly useless language... TclTk!! Utterly destroyed by the Ugly! And then the people became very angry... "What a double cross!" they chanted. Why should we learn a language like TclTk just to fix problems that the TclTk folks need to fix themselves? Would not that time be more wisely spent in looking over code that is 100% Python and modifying it? Not only would our community benefit but we can propagate the maintainece and/or improvements to a wider group of folks by removing the high entrance requirements. When we elevate every python programmer to a PythonGUI maintainer then we will have achieved community nirvana! We have now reached a point where the very simplicity we have embraced (Tkinter) has become a stumbling block not only for the users of Tkinter, but more devastating is the damage this TCL/Tk monkey has done to keep our fellow Python brothers and sisters from learning how a GUI kit works (behind the scenes) with each OS to bring all this graphical stuff to life. So what should we do? The answer is simple. We need a 100% Python GUI. A GUI coded in Python from top to bottom. A GUI that is cross platform to the big three (Windows, Linux, and Mac). A GUI that not only is easy as Tkinter but also a GUI that can be manipulated by the average python programmer. A GUI that not only teaches the fundamentals of using a GUI, but also a GUI that teaches how a GUI works under the hood Then and only then will Python be truly what GvR intended. I want everyone here to consider what i am proposing and offer some opinions because it is time for change. -- http://mail.python.org/mailman/listinfo/python-list
gSOAP and Python/ctypes
For the moment onlly studied under Linux Fedora 13, here is a gSOAP + Python/ctypes + ctypesgen introduction available at http://vouters.dyndns.org/tima/Linux-gSOAP-C-Python-ctypes-Why_and_when_using_gSOAP-a_quick_introduction.html Hoping this will help some of you. -- http://mail.python.org/mailman/listinfo/python-list
Interrput a thread
Hi all, I need to stop a threaded (using CTR+C or kill) application if
it runs too much or if I decide to resume the work later.
I come up with the following test implementation but I wanted some
suggestion from you on how I can implement what I need in a better or
more pythonic way. Here the code:
import os
import signal
import time
from threading import Thread, current_thread
from queue import LifoQueue, Empty
COMMAND = {"STOP": 0, "NORMAL": 1}
THREAD_NUM = 5
lq = LifoQueue()
print("{0}\n".format(os.getpid()))
class InterceptInterrupt(Exception):
pass
class Handler:
def __init__(self, queue):
self._queue = queue
def __del__(self):
print("Bye bye!")
def getHandler(self, signum, frame):
print("Interrupt raised!")
for _ in range(THREAD_NUM):
self._queue.put((COMMAND["STOP"], None))
raise InterceptInterrupt
h = Handler(lq)
signal.signal(signal.SIGINT, h.getHandler)
for i in range(25):
lq.put((COMMAND["NORMAL"], i))
def do_work(queue):
while True:
time.sleep(5)
try:
cmd, value = queue.get(block=False)
if cmd == COMMAND["STOP"]:
print("{0}: STOP command
received!".format(current_thread().name))
break
elif cmd == COMMAND["NORMAL"]:
print(value)
except Empty:
break
threads = [Thread(target=do_work, args=(lq,)) for _ in
range(THREAD_NUM)]
for t in threads:
t.start()
while not lq.empty():
try:
time.sleep(1)
except (IOError, InterceptInterrupt):
break
for t in threads:
t.join()
if lq.empty():
print("The queue is empty.")
else:
print("The queue is NOT empty. Some additional work has to be
done.")
Thank you,
Mattia
--
http://mail.python.org/mailman/listinfo/python-list
Re: Does Python 3.1 accept \r\n in compile()?
On 12/29/2010 4:06 PM, jmfauth wrote:
On 29 Dez., 21:14, Terry Reedy wrote:
On 12/29/2010 2:31 PM, Terry Reedy wrote:
"Changed in version 3.2: Allowed use of Windows and Mac newlines. Also
input in 'exec' mode does not have to end in a newline anymore. Added
the optimize parameter."
Retest shows that above is correct.
>>> compile("print(999)\r\n", "blah", "exec")
at 0x00F5EC50, file "blah", line 1>
Ok, I see. Thanks.
The '\r\n' acceptance has been introduced in Python 2.7
and I was a little bit suprised with Python 3.1.
2.6 was followed by 3.0 and then 3.1.
2.7 will be followed by 3.2 in a couple more month.
That feature was added to 2.7 and 3.2 in Nov 2009 long after 3.1.
--
Terry Jan Reedy
--
http://mail.python.org/mailman/listinfo/python-list
Re: Does Python 3.1 accept \r\n in compile()?
On 29 Dez., 21:14, Terry Reedy wrote:
> On 12/29/2010 2:31 PM, Terry Reedy wrote:
>
> > "Changed in version 3.2: Allowed use of Windows and Mac newlines. Also
> > input in 'exec' mode does not have to end in a newline anymore. Added
> > the optimize parameter."
>
> Retest shows that above is correct.
>
> >>> compile("print(999)\r\n", "blah", "exec")
>
> at 0x00F5EC50, file "blah", line 1>
>
Ok, I see. Thanks.
The '\r\n' acceptance has been introduced in Python 2.7
and I was a little bit suprised with Python 3.1.
For the story, I'm not using directly the compile()
command, but something like:
.runsource(source)
where source is coming from a GUI toolkit text widget.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Does Python 3.1 accept \r\n in compile()?
On 12/29/2010 2:31 PM, Terry Reedy wrote:
"Changed in version 3.2: Allowed use of Windows and Mac newlines. Also
input in 'exec' mode does not have to end in a newline anymore. Added
the optimize parameter."
Retest shows that above is correct.
>>> compile("print(999)\r\n", "blah", "exec")
at 0x00F5EC50, file "blah", line 1>
For most development purposes (not just yours), 3.2b2 is already better
than 3.1.
Terry Jan Reedy
--
http://mail.python.org/mailman/listinfo/python-list
Re: Does Python 3.1 accept \r\n in compile()?
On 12/29/2010 11:07 AM, jmfauth wrote:
I wrote miscellaneous interactive interpreters and
I fall on this.
In Python 2.7 (understand Python> 2.6), a source code
can be compiled with "native" '\r\n' as eol.
I am a bit surprised, but I presume this is one on many
back-compatibility holdovers still in 2.7. I believe 2.7 normally reads
input with universal newline support, so that line endings are fixed on
input, where they should be. Within Python, 'newline' is '\n'.
In Python 3.1, it does not seem to be the case.
In 3.0, there were many simplifications where old things got dropped.
(Python 3.2.a/b not checked).
I have not heard of any change. The compile() entry has the following:
"Changed in version 3.2: Allowed use of Windows and Mac newlines. Also
input in 'exec' mode does not have to end in a newline anymore. Added
the optimize parameter."
The second and third statement are true, but
>>> compile('print(999)\r\n', '', 'exec')
Traceback (most recent call last):
File "", line 1, in
compile('print(999)\r\n', '', 'exec')
File "", line 1
print(999)
^
SyntaxError: invalid syntax
I will inquire on pydev.
Bug, regression, deliberate choice?
I presume deliberate simplification, but you can wait for another answer
or check svn logs of the appropriate source file.
Or there might be an entry in 3.0 NEWS or What's New files.
--
Terry Jan Reedy
--
http://mail.python.org/mailman/listinfo/python-list
PyUSB 1.0.0 alpha 1 release
Dear all, PyUSB 1.0.0 alpha 1 is out. Since alpha 0, this version : - Standard control requests through usb.control module. - String descriptors through usb.util module. - Complete PyUSB 0.4 API emulation. - Working libusb 1.0 support under Windows. For details check the ReleaseNotes.txt and ChangeLog files. This version can be download through sourceforge: https://sourceforge.net/projects/pyusb/files/PyUSB%201.0/1.0.0-alpha-1/ For further information about PyUSB visit the project website: http://pyusb.sourceforge.net -- Best Regards, Wander Lairson Costa LCoN - Laboratório de Computação Natural - Natural Computing Laboratory (http://www.mackenzie.com.br/lcon.html) Programa de Pós-Graduação em Engenharia Elétrica (PPGEE) Faculdade de Computação e Informática (FCI) Universidade Presbiteriana Mackenzie - SP - Brazil -- http://mail.python.org/mailman/listinfo/python-list
Python 3 and SNMP Traps
All: I'm using Python 3.1.3 and need to incorporate sending SNMP traps from my script. I've researched and I found pysnmp and net-snmp with python bindings. The first appears to be only for Python 2.x. The second I'm not certain about. Has anyone experience with this and able to give suggestions? Thanks, Joe -- http://mail.python.org/mailman/listinfo/python-list
Re: Trying to parse a HUGE(1gb) xml file
maybe you can try http://vtd-xml.sourceforge.net/ -- http://mail.python.org/mailman/listinfo/python-list
Does Python 3.1 accept \r\n in compile()?
I wrote miscellaneous interactive interpreters and
I fall on this.
In Python 2.7 (understand Python > 2.6), a source code
can be compiled with "native" '\r\n' as eol.
In Python 3.1, it does not seem to be the case.
(Python 3.2.a/b not checked).
Bug, regression, deliberate choice?
>>> sys.version
2.7.1 (r271:86832, Nov 27 2010, 18:30:46) [MSC v.1500 32 bit
(Intel)]
>>> compile('if True:\nprint 999\n', '', 'exec')
at 02858DA0, file "", line 1>
>>> compile('if True:\r\nprint 999\r\n', '', 'exec')
at 02858E30, file "", line 1>
>>> exec(compile('if True:\r\nprint 999\r\n', '', 'exec'))
999
>>> sys.version
'3.1.2 (r312:79149, Mar 21 2010, 00:41:52) [MSC v.1500 32 bit
(Intel)]'
compile('if True:\nprint(999)\n', '', 'exec')
at 0x01FE5458, file "", line 2>
>>> exec(compile('if True:\nprint(999)\n', '', 'exec'))
999
>>> # this fails
>>> compile('if True:\r\nprint(999)\r\n', '', 'exec')
Traceback (most recent call last):
File "", line 1, in
File "", line 1
if True:
^
SyntaxError: invalid syntax
--
http://mail.python.org/mailman/listinfo/python-list
Tiny4py, a little python wrapper to make shorten urls and QRCodes
Hi, I would announce you my new python wrapper to make shorten urls and QRCodes, using main used services: goo.gl, bit.ly and tinyurl. Please, visit http://code.google.com/p/tiny4py/ Bests -- http://mail.python.org/mailman/listinfo/python-list
ANN: MyNewspaper v3.0
Hi there, I'm really pleased to announce a new release of MyNewspaper, a web-based personal RSS aggregator and feeds reader. Although no public releases in last years, I've been improving MyNewspaper continually for my personal use, but I think it's the time to publish it again. Some technical points of interest: - backend based on CherryPy web framework, FeedParser, SQLObject, SQLite - frontend with javascript (jQuery, jQueryUI, jQuery-mobile) More information, complete requirements and download link at: [main] https://inigo.katxi.org/devel/mynewspaper/ [mirror] http://www.terra.es/personal7/inigoserna/mynewspaper/ Of course, all comments, suggestions etc. are welcome. Best regards, Iñigo Serna -- http://mail.python.org/mailman/listinfo/python-list
Re: Making urllib2's POST 302 handle same as Perl LWP's behaviour
I have tried:
In httpd.conf:
Redirect /one/ http://localhost/two/
Redirect /two/ http://localhost/three/
redirect /three/ http://www.google.com/
Then I made a POST request with LWP::UserAgent to /one:
use LWP::UserAgent;
print LWP::UserAgent->new->post('http://localhost/one/')->as_string;
And the result was:
HTTP/1.1 302 Found
Connection: close
Date: Wed, 29 Dec 2010 13:58:37 GMT
Location: http://localhost/two/
Server: Apache/2.2.15 (Win32) mod_perl/2.0.4-dev Perl/v5.10.1
...
Exactly as you described.
Then I made a POST request with WWW::Mechanize:
use WWW::Mechanize;
print WWW::Mechanize->new->post('http://localhost/one/')->as_string;
And the result was:
HTTP/1.1 200 OK
Cache-Control: private, max-age=0
Connection: close
Date: Wed, 29 Dec 2010 14:00:44 GMT
Server: gws
So it seems that LWP::UserAgent works similarly with mechanize and
WWW::Mechanize similarly to urllib. Nice. :-)
Octavian
- Original Message -
From: "Karra"
Newsgroups: comp.lang.python
To:
Sent: Wednesday, December 29, 2010 2:35 PM
Subject: Re: Making urllib2's POST 302 handle same as Perl LWP's behaviour
On Dec 29, 3:57 pm, Karra wrote:
> Can someone point me to how I can get the default LWP:UserAgent
> behaviour of handling this scenario using urllib2?
Out of frustration, I decided to give 'mechanize' a try. It came as an
awesome surprise that mechanize implements the exact api of urllib2 -
meaning all I had to do was a query-replace of urllib2 to mechanize,
and lo-and-behold I got what I wanted!
Which is to say, the behaviour of mechanize matches Perl's
LWP::UserAgent as afar as handling of POST redirects go.
--
http://mail.python.org/mailman/listinfo/python-list
--
http://mail.python.org/mailman/listinfo/python-list
Re: Making urllib2's POST 302 handle same as Perl LWP's behaviour
On Dec 29, 3:57 pm, Karra wrote: > Can someone point me to how I can get the default LWP:UserAgent > behaviour of handling this scenario using urllib2? Out of frustration, I decided to give 'mechanize' a try. It came as an awesome surprise that mechanize implements the exact api of urllib2 - meaning all I had to do was a query-replace of urllib2 to mechanize, and lo-and-behold I got what I wanted! Which is to say, the behaviour of mechanize matches Perl's LWP::UserAgent as afar as handling of POST redirects go. -- http://mail.python.org/mailman/listinfo/python-list
Re: O'Reilly Python Certification
At Tue, 28 Dec 2010 20:07:29 + (UTC), J. Altman wrote: > > I have a general question. > > Does it seem odd that a certificate in Python, an Open Source > language; taught at O'Reilly, which offers an Open Source Programming > Certificate and is something like waist-deep in Open Source > publishing; is offered to the world at large but only (IIUC) if one > runs some version of Windows by MS? > > Based on what I am given to understand from my correspondence with > OST, it seems that I *must* install an instance of Windows to take the > certificate's courses. This is not true. You can take the course on any operating system that supports a RDP client. I am enrolled with in the python course and I use GNU/Linux. They even have instructions on their website on how to configure it. I would have preferred them to use a UNIX shell. I'm still waiting for somebody to come up with a course that teaches me a programming language, while teaching me a VCS and allows me to write code and submit to a repo with other students contributing. You want to bring people into F/OSS -- That is how you do it! The complaint that I do have with OST (at least the Python course) and the reason I have not completed (or even worked on the course in almost a year) it, is that its just plain boring. It's almost 2011! Give me some interactive flash, a video, something. Reading some pages of dry text just doesn't cut it for me. I can do that on my own. If I'm going to pay for a course I want a teacher that is going to teach me something. I can buy plenty of books and read them. The entire course is just plain dry text. I don't even remeber seeing an image diagram. On top of that the text is horribly ugly to look at. -- http://mail.python.org/mailman/listinfo/python-list
Re: O'Reilly Python Certification
At Tue, 28 Dec 2010 20:07:29 + (UTC), J. Altman wrote: > > I have a general question. > > Does it seem odd that a certificate in Python, an Open Source > language; taught at O'Reilly, which offers an Open Source Programming > Certificate and is something like waist-deep in Open Source > publishing; is offered to the world at large but only (IIUC) if one > runs some version of Windows by MS? > > Based on what I am given to understand from my correspondence with > OST, it seems that I *must* install an instance of Windows to take the > certificate's courses. This is not true. You can take the course on any operating system that supports a RDP client. I am enrolled with in the python course and I use GNU/Linux. They even have instructions on their website on how to configure it. I would have preferred them to use a UNIX shell. I'm still waiting for somebody to come up with a course that teaches me a programming language, while teaching me a VCS and allows me to write code and submit to a repo with other students contributing. You want to bring people into F/OSS -- That is how you do it! The complaint that I do have with OST (at least the Python course) and the reason I have not completed (or even worked on the course in almost a year) it, is that its just plain boring. It's almost 2011! Give me some interactive flash, a video, something. Reading some pages of dry text just doesn't cut it for me. I can do that on my own. If I'm going to pay for a course I want a teacher that is going to teach me something. I can buy plenty of books and read them. The entire course is just plain dry text. I don't even remeber seeing an image diagram. On top of that the text is horribly ugly to look at. -- http://mail.python.org/mailman/listinfo/python-list
Re: O'Reilly Python Certification
At Tue, 28 Dec 2010 20:07:29 + (UTC), J. Altman wrote: > > I have a general question. > > Does it seem odd that a certificate in Python, an Open Source > language; taught at O'Reilly, which offers an Open Source Programming > Certificate and is something like waist-deep in Open Source > publishing; is offered to the world at large but only (IIUC) if one > runs some version of Windows by MS? > > Based on what I am given to understand from my correspondence with > OST, it seems that I *must* install an instance of Windows to take the > certificate's courses. This is not true. You can take the course on any operating system that supports a RDP client. I am enrolled with in the python course and I use GNU/Linux. They even have instructions on their website on how to configure it. I would have preferred them to use a UNIX shell. I'm still waiting for somebody to come up with a course that teaches me a programming language, while teaching me a VCS and allows me to write code and submit to a repo with other students contributing. You want to bring people into F/OSS -- That is how you do it! The complaint that I do have with OST (at least the Python course) and the reason I have not completed (or even worked on the course in almost a year) it, is that its just plain boring. It's almost 2011! Give me some interactive flash, a video, something. Reading some pages of dry text just doesn't cut it for me. I can do that on my own. If I'm going to pay for a course I want a teacher that is going to teach me something. I can buy plenty of books and read them. The entire course is just plain dry text. I don't even remeber seeing an image diagram. On top of that the text is horribly ugly to look at. -- http://mail.python.org/mailman/listinfo/python-list
Re: Interning own classes like strings for speed and size?
Christian Heimes writes:
> You are right as long as you don't try to rebind the variable.
And then only if you assign through an instance, which doesn't make
sense for a class-level cache. Assignment like Example2._cache = {}
would work.
--
http://mail.python.org/mailman/listinfo/python-list
Re: etl tool!!!!!
BOn Dec 28, 1:14 pm, Stefan Sonnenberg-Carstens wrote: > Am 28.12.2010 13:57, schrieb krishna kumar:> Is there any efficient etl tool > developed in python? > > Yes, Python. I use SQLAlchemy for both sources and targets, just because I hate to type sql queries :-) I am convincing clients to ditch solutions such informatica and talend in favour of plain python. I don't understand the mentality that learning an ETL graphical tool can be easier than learning a programming language, why don't just hire programmers and teach them business, after all, programmers are cheaper and often more intelligent. -- http://mail.python.org/mailman/listinfo/python-list
Making urllib2's POST 302 handle same as Perl LWP's behaviour
I am doing a POST to a webserver and get a 302 Found response (redirect). urllib2's default behaviour is to do a GET on the new url from the Location: URI in the 302 response. This is different from what I have found with LWP::UserAgent- >request() in perl. After much searching I understand there is a view that automatic redirection for a 302 in response to a POST is not in conformance to the relevant RFCs. Therefore, I believe urllib2's behaviour appears to be non-conformant (as, I believe are many browsers). Now, regardless of what is the "correct" approach to handling the 302, there is some information in the returned html of the 302 which I am losing because of the subsequent GET. I tried to raise a HTTPError from redirect_request() but that just kills the connection with the server. I tried returning None, same result. Can someone point me to how I can get the default LWP:UserAgent behaviour of handling this scenario using urllib2? -- http://mail.python.org/mailman/listinfo/python-list
Re: round in 2.6 and 2.7
On Dec 28, 9:47 pm, "Martin v. Loewis" wrote:
> >> "Float-to-string and string-to-float conversions are correctly rounded.
> >> The round() function is also now correctly rounded."
>
> >> Not sure that this is correct English; I think it means that the
> >> round() function is now correct.
>
> > Well, the correct result of the example the OP gave would be 9.9
> > exactly. But since 9.9 isn't exactly representable as a Python float,
> > we necessarily get an approximation. The language above is intended
> > to convey that it's the 'correctly rounded' approximation
>
> I see. Shouldn't it say then "The round() function
> gives/produces/returns correctly rounded results now", instead of saying
> that
> the round function *is* correctly rounded? ISTM that the round
> function cannot be rounded (correctly or not):
>
> py> round(round)
> Traceback (most recent call last):
> File "", line 1, in
> TypeError: a float is required
>
> But then, I'm not a native speaker (of English).
I dare say that you're just as much a native speaker as anyone else
when it comes to the language of floating-point arithmetic. Not sure
English comes into it that much. :-)
Sure, I agree it's probably a slight abuse of language to refer to a
function as 'correctly rounded', but I think it's a fairly standard
abuse. From the two nearest references to hand: IEEE 754-2008 has a
whole section entitled 'Recommended correctly rounded functions' (nit:
shouldn't there be a hyphen in that title?), and persists in referring
to 'correctly rounded' conversions. The more formal uses in that
document do indeed refer to single values, though. ("A conforming
function shall return results correctly rounded ...") The 'Handbook of
Floating-Point Arithmetic' by Muller et. al. gives a definition of a
correctly rounded function in section 2.2. "When the exact result of
a function is rounded according to a given rounding mode ..., one says
that the function is *correctly rounded*."
It's not so dissimilar from other mathematical abuses, like describing
a real-valued function as 'positive', when what you actually mean is
that all its values are positive.
It's also slightly unsettling usage for me, not least because the
statement 'f is correctly rounded' for a floating-point function f is
really a statement about *two* functions: namely, f (a function from
floating-point numbers to floating-point numbers) and the true
mathematical function that it's based on; the identity of the
underlying mathematical function is left implicit.
--
Mark
--
http://mail.python.org/mailman/listinfo/python-list
A wrap for a multi-tabbed terminal. Some questions
http://pastie.org/763792/wrap This in IMHO, a really useful piece of code, to wrap and run terminal commands, on a gtk+vte python based gui. I would to make some improvements, in order to wrap some terminal applications. How can SET_FOCUS (at start) to the first vte frame? (Avoiding to click on terminal to get focus) How can fork a command thru the menus? thank you, Steve, -- http://mail.python.org/mailman/listinfo/python-list
Re: Noob question on 2 vs 3 Python releases
Franck Ditter writes: > Pardon my noobness (?) but why is there a 2.x and 3.x development > teams working concurrently in Python ? Well, Python 2.7 is the last major 2.x release, only bugfixes are done for it, like the 2.7.1 release. Actual developement is in the 3.x branch now. > Which one should I choose to start with, to cope with > the future ? I started with a good book covering both. The basics are mostly the same anyways. -- http://mail.python.org/mailman/listinfo/python-list
Re: NameError: global name 'btn_Matlab' is not defined ?
On 28-12-2010 15:15, Steven D'Aprano wrote: > On Tue, 28 Dec 2010 14:34:19 +0100, Stef Mientki wrote: > >> hello, >> >> Never seen this before and I've no explanation whatsoever (Python 2.6) >> >> I've some dynamic generated code, >> one of objects generated is a wx.Button, called 'btn_Matlab'. > How do you generate the code? > > What code is generated? What does it do? > > >> After the code is generated, I can see that the button is created in the >> local namespace >> >>print locals()['btn_Matlab'] >> >> > 0x3602d28> > >> >> but if I try to print the button (at exactly the same location), I get >> an error >> >> print btn_Matlab >> >> NameError: global name 'btn_Matlab' is not defined ? >> >> Why isn't the compiler first checking the local namespace ? any clues ? > > My guess is that you've declared btn_Matlab as global, and then > dynamically created a local with the same name using exec or similar. thanks Stevem, I found a solution. I indeed tried to "inject" local variables from a stack a few levels deeper, which doesn't seem to be possible (or reliable). The documentation isn't overwhelming about that point, exec and eval doesn't mention anything, but execfile warms for this issue. The code now looks something like this: self.p_locals = sys._getframe ( StackUp ).f_locals self.p_globals = sys._getframe ( StackUp ).f_globals Component = eval ( defi[1], self.p_globals, self.p_locals ) ( Parent, **Extra ) self.p_globals[ 'Component' ] = Component if 'self' in defi[0] : exec ( '%s = Component' %( defi[0] ), self.p_globals, self.p_locals ) else : exec ( '%s = Component' %( defi[0] ), self.p_globals) cheers, Stef -- http://mail.python.org/mailman/listinfo/python-list
