Variables visibility for methods
Hello I made few experiments about variables visibility for methods. class MyClass: a = 1 def test(self): print(a) obj = MyClass() obj.test() Traceback (most recent call last): File "", line 1, in obj.test() File "", line 4, in test print(a) NameError: name 'a' is not defined === RESTART: Shell == a = 1 class MyClass: def test(self): print(a) obj = MyClass() obj.test() 1 So it seems that when an object's méthod is executed, variables in the scope outside the object's class can be read (2nd example), but not variables inside the class (1st example). For 1st example, I know that print(MyClass.a) or print(self.a) would have work. Any comments are welcome. -- https://mail.python.org/mailman/listinfo/python-list
Re: Variables visibility for methods
"ast" writes: > ... > So it seems that when an object's méthod is executed, variables > in the scope outside the object's class can be read (2nd example), > but not variables inside the class (1st example). > > For 1st example, I know that print(MyClass.a) or print(self.a) > would have work. > > Any comments are welcome. You are right. And it is documented this way. -- https://mail.python.org/mailman/listinfo/python-list
Re: Variables visibility for methods
"dieter" a écrit dans le message de news:[email protected]... "ast" writes: You are right. And it is documented this way. Thank you -- https://mail.python.org/mailman/listinfo/python-list
Fatal Python error
Dear friendI'm very sorry to bother you in a busy schedule. But I have a questions about Sigil's environment that really need your help. I'm trying to use Sigil at a windows system,the follow are the relation of Sigil build and run environment. OS:WIN10 Python:python-3.6.0a4-amd64 QT:qt5.5.1 ActivePerl:ActivePerl-5.24.0.2400-MSWin32-x64-300558 Ruby:rubyinstaller-2.3.1-x64 Sigil:Sigil-0.9.6-Code VS:VS2015 The system environment I alse configured.The Sigil project also build successed. But When I run the Sigil.exe that follow errors occured. -- Fatal Python error: Py_Initialize: unable to load the file system codec -- The Sigil.exe can not run, and the main sigil form also can not appearses. Can you help me which I should do to solove this problems? Thanks very much. -- https://mail.python.org/mailman/listinfo/python-list
Re: The Joys Of Data-Driven Programming
On Sunday, 21 August 2016 15:20:39 UTC+1, Marko Rauhamaa wrote: > > Aren’t makefiles data-driven? > > Yes, "make" should be added to my sin list. > > > [Personally Ive always believed that jam is better than make and is > > less used for entirely historical reasons; something like half the > > world eoling with crlf and half with lf. But maybe make is really a > > better design because more imperative?] > > Don't know jam, but can heartily recommend SCons. The data driven side of make is the target: sources part. But (particularly as a Python programmer, where build dependencies are less of an issue) a huge part of make usage is in my experience, simply name: actions pairs (which is the less data driven aspect), maybe with an element of "always do X before Y". I've generally found "make successors" like SCons and waf to be less useful, precisely because they focus on the dependency graph (the data driven side) and less on the trigger-action aspect. Has anyone else found this to be the case? Is there any "make replacement" out there that focuses more on named sets of actions (maybe with prerequisite/successor type interdependencies), and less on building file dependency graphs? Paul -- https://mail.python.org/mailman/listinfo/python-list
Re: The Joys Of Data-Driven Programming
On Aug 31, 2016, at 8:21 AM, Paul Moore wrote: > On Sunday, 21 August 2016 15:20:39 UTC+1, Marko Rauhamaa wrote: >>> Aren’t makefiles data-driven? >> >> Yes, "make" should be added to my sin list. >> >>> [Personally Ive always believed that jam is better than make and is >>> less used for entirely historical reasons; something like half the >>> world eoling with crlf and half with lf. But maybe make is really a >>> better design because more imperative?] >> >> Don't know jam, but can heartily recommend SCons. > > The data driven side of make is the target: sources part. But (particularly > as a Python programmer, where build dependencies are less of an issue) a huge > part of make usage is in my experience, simply name: actions pairs (which is > the less data driven aspect), maybe with an element of "always do X before Y". > > I've generally found "make successors" like SCons and waf to be less useful, > precisely because they focus on the dependency graph (the data driven side) > and less on the trigger-action aspect. > > Has anyone else found this to be the case? Is there any "make replacement" > out there that focuses more on named sets of actions (maybe with > prerequisite/successor type interdependencies), and less on building file > dependency graphs? Maybe Ninja (https://ninja-build.org/)? I personally like it because of how simple it is, and the fact that it doesn't use leading tabs the way that make does. It is intended to be the assembler for higher-level build systems which are more like compilers. I personally use it as a make replacement because it does what I tell it to do, and nothing else. It may fit what you're after. Thanks, Cem Karan -- https://mail.python.org/mailman/listinfo/python-list
Re: The Joys Of Data-Driven Programming
On Aug 31, 2016, at 9:02 AM, Paul Moore wrote: > On 31 August 2016 at 13:49, Cem Karan wrote: >>> Has anyone else found this to be the case? Is there any "make replacement" >>> out there that focuses more on named sets of actions (maybe with >>> prerequisite/successor type interdependencies), and less on building file >>> dependency graphs? >> >> Maybe Ninja (https://ninja-build.org/)? I personally like it because of how >> simple it is, and the fact that it doesn't use leading tabs the way that >> make does. It is intended to be the assembler for higher-level build >> systems which are more like compilers. I personally use it as a make >> replacement because it does what I tell it to do, and nothing else. It may >> fit what you're after. > > It still seems focused on the file dependency graph (at least, from a > quick look). > > I'm thinking more of the makefile pattern > > myproj.whl: >pip wheel . > ve: build >virtualenv ve >ve/bin/python -m pip install ./*.whl > test: ve >push ve >bin/python -m py.test >popd > clean: >rm -rf ve > > Basically, a couple of "subcommands", one of which has 2 prerequisites > that are run if needed. Little more in practice than 2 shell scripts > with a bit of "if this is already done, skip" logic. > > Most makefiles I encounter or write are of this form, and make > essentially no use of dependency rules or anything more complex than > "does the target already exist" checks. Make would be fine for this > except for the annoying "must use tabs" rule, and the need to rely on > shell (= non-portable, generally unavailable on Windows) constructs > for any non-trivial logic. > > In the days when make was invented, not compiling a source file whose > object file was up to date was a worthwhile time saving. Now I'm more > likely to just do "cc -c *.c" and not worry about it. OK, I see what you're doing, and you're right, Ninja could be forced to do what you want, but it isn't the tool that you need. Thanks, Cem Karan -- https://mail.python.org/mailman/listinfo/python-list
Re: The Joys Of Data-Driven Programming
Cem Karan : > On Aug 31, 2016, at 9:02 AM, Paul Moore wrote: >> In the days when make was invented, not compiling a source file whose >> object file was up to date was a worthwhile time saving. Now I'm more >> likely to just do "cc -c *.c" and not worry about it. > > OK, I see what you're doing, and you're right, Ninja could be forced to > do what you want, but it isn't the tool that you need. So if you always need to perform a quick batch of commands, a simple build.sh script would do, right? Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: The Joys Of Data-Driven Programming
On Wednesday, August 31, 2016 at 5:52:02 PM UTC+5:30, Paul Moore wrote: > On Sunday, 21 August 2016 15:20:39 UTC+1, Marko Rauhamaa wrote: > > > Aren’t makefiles data-driven? > > > > Yes, "make" should be added to my sin list. > > > > > [Personally Ive always believed that jam is better than make and is > > > less used for entirely historical reasons; something like half the > > > world eoling with crlf and half with lf. But maybe make is really a > > > better design because more imperative?] > > > > Don't know jam, but can heartily recommend SCons. > > The data driven side of make is the target: sources part. But (particularly > as a Python programmer, where build dependencies are less of an issue) a huge > part of make usage is in my experience, simply name: actions pairs (which is > the less data driven aspect), maybe with an element of "always do X before Y". > > I've generally found "make successors" like SCons and waf to be less useful, > precisely because they focus on the dependency graph (the data driven side) > and less on the trigger-action aspect. > > Has anyone else found this to be the case? Is there any "make replacement" > out there that focuses more on named sets of actions (maybe with > prerequisite/successor type interdependencies), and less on building file > dependency graphs? > > Paul Dont know much of jam. Still here goes Jam users write two files Jamfile (like Makefile) and Jambase (the make rules reified which in practice is rarely needed to be modified by a vanilla user) You probably want to use jam and write your own jambase https://swarm.workshop.perforce.com/view/guest/perforce_software/jam/src/Jambase.html -- https://mail.python.org/mailman/listinfo/python-list
Re: The Joys Of Data-Driven Programming
On 31 August 2016 at 13:49, Cem Karan wrote: >> Has anyone else found this to be the case? Is there any "make replacement" >> out there that focuses more on named sets of actions (maybe with >> prerequisite/successor type interdependencies), and less on building file >> dependency graphs? > > Maybe Ninja (https://ninja-build.org/)? I personally like it because of how > simple it is, and the fact that it doesn't use leading tabs the way that make > does. It is intended to be the assembler for higher-level build systems > which are more like compilers. I personally use it as a make replacement > because it does what I tell it to do, and nothing else. It may fit what > you're after. It still seems focused on the file dependency graph (at least, from a quick look). I'm thinking more of the makefile pattern myproj.whl: pip wheel . ve: build virtualenv ve ve/bin/python -m pip install ./*.whl test: ve push ve bin/python -m py.test popd clean: rm -rf ve Basically, a couple of "subcommands", one of which has 2 prerequisites that are run if needed. Little more in practice than 2 shell scripts with a bit of "if this is already done, skip" logic. Most makefiles I encounter or write are of this form, and make essentially no use of dependency rules or anything more complex than "does the target already exist" checks. Make would be fine for this except for the annoying "must use tabs" rule, and the need to rely on shell (= non-portable, generally unavailable on Windows) constructs for any non-trivial logic. In the days when make was invented, not compiling a source file whose object file was up to date was a worthwhile time saving. Now I'm more likely to just do "cc -c *.c" and not worry about it. Paul -- https://mail.python.org/mailman/listinfo/python-list
Re: Variables visibility for methods
On Wednesday, August 31, 2016 at 12:09:16 AM UTC-7, ast wrote: > Hello > > I made few experiments about variables visibility > for methods. > > class MyClass: > a = 1 > def test(self): > print(a) > > obj = MyClass() > obj.test() > > Traceback (most recent call last): > File "", line 1, in > obj.test() > File "", line 4, in test > print(a) > NameError: name 'a' is not defined > > === RESTART: Shell == > > a = 1 > > class MyClass: > def test(self): > print(a) > > obj = MyClass() > obj.test() > 1 > > So it seems that when an object's méthod is executed, variables > in the scope outside the object's class can be read (2nd example), > but not variables inside the class (1st example). > > For 1st example, I know that print(MyClass.a) or print(self.a) > would have work. > > Any comments are welcome. In your example a is an attribute of MyClass, not instances of MyClass like obj. Refrencing a as MyClass.a returns 1. See below: >>> class MyClass: ... a = 1 ... def test(self): ... print(MyClass.a) ... >>> obj = MyClass() >>> obj.test() 1 -- https://mail.python.org/mailman/listinfo/python-list
Re: Fatal Python error
On Wed, Aug 31, 2016 at 9:04 AM, Wanderer <[email protected]> wrote: > The system environment I alse configured.The Sigil project also build > successed. > But When I run the Sigil.exe that follow errors occured. > -- > Fatal Python error: Py_Initialize: unable to load the file system codec > -- This is an expected error if Python can't find the standard library. For example: C:\>cmd /c "set PYTHONHOME=C:\ & python" Fatal Python error: Py_Initialize: unable to load the file system codec ImportError: No module named 'encodings' Current thread 0x0730 (most recent call first): Maybe you have a stale PYTHONHOME setting (generally this variable should not be set permanently), or maybe you've put the standard library (possibly python36.zip) somewhere unexpected. -- https://mail.python.org/mailman/listinfo/python-list
C Python extension to export an Function
Hi Team,
Iam on python 2.7 and Linux.
Iam pretty new to C Python extension , I was able to export few simple
modules to python and it look like the cool thing to do , but Iam stuck
for with a problem now , Iam not able to figure out how to export
fun_addr_from_addr()
to Python. I would need some suggestion on how to develop a C Python
API for the below piece of code.
1. The end goal is to export fun_addr_from_addr(baddr, *baddr) to Python.
Perhaps by creating a python wrapper for fun_bh_toblkoff() would help me ?
Here is the sample example code.
fun_toblkoff(dda_locn_t *locn,
struct ifs_baddr *baddr, int *poff, int *psize)
{
if (dda_locnparm_get(locn) != OK)
return FAIL;
/* fill in baddr */
*baddr = dda_index_to_baddr(locn->idx);
if (locn->flags & DLFLAG)
locn->xoff = fun_addr_from_addr(baddr, *baddr);
*poff = 0;
*psize = _BSIZE;
return OK;
}
So the primary challenge when writing a wrapper for a single
function is figuring out how to get the arguments from
Python form to C form, and how to get the result back to Python form.
Regards,
Ganesh
--
https://mail.python.org/mailman/listinfo/python-list
