Re: how to get character hex number?
On 01/09/2012 04:50, Tim Chase wrote:
Well, in 3.1.3 at least, using the u"..." notation dies on me with
an invalid syntax. However, as Ian suggests, you can do
my_str = "english"
"".join("%02x" % c for c in my_str.encode("ascii"))
or whatever other encoding you want instead of "ascii".
-tkc
The u"..." notation has been reintroducd for Python 3.3 see
http://docs.python.org/dev/whatsnew/3.3.html#pep-414-explicit-unicode-literals
--
Cheers.
Mark Lawrence.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter bug in Entry widgets on OS X
On Friday, 31 August 2012, Dennis Lee Bieber wrote: > On Fri, 31 Aug 2012 15:41:01 GMT, Alister > > > > declaimed the following in gmane.comp.python.general: > > > I agree that it is unexpected in a single line entry box but isn't the > 1st > > rule of user interface design to assume the user is a moron & will do > > things they are not supposed to do? > > > > Therefore invalid inputs should be handled gracefully (not just insert > > random characters) which is what I think the original poster is > > suggesting. > > To which I'd suggest the programmer (vs the user), probably needs > to > code some sort of per-character validation check... After all, there may > be situations where accepting pretty much any key-code is desired, and > if the widget filters characters before they get to the programmer level > that becomes impossible. > > It would be good if I could intercept the key press event and cancel its action on the Entry widget. It's easy to intercept the key event, but I haven't found out how to prevent the funny characters from being inserted into the Entry widget input area. I've struggled to find good tkinter docs on the web. > caveat -- I've only written one simple form using Tkinter, so what > do I know... It's about as much as I've done! -- Arnaud -- http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter bug in Entry widgets on OS X
Arnaud Delobelle wrote:
> On Friday, 31 August 2012, Dennis Lee Bieber wrote:
>
>> On Fri, 31 Aug 2012 15:41:01 GMT, Alister
>>
>> >
>> declaimed the following in gmane.comp.python.general:
>>
>> > I agree that it is unexpected in a single line entry box but isn't the
>> 1st
>> > rule of user interface design to assume the user is a moron & will do
>> > things they are not supposed to do?
>> >
>> > Therefore invalid inputs should be handled gracefully (not just insert
>> > random characters) which is what I think the original poster is
>> > suggesting.
>>
>> To which I'd suggest the programmer (vs the user), probably needs
>> to
>> code some sort of per-character validation check... After all, there may
>> be situations where accepting pretty much any key-code is desired, and
>> if the widget filters characters before they get to the programmer level
>> that becomes impossible.
>>
>>
> It would be good if I could intercept the key press event and cancel its
> action on the Entry widget. It's easy to intercept the key event, but I
> haven't found out how to prevent the funny characters from being inserted
> into the Entry widget input area.
Untested as I have no Mac:
import Tkinter as tk
def suppress(event):
if event.keycode in {111, 116}:
print "ignoring", event.keycode
return "break"
print event.keycode, "accepted"
root = tk.Tk()
entry = tk.Entry(root)
entry.bind("", suppress)
entry.pack()
root.mainloop()
> I've struggled to find good tkinter
> docs on the web.
For my (basic) needs I keep coming back to
http://infohost.nmt.edu/tcc/help/pubs/tkinter/
--
http://mail.python.org/mailman/listinfo/python-list
Re: how to get character hex number?
On 09/01/12 03:49, Mark Lawrence wrote: > On 01/09/2012 04:50, Tim Chase wrote: >> Well, in 3.1.3 at least, using the u"..." notation dies on me with >> an invalid syntax. > > The u"..." notation has been reintroducd for Python 3.3 Nice to know--it makes writing backwards compat. code just a bit easier, even if it is a NOOP. I'll catch it when Debian Stable makes it there (currently at 3.1). -tkc -- http://mail.python.org/mailman/listinfo/python-list
Re: to know binary
On 2012-09-01 06:15, contro opinion wrote: there is a only line in the file nanmed test: 1234 when i open it whit xxd xxd test what i get is : 000: 3132 3334 0a 1234. can you explain it ? At offset zero (00): chr(0x31) + chr(0x32)+ chr(0x33)+ chr(0x33)+ chr(0x0a) = '1'+'2'+'3'+'4'+'.' = '1234.' Does it have to do ANYTHING with Python? If I were you, and it was something that must be explained, then I would rather start books about programming before asking questions on a mailing list that is not related to my question. -- http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter bug in Entry widgets on OS X
On 1 September 2012 11:30, Peter Otten <[email protected]> wrote: > Arnaud Delobelle wrote: >> It would be good if I could intercept the key press event and cancel its >> action on the Entry widget. It's easy to intercept the key event, but I >> haven't found out how to prevent the funny characters from being inserted >> into the Entry widget input area. > > Untested as I have no Mac: > > import Tkinter as tk > > def suppress(event): > if event.keycode in {111, 116}: > print "ignoring", event.keycode > return "break" > print event.keycode, "accepted" > > root = tk.Tk() > entry = tk.Entry(root) > entry.bind("", suppress) > entry.pack() > > root.mainloop() This works fine! return "break" is the piece of knowledge that I was missing. Thanks a lot! In fact I lied a bit in my original message - I do use the UP and DOWN arrows on one Entry widget for navigating its command history. To do this I was binding the "" and "" events to a function, which simply has to return "break" to work around the bug. On other Entry widgets, I just bind "" and "" to a suppress function which simply returns "break". >> I've struggled to find good tkinter >> docs on the web. > > For my (basic) needs I keep coming back to > > http://infohost.nmt.edu/tcc/help/pubs/tkinter/ Thanks for the link. I was using the docs on effbot which are nice but probably incomplete (and old). I guess I should flag up this bug but I don't even know if it's a Python or Tk problem and have little time or expertise to investigate. -- Arnaud -- http://mail.python.org/mailman/listinfo/python-list
Re: Looking for an IPC solution
> There are just so many IPC modules out there. I'm looking for a > solution for developing a new a multi-tier application. The core > application will be running on a single computer, so the IPC should > be using shared memory (or mmap) and have very short response times. Probably the fastest I/RPC implementation for Python should be OmniOrbpy: http://omniorb.sourceforge.net/ It's cross-platform, language-independent and standard-(Corba-) compliant. > I have seen a stand alone cross platform IPC server before that could > serve "channels", and send/receive messages using these channels. But > I don't remember its name and now I cannot find it. Can somebody > please help? If it's just for "messaging", Spread should be interesting: http://www.spread.org/ Also cross-platform & language-independent. Sincerely, Wolfgang -- http://mail.python.org/mailman/listinfo/python-list
Twisted 12.2.0 released
On behalf of Twisted Matrix Laboratories, I am honored to announce the release of Twisted 12.2. Highlights for this release include: * To be able to work on Python3 support, Python 2.5 is no longer supported. * twisted.mail.imap4 now serves BODYSTRUCTURE responses which provide more information and conform to the IMAP4 RFC more closely. * twisted.conch now supports commercial SSH implementations which don't comply with the IETF standard. * twisted.internet.endpoints now provides several new endpoints, including a TCP client endpoint that resolves hostnames to IPv6 host addresses. * IReactorSocket.adoptStreamConnection, implemented by some reactors, allows adding an existing established connection to the reactor. Starting with the release after 12.2, Twisted will begin requiring zope.interface 3.6 (as part of Python 3 support). This is the last Twisted release supporting Python 2.6 on Windows. For more information, see the NEWS file here: http://twistedmatrix.com/Releases/Twisted/12.2/NEWS.txt Download it now from: http://pypi.python.org/packages/source/T/Twisted/Twisted-12.2.0.tar.bz2 or http://pypi.python.org/packages/2.6/T/Twisted/Twisted-12.2.0.win32-py2.6.exe or http://pypi.python.org/packages/2.6/T/Twisted/Twisted-12.2.0.win32-py2.6.msi or http://pypi.python.org/packages/2.7/T/Twisted/Twisted-12.2.0.win32-py2.7.exe or http://pypi.python.org/packages/2.7/T/Twisted/Twisted-12.2.0.win32-py2.7.msi Thanks to the supporters of Twisted and to the many contributors for this release. -- Ashwini Oruganti -- http://mail.python.org/mailman/listinfo/python-list
Re: interfacing with x86_64 assembler
On Friday, 31 August 2012 19:28:11 UTC+5:30, Grant Edwards wrote: > On 2012-08-31, Mark Lawrence wrote: > > > On 31/08/2012 14:40, lipska the kat wrote: > > > > >> I was hacking away at some x86_64 assembler today > > >> when I found myself obsessively indenting my code > > >> by EXACTLY 4 spaces or (multiples thereof) > > > > > What's wrong with structured assembler? :) > > > > Nothing -- it's called "C". > > > > -- > > Grant Edwards grant.b.edwardsYow! Not SENSUOUS ... only > > at "FROLICSOME" ... and in > > gmail.comneed of DENTAL WORK ... in > >PAIN!!! Very much true. In fact C is by definition assembly (as the creators just added whatever features the machine supported to C) -- http://mail.python.org/mailman/listinfo/python-list
Re: PipeController v0.1 - experimental tool to simulate simple UNIX-style pipes in Python
On Friday, 31 August 2012 03:27:54 UTC+5:30, vasudevram wrote: > I wrote PipeController recently to experiment with doing UNIX-style pipes in > Python. > > > > Blog post about it: > > > > http://jugad2.blogspot.in/2012/08/pipecontroller-v01-released-simulating.html > > > > The blog post has a link to the downloadable PipeController source code. > > > > It will be released under the New BSD License, which means you can use it for > any purpose, commercial or otherwise, subject to the terms of the license. > > > > - Vasudev Ram > > www.dancingbison.com > > jugad2.blogspot.com > > twitter.com/vasudevram Doesn't the pipes module already do this? -- http://mail.python.org/mailman/listinfo/python-list
Re: KAJOL SEX VIDEOS'''''''''''''''''''
On Thursday, August 2, 2012 9:35:25 PM UTC+5, devi wrote: > KAJAL SEX VIDEOS > > http://maxworkerds.co.cc -- http://mail.python.org/mailman/listinfo/python-list
Re: Async client for PostgreSQL?
On 8/31/12 7:17 PM, Laszlo Nagy wrote: Is there any extension for Python that can do async I/O for PostgreSQL with tornadoweb's ioloop? Something like: class MainHandler(tornado.web.RequestHandler): @tornado.web.asynchronous def get(self): pg_connection.(long_taking_query_sql,params,callback=self.on_query_opened) def on_query_opened(self, query): self.write(process_rows(query)) self.finish() What would be an alternative? The theoretical problem: suppose there are 100 clients (web browsers) connected to the server with keep alive connections. They are doing long-polls and they are also sending/receiving events (with short response times). Each web browser has an associated state stored on the server side, in the memory (as an object tree). The state is bound to the client with a session id. Most requests will have to be responded with small amounts of data, calculated from the session state, or queried from the database. Most database queries are simple, running for about 100msec. But a few of them will run for 1sec or more. Number of requests ending in database queries is relatively low (10/sec). Other requests can be responded must faster. but they are much more frequent (100/sec, that is. 1 request/sec/client). There is a big global cache full of (Python) objects. Their purpose is to reduce the number of database queries. These objects in the global cache are emitting events to other objects found in the client sessions. Generally, it is not possible to tell what request will end in a database query. Multi-threading is not an option because number of clients is too high (running 100 threads is not good). This is why I decided to use anyc I/O. Tornadoweb looks good for most requirements: async i/o, store session state in objects etc. The biggest problem is that psycopg is not compatible with this model. If I use blocking I/O calls inside a request handler, then they will block all other requests most of the time, resulting in slow response times. What would be a good solution for this? Thanks, Laszlo Hi does running on tornado imply that you would not consider twisted http://twistedmatrix.com ? If not, twisted has exactly this capability hiding long running queries on whatever db's behind deferToThread(). Brute force I would pack the db access into a twisted run web-service, forking work out in twisted either with deferToThread() or if you want to take advantage of using processes instead of threads thus being able to tap all cores, then have a look at ampoule at https://launchpad.net/ampoule - be aware though that ampoule has a 64k limit on what can be passed around. Werner -- http://mail.python.org/mailman/listinfo/python-list
Re: PipeController v0.1 - experimental tool to simulate simple UNIX-style pipes in Python
Resending to the list... On Sep 1, 2012 12:19 PM, "Ian Kelly" wrote: > On Sep 1, 2012 9:37 AM, "Ramchandra Apte" wrote: > > Doesn't the pipes module already do this? > > No, that deals with actual Unix pipes. This appears to be about pipelined > processing within a single program and not IPC; the description "Unix-like" > is a bit misleading, IMO. > -- http://mail.python.org/mailman/listinfo/python-list
Re: Async client for PostgreSQL?
Hi does running on tornado imply that you would not consider twisted http://twistedmatrix.com ? If not, twisted has exactly this capability hiding long running queries on whatever db's behind deferToThread(). All right, I was reading its documentation http://twistedmatrix.com/documents/10.1.0/api/twisted.internet.threads.deferToThread.html It doesn't tell too much about it: "Run a function in a thread and return the result as a Deferred.". Run a function but in what thread? Does it create a new thread for every invocation? In that case, I don't want to use this. My example case: 10% from 100 requests/second deal with a database. But it does not mean that one db-related request will do a single db API call only. They will almost always do more: start transaction, parse and open query, fetch with cursor, close query, open another query etc. then commit transaction. 8 API calls to do a quick fetch + update (usually under 100msec, but it might be blocked by another transaction for a while...) So we are talking about 80 database API calls per seconds at least. It would be insane to initialize a new thread for each invocation. And wrapping these API calls into a single closure function is not useful either, because that function would not be able to safely access the state that is stored in the main thread. Unless you protet it with locks. But it is whole point of async I/O server: to avoid using slow locks, expensive threads and context switching. Maybe, deferToThread uses a thread pool? But it doesn't say much about it. (Am I reading the wrong documentation?) BTW I could try a version that uses a thread pool. It is sad, by the way. We have async I/O servers for Python that can be used for large number of clients, but most external modules/extensions do not support their I/O loops. Including the extension modules of the most popular databases. So yes, you can use Twisted or torandoweb until you do not want to call *some* API functions that are blocking. (By *some* I mean: much less blocking than non-blocking, but quite a few.) We also have synchronous Python servers, but we cannot get rid of the GIL, Python threads are expensive and slow, so they cannot be used for a large number of clients. And finally, we have messaging services/IPC like zeromq. They are probably the most expensive, but they scale very well. But you need more money to operate the underlying hardware. I'm starting to think that I did not get a quick answer because my use case (100 clients) fall into to the "heavy weight" category, and the solution is to invest more in the hardware. :-) Thanks, Laszlo -- http://mail.python.org/mailman/listinfo/python-list
Re: Async client for PostgreSQL?
On 9/1/12 9:28 AM, Laszlo Nagy wrote: Hi does running on tornado imply that you would not consider twisted http://twistedmatrix.com ? If not, twisted has exactly this capability hiding long running queries on whatever db's behind deferToThread(). All right, I was reading its documentation http://twistedmatrix.com/documents/10.1.0/api/twisted.internet.threads.deferToThread.html It doesn't tell too much about it: "Run a function in a thread and return the result as a Deferred.". Run a function but in what thread? Does it create a new thread for every invocation? In that case, I don't want to use this. My example case: 10% from 100 requests/second deal with a database. But it does not mean that one db-related request will do a single db API call only. They will almost always do more: start transaction, parse and open query, fetch with cursor, close query, open another query etc. then commit transaction. 8 API calls to do a quick fetch + update (usually under 100msec, but it might be blocked by another transaction for a while...) So we are talking about 80 database API calls per seconds at least. It would be insane to initialize a new thread for each invocation. And wrapping these API calls into a single closure function is not useful either, because that function would not be able to safely access the state that is stored in the main thread. Unless you protet it with locks. But it is whole point of async I/O server: to avoid using slow locks, expensive threads and context switching. Maybe, deferToThread uses a thread pool? But it doesn't say much about it. (Am I reading the wrong documentation?) BTW I could try a version that uses a thread pool. It is sad, by the way. We have async I/O servers for Python that can be used for large number of clients, but most external modules/extensions do not support their I/O loops. Including the extension modules of the most popular databases. So yes, you can use Twisted or torandoweb until you do not want to call *some* API functions that are blocking. (By *some* I mean: much less blocking than non-blocking, but quite a few.) We also have synchronous Python servers, but we cannot get rid of the GIL, Python threads are expensive and slow, so they cannot be used for a large number of clients. And finally, we have messaging services/IPC like zeromq. They are probably the most expensive, but they scale very well. But you need more money to operate the underlying hardware. I'm starting to think that I did not get a quick answer because my use case (100 clients) fall into to the "heavy weight" category, and the solution is to invest more in the hardware. :-) Thanks, Laszlo Laszlo: Hmm, I was suggesting that you could replace the whole DB driver with a webservice implemented with twisted, if you rule out threads then with ampoule doing it with a process pool and consume this webservice with the tornado side asynchronously. production level example thread pool based DB API: Just to give you some ballpark figures, I'm running a game server with a daily peak of about 1500 parallel permanent connections and 50k games played every day (avg game duration 13min, peak request frequency close to 100req/sec) with a lot of statistics going into a MySQL DB on US$2k worth of hardware. Twisted as basis sitting atop FreeBSD, started the latest version in March, its running since then, no restarts, no reboots, no problems. production level example process pool based PDF production: Or for another implementation I'm running a webservice based PDF production (probably as blocking as services can come) for a Java based business app with twisted/ampoule, this is as stable as the game server. HTH, Werner -- http://mail.python.org/mailman/listinfo/python-list
Re: Async client for PostgreSQL?
On Friday, August 31, 2012 10:17:18 PM UTC-7, Laszlo Nagy wrote: > Is there any extension for Python that can do async I/O for PostgreSQL As others point out, the easiest route is using one of the blocking drivers with threads and "emulate" async operations. However, the low-level parts of py-postgresql (python.projects.postgresql.org) were designed with arbitrary modes in mind. That is, the protocol code is independent of the transport so that it could be used with frameworks like twisted given some effort. Much of the work that will go into py-postgresql over the next couple years will be to make it easier to integrate into arbitrary frameworks. Currently, I suspect it would require some "heavy lifting".. =\ cheers, github.com/jwp -- http://mail.python.org/mailman/listinfo/python-list
ANN: A new version (0.3.1) of the Python module which wraps GnuPG has been released.
A new version of the Python module which wraps GnuPG has been
released.
What Changed?
=
This is a minor enhancement and bug-fix release. See the project
website ( http://code.google.com/p/python-gnupg/ ) for more
information. Summary:
Better support for status messages from GnuPG.
Support for additional arguments to be passed to GnuPG.
Bugs in tests which used Latin-1 encoded data have been fixed by
specifying that encoding.
On verification (including after decryption), the signer trust level
is returned in integer and text formats.
The current version passes all tests on Windows (CPython 2.4, 2.5,
2.6, 2.7, 3.1 and Jython 2.5.1), Mac OS X (Python 2.5) and Ubuntu
(CPython 2.4, 2.5, 2.6, 2.7, 3.0, 3.1, 3.2). On Windows, GnuPG 1.4.11
has been used for the tests.
What Does It Do?
The gnupg module allows Python programs to make use of the
functionality provided by the Gnu Privacy Guard (abbreviated GPG or
GnuPG). Using this module, Python programs can encrypt and decrypt
data, digitally sign documents and verify digital signatures, manage
(generate, list and delete) encryption keys, using proven Public Key
Infrastructure (PKI) encryption technology based on OpenPGP.
This module is expected to be used with Python versions >= 2.4, as it
makes use of the subprocess module which appeared in that version of
Python. This module is a newer version derived from earlier work by
Andrew Kuchling, Richard Jones and Steve Traugott.
A test suite using unittest is included with the source distribution.
Simple usage:
>>> import gnupg
>>> gpg = gnupg.GPG(gnupghome='/path/to/keyring/directory')
>>> gpg.list_keys()
[{
...
'fingerprint': 'F819EE7705497D73E3CCEE65197D5DAC68F1AAB2',
'keyid': '197D5DAC68F1AAB2',
'length': '1024',
'type': 'pub',
'uids': ['', 'Gary Gross (A test user) ']},
{
...
'fingerprint': '37F24DD4B918CC264D4F31D60C5FEFA7A921FC4A',
'keyid': '0C5FEFA7A921FC4A',
'length': '1024',
...
'uids': ['', 'Danny Davis (A test user) ']}]
>>> encrypted = gpg.encrypt("Hello, world!", ['0C5FEFA7A921FC4A'])
>>> str(encrypted)
'-BEGIN PGP MESSAGE-\nVersion: GnuPG v1.4.9 (GNU/Linux)\n
\nhQIOA/6NHMDTXUwcEAf
...
-END PGP MESSAGE-\n'
>>> decrypted = gpg.decrypt(str(encrypted), passphrase='secret')
>>> str(decrypted)
'Hello, world!'
>>> signed = gpg.sign("Goodbye, world!", passphrase='secret')
>>> verified = gpg.verify(str(signed))
>>> print "Verified" if verified else "Not verified"
'Verified'
For more information, visit http://code.google.com/p/python-gnupg/ -
as always, your feedback is most welcome (especially bug reports,
patches and suggestions for improvement). Enjoy!
Cheers
Vinay Sajip
Red Dove Consultants Ltd.
--
http://mail.python.org/mailman/listinfo/python-list
Re: interfacing with x86_64 assembler
I haven't seen this joke on the Net in years, does anyone still remember it? "C combines the power of assembly language with the readability and maintainability of assembly language." -- http://mail.python.org/mailman/listinfo/python-list
Re: interfacing with x86_64 assembler
On Sun, Sep 2, 2012 at 10:10 AM, John Ladasky wrote: > I haven't seen this joke on the Net in years, does anyone still remember it? > > "C combines the power of assembly language with the readability and > maintainability of assembly language." Seen it, and it has validity. But I'd rather work with C than actual assembly any day. And these days, C code is just a bunch of directives specifying how a compiler should build a program; optimizing compilers add, remove, reorder, whatever they think fit. It's a pretty high level language now. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Looking for an IPC solution
On Friday, August 31, 2012 2:22:00 PM UTC-5, Laszlo Nagy wrote: > There are just so many IPC modules out there. I'm looking for a solution > > for developing a new a multi-tier application. The core application will > > be running on a single computer, so the IPC should be using shared > > memory (or mmap) and have very short response times. But there will be a > > tier that will hold application state for clients, and there will be > > lots of clients. So that tier needs to go to different computers. E.g. > > the same IPC should also be accessed over TCP/IP. Most messages will be > > simple data structures, nothing complicated. The ability to run on PyPy > > would, and also to run on both Windows and Linux would be a plus. > > > > I have seen a stand alone cross platform IPC server before that could > > serve "channels", and send/receive messages using these channels. But I > > don't remember its name and now I cannot find it. Can somebody please help? > > > > Thanks, > > > > Laszlo Hi Laszlo, There aren't a lot of ways to create a Python object in an "mmap" buffer. "mmap" is conducive to arrays of arrays. For variable-length structures like strings and lists, you need "dynamic allocation". The C functions "malloc" and "free" allocate memory space, and file creation and deletion routines operate on disk space. However "malloc" doesn't allow you to allocate memory space within memory that's already allocated. Operating systems don't provide that capability, and doing it yourself amounts to creating your own file system. If you did, you still might not be able to use existing libraries like the STL or Python, because one address might refer to different locations in different processes. One solution is to keep a linked list of free blocks within your "mmap" buffer. It is prone to slow access times and segment fragmentation. Another solution is to create many small files with fixed-length names. The minimum file size on your system might become prohibitive depending on your constraints, since a 4-byte integer could occupy 4096 bytes on disk or more. Or you can serialize the arguments and return values of your functions, and make requests to a central process. -- http://mail.python.org/mailman/listinfo/python-list
Accessing AST at runtime
Hi, I would like to access the AST of a python object at runtime. I mean, if I have this: def f(x): return x*x/2 Is there any way to interrogate the object f to find out the AST of the expression x*x/2 ? Of course if the definition of f were in a file, I could use the ast module to parse it; but what I want is to do this from within the code. The closest thing I was able to find was f.__code__, and more specifically f.__code__.co_code, but that is a byte-string which seems to be the bytecode (?) for the function. This may not be possible at all; maybe after the def statement is processed by the Python interpreter the AST information is discarded. But I wanted to check here if someone knows one way or another. Many thanks. -- http://mail.python.org/mailman/listinfo/python-list
Re: Accessing AST at runtime
On Sunday, 2 September 2012 08:00:59 UTC+5:30, (unknown) wrote: > Hi, > > > > I would like to access the AST of a python object at runtime. I mean, if I > have this: > > > > def f(x): return x*x/2 > > > > Is there any way to interrogate the object f to find out the AST of the > expression x*x/2 ? Of course if the definition of f were in a file, I could > use the ast module to parse it; but what I want is to do this from within the > code. > > > > The closest thing I was able to find was f.__code__, and more specifically > f.__code__.co_code, but that is a byte-string which seems to be the bytecode > (?) for the function. > > > > This may not be possible at all; maybe after the def statement is processed > by the Python interpreter the AST information is discarded. But I wanted to > check here if someone knows one way or another. > > > > Many thanks. You could scan the text for code and then ast.parse() it. Then you know how... -- http://mail.python.org/mailman/listinfo/python-list
Re: interfacing with x86_64 assembler
On Sunday, 2 September 2012 06:06:06 UTC+5:30, Chris Angelico wrote: > On Sun, Sep 2, 2012 at 10:10 AM, John Ladasky > > wrote: > > > I haven't seen this joke on the Net in years, does anyone still remember it? > > > > > > "C combines the power of assembly language with the readability and > > maintainability of assembly language." > > > > Seen it, and it has validity. But I'd rather work with C than actual > > assembly any day. And these days, C code is just a bunch of directives > > specifying how a compiler should build a program; optimizing compilers > > add, remove, reorder, whatever they think fit. It's a pretty high > > level language now. > > > > ChrisA I thought it was like this: assembly a low level language C a medium level language Java a high level language Python a very-high level language -- http://mail.python.org/mailman/listinfo/python-list
Re: py2c - an open source Python to C/C++ is looking for developers
On Tuesday, 31 July 2012 18:16:27 UTC+5:30, Stefan Behnel wrote: > Stefan Behnel, 31.07.2012 07:23: > > > From a look at the source code, it seems hard to bring it together with > > > anything. It looks very monolithic. > > > > Hmm, sorry, I mixed it up with "2c.py", which is yet another of those > > Python-to-C compilers with an all too similar name. > > > > https://code.google.com/p/2c-python/ > > > > There are a couple of others here: > > > > http://wiki.python.org/moin/PythonImplementations > > > > Seeing the number of those compilers, almost none of which is commonly used > > and/or still alive as a project, the question really is: why another one? > > > > I mean, it's totally fine as a hobby educational project, sure, and I > > really don't want to discourage anyone from going through this to have fun. > > > > But apart from "just for fun", what is the goal that would make this > > particular compiler different from the others? And also different enough to > > merit its own source base, instead of basing it on one of the existing > > projects? I don't consider "source is harder to read than to write" a good > > answer to this in general. > > > Stefan It converts to *pure* C/C++ *without* using Python or its API so that it can be the same speed as C/C++ -- http://mail.python.org/mailman/listinfo/python-list
Re: Curses unicode support
On Saturday, September 1, 2012 3:41:04 PM UTC-7, Steven D'Aprano wrote: > Thanks to Victor Stinner, the curses module now has improved Unicode > > support. > > > > http://mail.python.org/pipermail/python-dev/2012-September/121569.html > > > > Victor has asked for testers to report any bugs in the module before > > Python 3.3 goes live: > > > > [quote] > > So please try to test the curses module before Python 3.3 final with > > your favorite application! > > [end quote] > > > > > > -- > > Steven It might be worth mentioning here that there is no _curses module, with or without Unicode support, in any CPython version for the Windows operating system (http://bugs.python.org/issue2889). Christoph -- http://mail.python.org/mailman/listinfo/python-list
Re: py2c - an open source Python to C/C++ is looking for developers
On 09/01/2012 09:15 PM, Ramchandra Apte wrote: > It converts to *pure* C/C++ *without* using Python or its API so that it can > be the same speed as C/C++ Sounds like a fun project for you. I hope you learn a lot doing it. That's reason enough for it. Do you plan to port all the standard python modules as well, though? Because Python modules, both in the standard library and third-party, are the main reasons that I use python. For example, PyGTK. Python is a great glue language. Since it can seamlessly interact with C and be extended in C, speed has never really been an issue for me. -- http://mail.python.org/mailman/listinfo/python-list
Re: Accessing AST at runtime
On 9/1/2012 10:30 PM, [email protected] wrote: Hi, I would like to access the AST of a python object at runtime. I mean, if I have this: def f(x): return x*x/2 Is there any way to interrogate the object f to find out the AST of the expression x*x/2 ? Of course if the definition of f were in a file, I could use the ast module to parse it; but what I want is to do this from within the code. The closest thing I was able to find was f.__code__, and more specifically f.__code__.co_code, but that is a byte-string which seems to be the bytecode (?) for the function. This may not be possible at all; maybe after the def statement is processed by the Python interpreter the AST information is discarded. Yes, it is. -- Terry Jan Reedy -- http://mail.python.org/mailman/listinfo/python-list
Re: py2c - an open source Python to C/C++ is looking for developers
>That's reason enough for it. Do you plan to port all the standard python modules as well, though? Well, it should be quite easy because most of the _modules are either C accelerator (which there is no need to port) or a C wrapper (which should be trivial to port) -- http://mail.python.org/mailman/listinfo/python-list
Re: py2c - an open source Python to C/C++ is looking for developers
On Sunday, 2 September 2012 11:18:38 UTC+5:30, Michael Torrie wrote: > On 09/01/2012 09:15 PM, Ramchandra Apte wrote: > > > It converts to *pure* C/C++ *without* using Python or its API so that it > > can be the same speed as C/C++ > > > > Sounds like a fun project for you. I hope you learn a lot doing it. > > That's reason enough for it. Do you plan to port all the standard > > python modules as well, though? Because Python modules, both in the > > standard library and third-party, are the main reasons that I use > > python. For example, PyGTK. Python is a great glue language. Since it > > can seamlessly interact with C and be extended in C, speed has never > > really been an issue for me. I am writing py2c for my OS written in Python (planned) . >Sounds like a fun project for you. More fun with more developers. (I need developers) -- http://mail.python.org/mailman/listinfo/python-list
Cython 0.17 released
Hello everyone, on behalf of the Cython project team, I'm proud to announce the final release of Cython 0.17. This is a major step forward in the development of the Cython programming language that will make life easier for a lot of users, rounds up some rough edges of the compiler and adds (preliminary) support for CPython 3.3 and PyPy. With this release, the Cython compiler successfully passes over 14,000 regression tests of the CPython 3.3 test suite and almost 13,000 tests of the CPython 2.7 suite, with only some 300 and 200 failures respectively. This makes it a serious alternative to interpreted Python execution that integrates natively with the complete CPython ecosystem. It is also the first final release of an implementation of PEP 380 (generator delegation), before it will eventually appear in CPython 3.3. === Download and Documentation === Download: http://cython.org/release/Cython-0.17.tar.gz Release notes: http://wiki.cython.org/ReleaseNotes-0.17 Homepage: http://cython.org/ Documentation: http://docs.cython.org/ === Major features of this release === * vastly improved integration with the C++ STL containers http://docs.cython.org/src/userguide/wrapping_CPlusPlus.html#standard-library http://docs.cython.org/src/tutorial/strings.html#c-strings * "yield from" delegation between generators (PEP 380) http://www.python.org/dev/peps/pep-0380/ * alpha quality support for PyPy (via cpyext) http://docs.cython.org/src/userguide/pypy.html === What is Cython ? === Cython is a language with an optimising compiler that makes writing C extensions for the Python language as easy as Python itself. The Cython language is a superset of the Python language that additionally supports calling C functions and declaring C types on variables and class attributes. This allows the compiler to generate very efficient C code from Cython code. The C code is generated once and then compiles with all major C/C++ compilers in CPython 2.4 and later, including Python 3.x. PyPy support is work in progress (on both sides) and is considered mostly usable in Cython 0.17. All of this makes Cython the ideal language for wrapping external C libraries, embedding CPython into existing applications, and for fast C modules that speed up the execution of Python code. Have fun, Stefan -- http://mail.python.org/mailman/listinfo/python-list
Re: py2c - an open source Python to C/C++ is looking for developers
Ramchandra Apte, 02.09.2012 08:10: >> That's reason enough for it. Do you plan to port all the standard > python modules as well, though? > > Well, it should be quite easy because most of the _modules are either C > accelerator (which there is no need to port) or a C wrapper (which should be > trivial to port) Nope, not at all. They use the CPython C-API internally, so in order to port them, you'll have to reimplement that first. That's a huge amount of work, as proven by the incompleteness of all other Python implementations in that regard. If you think you can do better here then IronPython or PyPy, please go ahead. Stefan -- http://mail.python.org/mailman/listinfo/python-list
