I may regret this, but there is a very alpha Python bytecode assembler.
https://pypi.python.org/pypi/xasm
--
https://mail.python.org/mailman/listinfo/python-list
On Monday, August 22, 2016 at 8:45:05 AM UTC-4, Chris Angelico wrote:
> On Mon, Aug 22, 2016 at 10:05 PM, Marko Rauhamaa wrote:
> > rocky :
> >
> >> A slightly different but related problem is noting the Python dialect
> >> at the package-level.
> >
>
On Monday, August 22, 2016 at 8:05:15 AM UTC-4, Marko Rauhamaa wrote:
> rocky :
>
> > A slightly different but related problem is noting the Python dialect
> > at the package-level.
>
> I don't know what if anything is needed support this idea, but one
> opt
On Monday, August 22, 2016 at 12:33:53 AM UTC-4, Chris Angelico wrote:
> On Mon, Aug 22, 2016 at 1:37 PM, rocky wrote:
> > Sorry should have been:
> >
> > assert sys.version_info >= (3,0)
>
> The next question is: How common is code like this? I don't put
&g
On Monday, August 22, 2016 at 6:44:43 AM UTC-4, Rustom Mody wrote:
> On Monday, August 22, 2016 at 3:53:27 PM UTC+5:30, rocky wrote:
> > On Monday, August 22, 2016 at 2:04:39 AM UTC-4, Random832 wrote:
> > > On Mon, Aug 22, 2016, at 01:35, Steven D'Aprano wrote:
> &g
On Monday, August 22, 2016 at 1:36:07 AM UTC-4, Steven D'Aprano wrote:
> On Monday 22 August 2016 14:33, Chris Angelico wrote:
>
> > On Mon, Aug 22, 2016 at 1:37 PM, rocky wrote:
> >> Sorry should have been:
> >>
> >> assert sys.version_info >= (3,
On Monday, August 22, 2016 at 2:04:39 AM UTC-4, Random832 wrote:
> On Mon, Aug 22, 2016, at 01:35, Steven D'Aprano wrote:
> > Could somebody (the OP?) please explain what is the purpose of this
> > proposal, what it does, how it works, and when would people use it?
>
> I think what he wants is a w
Sorry should have been:
assert sys.version_info >= (3,0)
On Sunday, August 21, 2016 at 11:30:11 PM UTC-4, Ben Finney wrote:
> rocky writes:
>
> > The assertion should have been
> >
> > assert sys.version >= (3, 0)
>
> Perhaps you haven't trie
The assertion should have been
assert sys.version >= (3, 0)
If we want to indicate the Python program supports language versions 3.0 and
greater.
On Sunday, August 21, 2016 at 3:59:48 PM UTC-4, Vincent Vande Vyvre wrote:
> Le 21/08/2016 à 20:28, rocky a écrit :
> > The proble
The problem:
1. there are various code inspection tools that parse Python programs looking
for style issues or whatnot. The deeper ones have to do a full parse of the
python program. It would be helpful if there were a uniform way to indicate the
Python language level used in Python source code
On Thursday, June 9, 2016 at 1:36:56 AM UTC-4, Lawrence D’Oliveiro wrote:
> On Wednesday, June 8, 2016 at 10:39:00 PM UTC+12, rocky wrote:
>
> > In addition to the example programs which give the classic arithmetic
> > expression evaluator, I now include the beginnings of
On Friday, June 10, 2016 at 4:33:28 AM UTC-4, Robin Becker wrote:
> On 08/06/2016 19:32, rocky wrote:
> ..
> >
> > Sorry that should have been 1998 which would make more sense for the 7th
> > conference if the 1st one was around 2001. I've correct
On Wednesday, June 8, 2016 at 12:50:57 PM UTC-4, Robin Becker wrote:
> On 08/06/2016 11:38, rocky wrote:
> ...
> > [1] https://pypi.python.org/pypi/spark_parser/1.3.0
> ...
> the page above shows one can implement a time travel machine as it boldly
> states
>
ource code.
Alternatively if you want to understand how uncompyle6 works, such as to
improve it or fix bugs, you'll probably need to understand how the parser
system it uses works.
[1] https://pypi.python.org/pypi/spark_parser/1.3.0
[2] https://github.com/rocky/python-uncompyle6
On Monday, May 23, 2016 at 2:17:07 AM UTC-4, Pete Forman wrote:
> rocky writes:
>
> > I'm looking for a good name for a relatively new project I'll put on pypy.
> >
> > I've been working on a module to disassemble Python bytecode from many
> > versi
On Monday, May 23, 2016 at 2:17:07 AM UTC-4, Pete Forman wrote:
> rocky writes:
>
> > I'm looking for a good name for a relatively new project I'll put on pypy.
> >
> > I've been working on a module to disassemble Python bytecode from many
> > versi
al bytecode. So
that's in there as well.
In the future, I may could add a marshaler and an assembler to Python bytecode.
I know, this is kind of perverse.
At any rate the name I've been using is "pyxdis". See
https://github.com/rocky/python-pyxdis.
In the past I've bee
A little while ago I wrote uncompyle6 which can deparse Python C bytecode.
Currently it runs on 2.6-2.7 and 3.2 and up.
I think an underused part of that is that you can at runtime give it a bytecode
offset and it will show you where inside a line you are at. It also can show
the surrounding e
On Thursday, May 19, 2016 at 5:10:08 PM UTC-4, Fillmore wrote:
> Hello PyMasters!
>
> Long story short:
>
> cat myfile.txt | python -m pdb myscript.py
>
> doens't work (pdb hijacking stdin?).
>
> Google indicates that someone has fixed this with named pipes, but, call
> me stupid, I don't unde
On Tuesday, March 26, 2013 7:06:02 PM UTC-4, Steven D'Aprano wrote:
> On Tue, 26 Mar 2013 08:37:00 -0700, rocky wrote:
>
>
>
> > So again I come to import_relative,
>
> > http://code.google.com/p/pyimport-relative/. And again, I wish this
>
On Tue, Mar 26, 2013 at 5:16 PM, Phil Connell wrote:
> On Tue, Mar 26, 2013 at 08:37:00AM -0700, rocky wrote:
> > And again, I get the impression that for the use case asked about, there
> isn't much ambiguity. If I am in mypackage.foo and I want to access
> mypackage.col
On Tuesday, March 26, 2013 12:33:54 PM UTC-4, Jerry Hill wrote:
> On Mon, Mar 25, 2013 at 11:49 PM, rocky wrote:
>
> >> On Sun, 24 Mar 2013 18:12:49 -0500, Fabian von Romberg wrote:
>
> >> > I have a package name collections and inside of my package I want to
&g
On Tuesday, March 26, 2013 3:04:44 AM UTC-4, Terry Reedy wrote:
> On 3/24/2013 7:12 PM, Fabian von Romberg wrote:
>
> > Hi,
>
> >
>
> > I have a package name collections and inside of my package I want to
>
> > import the collections package from the standard library, but there
>
> > is name c
On Sunday, March 24, 2013 8:27:56 PM UTC-4, Steven D'Aprano wrote:
> On Sun, 24 Mar 2013 18:12:49 -0500, Fabian von Romberg wrote:
>
>
>
> > Hi,
>
> >
>
> > I have a package name collections and inside of my package I want to
>
> > import the collections package from the standard library, bu
I have been porting my Python debugger pydbgr to Python3. See [1] or [2].
Inside the debugger, when there is an exec() somewhere in the call stack, I'd
like to be able to retrieve the string parameter. With this, the debugger can
show part of the string in a call stack. Or it can show the text w
On Jul 7, 2:33 am, Peter Otten <__pete...@web.de> wrote:
> rocky wrote:
> > Someone recently reported a problem in pydb where a function defined
> > in his program was conflicting with amodulenamethat pydb uses. I
> > think I understand what's wrong, but I don
Someone recently reported a problem in pydb where a function defined
in his program was conflicting with a module name that pydb uses. I
think I understand what's wrong, but I don't have any elegant
solutions to the problem. Suggestions would be appreciated.
In a nutshell, here's the problem:
In
On Mar 23, 11:22 am, CinnamonDonkey
wrote:
> Hi Guys,
>
> Thanx for the quick responses, it is very much appreciated!
>
> Skip, that's a good point about "C++ != Python" and I assure you I am
> very much aware of that ;-).
>
> Looking athttp://www.python.org/dev/peps/pep-0328/#guido-s-decision
> w
Over at http://code.google.com/p/pydbgr/ is a rewrite of the pydb
debugger. Not all of the features from pydb have been moved over, and
the code there are some new features. Right now I'd call this alpha
software, but possibly it usable as is.
>From the development side, I think this will be a m
Import relative?
Recently for fun I've been working on a large Python program. It has
many files/modules spread over several directories/submodules.
Each module has some "demo" code at the end that I can use to run or
experiment with that module. Of course, modules often refer to others;
dependin
I am accustomed to vi my pthon scripts with 'tab' indent. But when I
copy some code to my script, the indent may be 'spaces'. So I wanna a
way to substitute those 'spaces' to be 'tabs' conveniently.
For example, I:
expand -t4 test.py >/tmp/test2.py
vi /tmp/test2.py
Then in vim, the indents should
python unzip
At first, I tried to use 'os.popen3("unzip ...") like this:
fin, fout, ferr = os.popen3("unzip -o -d %s %s" % (dest, zipfile))
strerr = ferr.read()
# This makes the program hanging up
if strerr:
print >> sys.stderr, strerr
outlog.error(strerr)
I want to know is this caused by
Well, I think I must have more explanation on my script. The script's
usage is like this:
~# fs_backup
Lack of backup identity name
program usage: fs_backup [OPTIONS] $identity
OPTIONS:
-a|--append [t/x[L]:$path, append 1 dir or file to $identity
t/x: include/exclude list, as -T/-X
I wonder is there any way to make the wrapper program can wrap options
&& arguments for the the subprocess/command the wrapper will
execute? by getopt or optparse module?
This is something like the shell script like this:
optwrap=""
while [ $# -gt 0 ]; do
case $1 in
-a) do-something; s
Hello,
Images, video, mp3 music, the real news from around the world... it's all
inside waiting for you.
You can find almost anything you are looking for.
They offer some of the best premium newsgroup access anywhere.
One thing I love about them, they don't keep log files of the news I read or
f
Installing fresh PyDev 0.9.7 onto eclipse 3.1 (no prior PyDev installed)
yields the following error when opening a python file. Seems like a
simple enough error... the PyEdit class seems to be present.
java.lang.ClassNotFoundException: org.python.pydev.editor.PyEdit
at
org.eclipse.osgi.fr
36 matches
Mail list logo
