Re: Importing variables non-deterministic?
Op 20-08-13 07:48, Steven D'Aprano schreef: > On Mon, 19 Aug 2013 22:34:00 +0200, Antoon Pardon wrote: > >> Op 19-08-13 19:05, Steven D'Aprano schreef: >> >> >>> I wish Python had stronger support for enforcing constantness, to whit, >>> some way to say "you can't rebind or delete this name once it is >>> bound". You can do it with attributes, by use of property, or in C >>> extensions, but you cannot do it with top-level name bindings. It makes >>> me terribly sad that you can do this: >>> >>> import math >>> math.pi = 3.0 >>> >>> >>> although I can't decide whether I am less sad or more sad to see that >>> the behaviour of math.sin and friends doesn't depend on math.pi. >> >> Why should you expect math.sin and friends be dependant on math.pi? >> AfAIR the numerical algorithms for calulating sin and friends don't >> depend on (the value of) pi. So there is no reason to suspect that >> altering math.pi would have any effect on the results of these >> functions. > > > Of course they depend on pi. Or rather, they depend on the geometric > properties of circles, which are related to pi. If the ratio of the > circumference of a circle to its diameter was exactly 3, instead of > 3.1415..., then sine and cosine functions would be periodic with period 6 > rather than τ = 2π. Which is beside the point. The fact that nπ are the zeropoints of the sin function doesn't imply in any way that you somehow need to work with the value of π in order to calculate any result of the function. Just as the function x^2 - 2 has -√2 and √2 as zeropoints, yet when given a numerical value, you dont need (the value of) √2 in order to get the result. So setting a variable like sqrt2 to whatever value shouldn't lead us to suspect it would influence the zeropoints of that function. Likewise with π and the calculation of sin. > If you consider the implementation of sin and cos functions, they usually > reduce the argument modulo π to something in the first quadrant, and then > use symmetry to adjust the value. So changing the value of pi could, in > principle, change the implementation of sin, cos and tan. Yes there is this aspect, which is a fair point. -- Antoon Pardon -- http://mail.python.org/mailman/listinfo/python-list
Re: Importing variables non-deterministic?
Le mardi 20 août 2013 07:48:37 UTC+2, Steven D'Aprano a écrit : > On Mon, 19 Aug 2013 22:34:00 +0200, Antoon Pardon wrote: > > > > > Op 19-08-13 19:05, Steven D'Aprano schreef: > > > > > > > > >> I wish Python had stronger support for enforcing constantness, to whit, > > >> some way to say "you can't rebind or delete this name once it is > > >> bound". You can do it with attributes, by use of property, or in C > > >> extensions, but you cannot do it with top-level name bindings. It makes > > >> me terribly sad that you can do this: > > >> > > >> import math > > >> math.pi = 3.0 > > >> > > >> > > >> although I can't decide whether I am less sad or more sad to see that > > >> the behaviour of math.sin and friends doesn't depend on math.pi. > > > > > > Why should you expect math.sin and friends be dependant on math.pi? > > > AfAIR the numerical algorithms for calulating sin and friends don't > > > depend on (the value of) pi. So there is no reason to suspect that > > > altering math.pi would have any effect on the results of these > > > functions. > > > > > > Of course they depend on pi. Or rather, they depend on the geometric > > properties of circles, which are related to pi. If the ratio of the > > circumference of a circle to its diameter was exactly 3, instead of > > 3.1415..., then sine and cosine functions would be periodic with period 6 > > rather than τ = 2π. > > > > If you consider the implementation of sin and cos functions, they usually > > reduce the argument modulo π to something in the first quadrant, and then > > use symmetry to adjust the value. So changing the value of pi could, in > > principle, change the implementation of sin, cos and tan. > > > > > > -- > > Steven - Never heard about series, Taylor, Maclaurin, ... ? jmf -- http://mail.python.org/mailman/listinfo/python-list
Re: refresing the edited python function
Sudheer Joseph writes: > ... > I wonder how the code developers work in this case > every time a function is modified one has to restart the console is a > nightmare... I use the "reload" approach a lot when developing isolated classes or functions and "plone.reload" for "Plone" related development. These approaches are not perfect but can avoid restarts in about 90 % of the cases. I also restart whenever something unexpected happens after a reload - as the reload approaches can have surprising effects. -- http://mail.python.org/mailman/listinfo/python-list
Re: Is this PEP-able? (syntax for functools.partial-like functionality)
On Tue, 20 Aug 2013 00:49:16 +0100, Fábio Santos wrote:
> I had an idea for a handy syntax which I thought of while designing a
> language for fun. This would be a syntax for creating, from a function,
> a function which is just like it but with some parameters pre-filled.
> The usage is much like functools.partials, and my proposed syntax is
> like this:
>
> def spam(a, b, c):
> ...
>
> spam_with_defaults = spam{1, 2}
Handy it may be, but why is this usage important enough to deserve new
syntax? The barrier to entry for new syntax is very high. For example,
Enums are a common, and standard, feature in many programming languages.
Enums will be introduced to Python in 3.4, but even they don't get
special syntax.
--
Steven
--
http://mail.python.org/mailman/listinfo/python-list
Re: Importing variables non-deterministic?
On Mon, 19 Aug 2013 22:34:00 +0200, Antoon Pardon wrote: > Op 19-08-13 19:05, Steven D'Aprano schreef: > > >> I wish Python had stronger support for enforcing constantness, to whit, >> some way to say "you can't rebind or delete this name once it is >> bound". You can do it with attributes, by use of property, or in C >> extensions, but you cannot do it with top-level name bindings. It makes >> me terribly sad that you can do this: >> >> import math >> math.pi = 3.0 >> >> >> although I can't decide whether I am less sad or more sad to see that >> the behaviour of math.sin and friends doesn't depend on math.pi. > > Why should you expect math.sin and friends be dependant on math.pi? > AfAIR the numerical algorithms for calulating sin and friends don't > depend on (the value of) pi. So there is no reason to suspect that > altering math.pi would have any effect on the results of these > functions. Of course they depend on pi. Or rather, they depend on the geometric properties of circles, which are related to pi. If the ratio of the circumference of a circle to its diameter was exactly 3, instead of 3.1415..., then sine and cosine functions would be periodic with period 6 rather than τ = 2π. If you consider the implementation of sin and cos functions, they usually reduce the argument modulo π to something in the first quadrant, and then use symmetry to adjust the value. So changing the value of pi could, in principle, change the implementation of sin, cos and tan. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: default python os x
On Mon, 19 Aug 2013 22:24:46 +0200, Uwe Rangs wrote: > My workflow at the moment is to set a link: mv python python_old > ln -s /usr/local/bin/python3.2 python > > But is this a good idea? You should never change the system Python, since that runs the risk of breaking system tools that expect a particular version. If there are any system tools that run "python", they may break. Instead, set a personal alias. For example, in my ~/.bashrc file, I have the following: export PYTHONPATH="/home/steve/python/:/home/steve/python/utilities" export PYTHONSTARTUP=/home/steve/python/utilities/startup.py alias python=python2.7 alias python3=python3.3 alias python1.5='env -u PYTHONSTARTUP python1.5' alias python2.0='env -u PYTHONSTARTUP python2.0' alias python2.1='env -u PYTHONSTARTUP python2.1' alias python2.2='env -u PYTHONSTARTUP python2.2' alias python2.3='env -u PYTHONSTARTUP python2.3' alias python3.4="env -u PYTHONPATH ~/python/cpython/python" So, for me, and me alone, typing "python" refers to Python 2.7 instead of the system Python, which happens to be 2.4 on my server and 2.6 on my laptop. "python1.5" etc unsets the startup file environment variable, since my startup file assumes 2.4 or better. "python3.4" points to a local copy in my home directory. Otherwise, python3.3, python3.2, etc. work as expected. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: make elements of a list twice or more.
On 7/08/2013 6:50 PM, liuerfire Wang wrote: > Here is a list x = [b, a, c] (a, b, c are elements of x. Each of them > are different type). Now I wanna generate a new list as [b, b, a, a, c, c]. from itertools import chain new_list = list(chain.from_iterable(zip(x,x))) -- http://mail.python.org/mailman/listinfo/python-list
Re: refresing the edited python function
In article , Ben Finney wrote: > Developers use the interactive console for exploring, not developing. I am reminded of a (very strange) guy I went to school with. He linked /dev/tty to /dev/tty.c. That allowed him to run "cc /dev/tty.c" and type in the text of a C program to compile. -- http://mail.python.org/mailman/listinfo/python-list
Re: Importing variables non-deterministic?
Antoon Pardon writes: > Op 19-08-13 09:45, Dave Angel schreef: > > Antoon Pardon wrote: > >> I think you are overstating your case. Classes and functions are > >> variables too and in general nobody seems to have a problem with > >> them being global. > > > > It's global *variables* that are to be avoided. constants like > > clsases and functions are fine. On the other hand, class attributes > > can be variable, and thus are to be avoided when reasonable. > > Python has no constants. Classes and functions can be changed just like > any other variable. I agree that classes and function are generally > meant to be constant, but often enought so are global int variables. I take this as yet another data point that speaking about “variables” leads mostly to confusion. What Python has are bindings. Those bindings can change (what Antoon calls “changed just like any other variable”). Many objects are immutable (what Dave calls “constants like classes and functions”), even if the bindings can vary and even if they contain attributes which are themselves bindings that can change. So, you're both right. The terminology is leading you both astray and having you talk past each other. Now go forth and speak of variables no more :-) -- \ “We demand rigidly defined areas of doubt and uncertainty!” | `\—Vroomfondel, _The Hitch-Hiker's Guide To The Galaxy_, Douglas | _o__)Adams | Ben Finney -- http://mail.python.org/mailman/listinfo/python-list
Re: refresing the edited python function
Sudheer Joseph writes: > I wonder how the code developers work in this case every time a > function is modified one has to restart the console is a nightmare... Developers use the interactive console for exploring, not developing. Use it to test, to confirm a suspicion about what a function call might do, to write code you know you will not run more than once. Any code you suspect might persist – and if you don't know, expect that it might persist – you should be writing in a module file and running as a program. > Hope one day some solution will be evolved. The time machine has brought you the solution: a text editor and the Python non-interactive session :-) -- \ “Generally speaking, the errors in religion are dangerous; | `\those in philosophy only ridiculous.” —David Hume, _A Treatise | _o__) of Human Nature_, 1739 | Ben Finney -- http://mail.python.org/mailman/listinfo/python-list
Is this PEP-able? (syntax for functools.partial-like functionality)
I had an idea for a handy syntax which I thought of while designing a
language for fun. This would be a syntax for creating, from a function, a
function which is just like it but with some parameters pre-filled. The
usage is much like functools.partials, and my proposed syntax is like this:
def spam(a, b, c):
...
spam_with_defaults = spam{1, 2}
Now calling spam_with_defaults is just like calling spam, but it only needs
one argument since a and b were set to 1 and 2, respectively.
spam_with_defaults(3) # same as calling spam(1, 2, 3)
This would also work with keyword arguments, E.G. spam{c=3} would return a
callable which would only need the arguments a and b.
This is just the plain old functools.partial functionality, but of course I
won't stop here. Still on our spam function:
spam_require_b = spam{2, *, 3}
spam_require_ab = spam{*, 3}
spam_require_a(1) # same as spam(1, 2, 3)
spam_require_ab(1, 2) # same as above
The * sign means that the function takes positional arguments which will be
added in place of the star. This is how we would do spam_require_b in pure
python:
def spam_require_b(*args, **kwargs):
return spam(*([1] + args + [2]), **kwargs)
Or, since we know it's only one argument,
spam_require_b = lambda b: spam(1, b, 3)
I also propose unpacking:
spam_unpacking = spam{1, (*, *)}
c = map(spam_unpacking, some_dict.items())
(Although this syntax isn't final), and receiving specific keyword
arguments.
spam_kw = spam{a, b, c=*}
The use cases this is intended to serve are mostly iteration related. There
is the case for being good plumbing for functions such as map, sorted,
filter and itertools.takewhile.
lines = filter(str.startswith{*, '#'}, open('file.cfg'))
lines = filter(bool, map(str.strip, lines))
config = dict(map(str.split{*, '=', 1}, lines))
A secondary use case is the creation of aliases.
def baz(self, callback):
respond = callback{instance=self}
...
What do you think?
PS: yes, I realized that I am proposing the addition of braces to the
language syntax.
--
http://mail.python.org/mailman/listinfo/python-list
Re: default python os x
On Mon, Aug 19, 2013 at 4:14 PM, Uwe Rangs wrote: > Hello, > > how can I change the default version of python with os x 10.7. > > Thanks, > Uwe > > -- > http://mail.python.org/mailman/listinfo/python-list You might want to look at this: http://stackoverflow.com/questions/5846167/how-to-change-default-python-version -- Joel Goldstick http://joelgoldstick.com -- http://mail.python.org/mailman/listinfo/python-list
Re: default python os x
My workflow at the moment is to set a link: mv python python_old ln -s /usr/local/bin/python3.2 python But is this a good idea? -- Uwe On 2013-08-19 20:14:04 +, Uwe Rangs said: Hello, how can I change the default version of python with os x 10.7. Thanks, Uwe -- http://mail.python.org/mailman/listinfo/python-list
Re: Importing variables non-deterministic?
Op 19-08-13 19:05, Steven D'Aprano schreef: I wish Python had stronger support for enforcing constantness, to whit, some way to say "you can't rebind or delete this name once it is bound". You can do it with attributes, by use of property, or in C extensions, but you cannot do it with top-level name bindings. It makes me terribly sad that you can do this: import math math.pi = 3.0 although I can't decide whether I am less sad or more sad to see that the behaviour of math.sin and friends doesn't depend on math.pi. Why should you expect math.sin and friends be dependant on math.pi? AfAIR the numerical algorithms for calulating sin and friends don't depend on (the value of) pi. So there is no reason to suspect that altering math.pi would have any effect on the results of these functions. -- Antoon Pardon -- http://mail.python.org/mailman/listinfo/python-list
default python os x
Hello, how can I change the default version of python with os x 10.7. Thanks, Uwe -- http://mail.python.org/mailman/listinfo/python-list
Re: opposite of __init__.py
Tamer Higazi wrote: > Hi people! > > I have asked myself a question, if there is a opposite of "__init__.py" > like "__del__.py" ?! Others have answered your question, but I wanted to correct a misunderstanding: > > I want, that when the application ends, certain functions are executed. > I know I could make a constructor and a destructor, Not sure what you're talkiing about, but you cannot be sure that an object's destructor ( __del__() ) will ever be called. If you want to make sure that a particular object gets processed, one approach is the with- syntax. > but I simply want to > know if there is a opposite > -- DaveA -- http://mail.python.org/mailman/listinfo/python-list
Re: Importing variables non-deterministic?
Op 19-08-13 18:57, Steven D'Aprano schreef: On Mon, 19 Aug 2013 10:16:36 +0200, Antoon Pardon wrote: Op 19-08-13 09:45, Dave Angel schreef: Antoon Pardon wrote: Op 17-08-13 17:01, Steven D'Aprano schreef: And here you re-import the name "y" from struct_global. That rebinds the current module's "y" with whatever value struct_global.y has *now*, rather than a second (or a minute, or an hour) earlier when the first import took place. Obviously at some point between the first import and the second import, struct_global.y must have been reassigned from -1 to 62. This goes to show why global variables are considered harmful, and why clean, modern program design tries to reduce the use of them as much as possible. Global variables are too easily modified by, well, *anything*. The sort of behaviour you are seeing is sometimes called "action at a distance" -- something, anything, anywhere in your program, possibly buried deep, deep down inside some function you might never suspect, is changing the global variable. I think you are overstating your case. Classes and functions are variables too and in general nobody seems to have a problem with them being global. It's global *variables* that are to be avoided. constants like clsases and functions are fine. On the other hand, class attributes can be variable, and thus are to be avoided when reasonable. Python has no constants. Classes and functions can be changed just like any other variable. I agree that classes and function are generally meant to be constant, but often enought so are global int variables. You are technically correct, but missing the point. If I wrote code that went around reassigning names from one function to another function, I would very likely soon work myself into a state of utter confusion: def func(x): ... # later save_func = func func = lambda x, y: do_stuff(x, 3*y)-4 result = something_that_calls_func() func = save_func Nasty, horrible code, yes? But it's nasty and horrible because "func" is bound to a function, it would be equally nasty and horrible if it was a data type (a string, a list, an int, a flag, ...) instead. Since classes and functions are First Class objects in Python, naturally if you treat them as global *variables* rather than global *constants* you can end up with problems. The problem is not the global part alone. Global constants, or pseudo-constant-by-convention-only, are fine. I don't think there is a big disagreement on this, I just thought you overstated your case as you originally worded it. And some of those that do change, only do so in the initialisation phase and should be considered constant for the rest of the program. My point was that Steven has no way of knowing what exactly is going on here and so shouldn't be making such a sweeping statement. On the contrary, I can read the Original Poster's description of the problem, and then use my ability to reason to deduce what the most likely explanation was. Now of course I might be wrong. I don't claim infallibility or omniscience. But I'm not an idiot, and if the OP says that a global variable has one value at one time, and then some time later has a different value, there are two likely possibilities: * The variable was changed by some other piece of code, i.e. it actually was being used as a *global variable*. Sure. But was that because it was intended to be used as a variable or was the intention to use it as a constant but because of a bug it was changed anyway? I don't think you have enough information to discriminate between these two cases and for the possibility of this being the latter case I found your disgression into the harm of global variable too strongly worded. -- Antoon Pardon. -- http://mail.python.org/mailman/listinfo/python-list
Re: Importing variables non-deterministic?
Op 19-08-13 17:04, Chris Angelico schreef:
On Mon, Aug 19, 2013 at 3:55 PM, Antoon Pardon
wrote:
Pity enough they chose a
way that didn't allow programmers to protect names they thought
important enough to do so too.
As of Python 3, we can redefine something that used to be a keyword,
which is even stronger than a constant.
def print(*args,print=print,**kw):
print("##",*args,**kw)
What easier way to tag all your print calls? And this is why it helps
to have nothing technically constant. You should be able to do the
same with anything, without having to go and edit someone else's code
to remove the 'const' keyword.
But what you are showing here is shadowing, not redefintion and you can
do that even if the shadowed name would be a constant.
--
Antoon Pardon
--
http://mail.python.org/mailman/listinfo/python-list
Re: Importing variables non-deterministic?
On Mon, Aug 19, 2013 at 6:16 PM, Steven D'Aprano wrote: > On Mon, 19 Aug 2013 16:57:37 +, Steven D'Aprano wrote: > >> def func(x): >> ... >> >> # later >> save_func = func >> func = lambda x, y: do_stuff(x, 3*y)-4 result = >> something_that_calls_func() >> func = save_func >> >> >> Nasty, horrible code, yes? But it's nasty and horrible because "func" is >> bound to a function, it would be equally nasty and horrible if it was a >> data type (a string, a list, an int, a flag, ...) instead. > > Oops, I left out a word. It is NOT nasty and horrible specifically > because "func" is bound to a function, it would be equally horrible if it > were a data type. I was having a little trouble parsing that! Thank you for the Iolanthe-style[1] update. ChrisA [1] http://math.boisestate.edu/gas/iolanthe/web_op/iol23d.html -- http://mail.python.org/mailman/listinfo/python-list
Re: Importing variables non-deterministic?
On Mon, 19 Aug 2013 16:57:37 +, Steven D'Aprano wrote: > def func(x): > ... > > # later > save_func = func > func = lambda x, y: do_stuff(x, 3*y)-4 result = > something_that_calls_func() > func = save_func > > > Nasty, horrible code, yes? But it's nasty and horrible because "func" is > bound to a function, it would be equally nasty and horrible if it was a > data type (a string, a list, an int, a flag, ...) instead. Oops, I left out a word. It is NOT nasty and horrible specifically because "func" is bound to a function, it would be equally horrible if it were a data type. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: refresing the edited python function
- Original Message - > From: Dave Angel > To: python-list@python.org > Cc: > Sent: Monday, 19 August 2013 4:45 PM > Subject: Re: refresing the edited python function > > Sudheer Joseph wrote: > >> Thank you Dieter, >> I never thought it will be so difficult task, All I > was thinking was that, I just do not know how it is done. I wonder how the > code > developers work in this case every time a function is modified one has to > restart the console is a nightmare... Hope one day some solution will be > evolved. >> with best regards, >> Sudheer >> > > Please don't top-post, and please use text messages, rather than html > mail, when posting on this list. > > Seems to me your problem is with ipython's IDE, not with Python. Python > requires you to rerun your application when making most changes to code. > But it doesn't say anything about restarting a "console," whatever > that > is in this context. I use Komodo IDE when i want an IDE functionality, > and never restart Komodo, over hours of work. > > Thank you Dave, I will make sure that when I post next time. with best regards, Sudheer -- http://mail.python.org/mailman/listinfo/python-list
Re: opposite of __init__.py
On Mon, 19 Aug 2013 18:48:19 +0200, Tamer Higazi wrote: > Hi people! > > I have asked myself a question, if there is a opposite of "__init__.py" > like "__del__.py" ?! No. If you want to run code when your application is shutting down, run it just before your code finishes: def main(): do_this() do_that() if __name__ == '__main__': main() shutdown() If you care about code running even if an exception takes place: if __name__ == '__main__': try: main() finally: shutdown() -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Importing variables non-deterministic?
On Mon, 19 Aug 2013 09:32:53 +0100, Chris Angelico wrote: > Python does have constants. It just doesn't have interpreter support for > them. Same as private members, in fact. "Constant by convention". I wish Python had stronger support for enforcing constantness, to whit, some way to say "you can't rebind or delete this name once it is bound". You can do it with attributes, by use of property, or in C extensions, but you cannot do it with top-level name bindings. It makes me terribly sad that you can do this: import math math.pi = 3.0 although I can't decide whether I am less sad or more sad to see that the behaviour of math.sin and friends doesn't depend on math.pi. Now, of course, and I don't expect any such "constants" to be proof against a dedicated attacker. One can work around read-only properties, and I expect that any future "no-rebind" constants will also be capable of being worked around. This is Python, not Haskell or Ada. But, naming convention or no naming convention, it is still valuable to get an exception if you accidentally rebind something that you shouldn't rebind. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: opposite of __init__.py
Yes, see the atexit module: http://docs.python.org/3/library/atexit.html On Mon, Aug 19, 2013 at 10:48 AM, Tamer Higazi wrote: > Hi people! > > I have asked myself a question, if there is a opposite of "__init__.py" > like "__del__.py" ?! > > I want, that when the application ends, certain functions are executed. > I know I could make a constructor and a destructor, but I simply want to > know if there is a opposite > > > Thanks > > > > Tamer > -- > http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
Re: Importing variables non-deterministic?
On Mon, 19 Aug 2013 10:16:36 +0200, Antoon Pardon wrote: > Op 19-08-13 09:45, Dave Angel schreef: >> Antoon Pardon wrote: >> >>> Op 17-08-13 17:01, Steven D'Aprano schreef: And here you re-import the name "y" from struct_global. That rebinds the current module's "y" with whatever value struct_global.y has *now*, rather than a second (or a minute, or an hour) earlier when the first import took place. Obviously at some point between the first import and the second import, struct_global.y must have been reassigned from -1 to 62. This goes to show why global variables are considered harmful, and why clean, modern program design tries to reduce the use of them as much as possible. Global variables are too easily modified by, well, *anything*. The sort of behaviour you are seeing is sometimes called "action at a distance" -- something, anything, anywhere in your program, possibly buried deep, deep down inside some function you might never suspect, is changing the global variable. >>> >>> I think you are overstating your case. Classes and functions are >>> variables too and in general nobody seems to have a problem with them >>> being global. >>> >>> >> It's global *variables* that are to be avoided. constants like clsases >> and functions are fine. On the other hand, class attributes can be >> variable, and thus are to be avoided when reasonable. > > Python has no constants. Classes and functions can be changed just like > any other variable. I agree that classes and function are generally > meant to be constant, but often enought so are global int variables. You are technically correct, but missing the point. If I wrote code that went around reassigning names from one function to another function, I would very likely soon work myself into a state of utter confusion: def func(x): ... # later save_func = func func = lambda x, y: do_stuff(x, 3*y)-4 result = something_that_calls_func() func = save_func Nasty, horrible code, yes? But it's nasty and horrible because "func" is bound to a function, it would be equally nasty and horrible if it was a data type (a string, a list, an int, a flag, ...) instead. Since classes and functions are First Class objects in Python, naturally if you treat them as global *variables* rather than global *constants* you can end up with problems. The problem is not the global part alone. Global constants, or pseudo-constant-by-convention-only, are fine. > And some of those that do change, only do so in the initialisation phase > and should be considered constant for the rest of the program. > > My point was that Steven has no way of knowing what exactly is going on > here and so shouldn't be making such a sweeping statement. On the contrary, I can read the Original Poster's description of the problem, and then use my ability to reason to deduce what the most likely explanation was. Now of course I might be wrong. I don't claim infallibility or omniscience. But I'm not an idiot, and if the OP says that a global variable has one value at one time, and then some time later has a different value, there are two likely possibilities: * The variable was changed by some other piece of code, i.e. it actually was being used as a *global variable*. * The OP is completely confused, and (inadvertently, we hope) reporting things which are actually not true. Much less likely: * Despite 15+ years of experience with Python, and reading the documentation, I have failed to notice that, yes, the OP is correct and importing variables is non-deterministic. * There's a bug in Python. Both of these are theoretically possible, but the chance of them is somewhere between Buckley's and None. Of course, if you have an alternate explanation for the issue the OP reported, I would love to hear it. Maybe I have completely misunderstood the situation. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
opposite of __init__.py
Hi people! I have asked myself a question, if there is a opposite of "__init__.py" like "__del__.py" ?! I want, that when the application ends, certain functions are executed. I know I could make a constructor and a destructor, but I simply want to know if there is a opposite Thanks Tamer -- http://mail.python.org/mailman/listinfo/python-list
Re: Importing variables non-deterministic?
On Mon, Aug 19, 2013 at 3:55 PM, Antoon Pardon
wrote:
> Pity enough they chose a
> way that didn't allow programmers to protect names they thought
> important enough to do so too.
As of Python 3, we can redefine something that used to be a keyword,
which is even stronger than a constant.
def print(*args,print=print,**kw):
print("##",*args,**kw)
What easier way to tag all your print calls? And this is why it helps
to have nothing technically constant. You should be able to do the
same with anything, without having to go and edit someone else's code
to remove the 'const' keyword.
ChrisA
--
http://mail.python.org/mailman/listinfo/python-list
Re: Importing variables non-deterministic?
Op 19-08-13 14:33, Dave Angel schreef: > Antoon Pardon wrote: > >> Op 19-08-13 11:18, Chris Angelico schreef: > >>> The issue >>> was regarding imports, and it's perfectly safe to import a constant, >>> even if the interpreter doesn't protect you from then being a total >>> idiot and changing it. >> >> Python doesn't have constants, so you statement about importing a >> constant doesn't make sense. The point is that python doesn't provide >> the mechanism for protecting names against reassignments. So you >> don't know whether the variable you think of as a constant is so >> in reality. And this from a pure language definition point of view. >> That you can use tools that make the interpreter no longer behave >> as the language should, doesn't negate that. >> > > Who cares what the language "protects?" I don't know any language > whose protections can't be at least partially bypassed by clever > foot-shooters. So? A number of language designers seem to think it is still worth while. And even as it may be possible to circumvent it, when we are talking about whether a language has constants or not, we are talking about this language feature. Whether you think this feature is worth having or not, doesn't change that this is what is meant when people talk about a language having constants or not. > In any case, we all know that Python doesn't protect > constants, so we're free to use the word in a friendlier way. > > A Python constant is what I use as a constant. No it is not. It can be a project constant, but it is not a python constant. As it turns out, python does have some constants if the version is high enough, being True, False and None. So for those values the python designers thought it valuable enough to protect them against reassignment. Pity enough they chose a way that didn't allow programmers to protect names they thought important enough to do so too. > I follow Pep-8 and make > it all caps. So in any library I write struct_global.y would be a bug > or a design flaw. No it is not. People are not obligated to follow pep-8 in their projects and not following pep-8 doesn't imply a design flaw. > (And with a single character name like that, it > wouldn't be global in any case. Single character names are reserved > for play code and for short loops) So? What if it is play code. You still don't know whether this person meant this variable in his play code to be used as a constant or not. -- Antoon Pardon -- http://mail.python.org/mailman/listinfo/python-list
Re: Question about crypto
On 08/18/2013 05:52 PM, Roy Smith wrote: > In article , > Anthony Papillion wrote: > >> I've just started working with the Crypto library and I've already run >> into a wall even though I'm following a tutorial. Basically, I'm trying >> to encrypt a string using AES in CBC mode. Here is the code: >> >> from Crypto import AES > > You don't say exactly what module you're using. I'm assuming > https://www.dlitz.net/software/pycrypto/api/current/, yes? Thank you, Roy, this was very helpful. You're right, I was confusing key size with the IV and I was tying the two together in an inappropriate (wrong) way. Thanks again! Anthony -- http://mail.python.org/mailman/listinfo/python-list
Re: Importing variables non-deterministic?
Antoon Pardon wrote: > Op 19-08-13 11:18, Chris Angelico schreef: >> The issue >> was regarding imports, and it's perfectly safe to import a constant, >> even if the interpreter doesn't protect you from then being a total >> idiot and changing it. > > Python doesn't have constants, so you statement about importing a > constant doesn't make sense. The point is that python doesn't provide > the mechanism for protecting names against reassignments. So you > don't know whether the variable you think of as a constant is so > in reality. And this from a pure language definition point of view. > That you can use tools that make the interpreter no longer behave > as the language should, doesn't negate that. > Who cares what the language "protects?" I don't know any language whose protections can't be at least partially bypassed by clever foot-shooters. In any case, we all know that Python doesn't protect constants, so we're free to use the word in a friendlier way. A Python constant is what I use as a constant. I follow Pep-8 and make it all caps. So in any library I write struct_global.y would be a bug or a design flaw. (And with a single character name like that, it wouldn't be global in any case. Single character names are reserved for play code and for short loops) And if I subsequently change it in my calling code, it isn't a constant any more. If I rebind the name, it's not even the same variable any more. That's a bug, not an exception to the rule "don't use global variables." I also accept as a constant those values which are initialized sufficiently early in the code that most places will only ever see the final value. Those may be global without worry. -- DaveA -- http://mail.python.org/mailman/listinfo/python-list
Re: Question about crypto
On 08/18/2013 05:29 PM, Skip Montanaro wrote: >> When I run the code above, I am told that the IV must be 16 bytes long. >> I'm assuming that the IV (I know that means "Initialization Vector") is >> either the key OR something else I can set. But I don't know how or what >> to do. > > Does this Stack Overflow thread help? It looks to me like you aren't > defining an initialization vector at all. > > http://stackoverflow.com/questions/14716338/pycrypto-how-does-the-initialization-vector-work Completely missed that Stack Overflow discussion. Thanks, Skip! That does help! Anthony -- http://mail.python.org/mailman/listinfo/python-list
Re: Importing variables non-deterministic?
Op 19-08-13 11:18, Chris Angelico schreef: > On Mon, Aug 19, 2013 at 10:03 AM, Antoon Pardon > wrote: >> This is irrelevant. That some context defines a constant, and that you >> can use a variable with the same name as a constant in python, doesn't >> contradict the statement that python (as a language) doesn't has >> constants. There is nothing in the language that would prevent buggy >> code from changing any of those variables. So from a python point of >> views these are just global variables. Just as the struct_global.y was >> in the original contribution. > > And there's nothing preventing a program from using ctypes to > overwrite an object's refcount, thus causing a segfault. So? Yes so? What is your point? Since Cpython caches small integers there is probably nothing preventing a program from using ctypes to make the number three behave as the number five. That doesn't mean that the language define three and five to be equal. A language having constants, does mean that the language can prevent a name from being reassigned. > The issue > was regarding imports, and it's perfectly safe to import a constant, > even if the interpreter doesn't protect you from then being a total > idiot and changing it. Python doesn't have constants, so you statement about importing a constant doesn't make sense. The point is that python doesn't provide the mechanism for protecting names against reassignments. So you don't know whether the variable you think of as a constant is so in reality. And this from a pure language definition point of view. That you can use tools that make the interpreter no longer behave as the language should, doesn't negate that. -- Antoon Pardon. -- http://mail.python.org/mailman/listinfo/python-list
Re: NodeTransformer: how to remove nodes?
Tobias Müller wrote:
> I'm facing an issue with NodeTransformer, a tool used for Python AST
> manipulations.
>
> Last week I posted on stackoverflow.com, but there are no responses yet.
> Maybe someone reading the mailing list can have a look and leave me a
> response here or over there?
>
> http://stackoverflow.com/questions/18275662/python-nodetransformer-how-to-
remove-nodes
As Chris says, you are overriding too much of the generic behaviour. Here is
a working demo:
import ast
class MyTransformer(ast.NodeTransformer):
def visit_For(self, node):
"""
For nodes: replace with nothing
"""
print("removing a For node")
return None
source = """
l = [0, 1, 2, 3]
total = 0
for i in l:
total += i
print(total)
"""
transformer = MyTransformer()
module = ast.parse(source)
transformer.visit(module)
codeobj = compile(module, '', 'exec')
exec(codeobj)
--
http://mail.python.org/mailman/listinfo/python-list
Re: refresing the edited python function
Sudheer Joseph wrote: > Thank you Dieter, > I never thought it will be so difficult task, All I was > thinking was that, I just do not know how it is done. I wonder how the code > developers work in this case every time a function is modified one has to > restart the console is a nightmare... Hope one day some solution will be > evolved. > with best regards, > Sudheer > Please don't top-post, and please use text messages, rather than html mail, when posting on this list. Seems to me your problem is with ipython's IDE, not with Python. Python requires you to rerun your application when making most changes to code. But it doesn't say anything about restarting a "console," whatever that is in this context. I use Komodo IDE when i want an IDE functionality, and never restart Komodo, over hours of work. -- DaveA -- http://mail.python.org/mailman/listinfo/python-list
Re: NodeTransformer: how to remove nodes?
On Mon, Aug 19, 2013 at 10:19 AM, Tobias Müller wrote:
> Hi
>
> I'm facing an issue with NodeTransformer, a tool used for Python AST
> manipulations.
>
> Last week I posted on stackoverflow.com, but there are no responses yet.
> Maybe someone reading the mailing list can have a look and leave me a
> response here or over there?
>
> http://stackoverflow.com/questions/18275662/python-nodetransformer-how-to-remove-nodes
I'm not familiar with NodeTransformer, but by the look of things, your
visit_For is being called (indirectly) by your own iterate_children,
which then ignores the return value. To apply changes like this,
either remove your definition of generic_visit, or have it pass
through to super():
def generic_visit(self, node):
"""
default behaviour
"""
print("visiting: "+node.__class__.__name__)
return super().generic_visit(node)
It's the code for NodeTransformer.generic_visit that does the
replacements (check out Lib/ast.py - it's down the very bottom in the
3.3 that I have), so if you bypass that, no replacement happens.
ChrisA
--
http://mail.python.org/mailman/listinfo/python-list
NodeTransformer: how to remove nodes?
Hi I'm facing an issue with NodeTransformer, a tool used for Python AST manipulations. Last week I posted on stackoverflow.com, but there are no responses yet. Maybe someone reading the mailing list can have a look and leave me a response here or over there? http://stackoverflow.com/questions/18275662/python-nodetransformer-how-to-remove-nodes Thanks Tobias Mueller -- http://mail.python.org/mailman/listinfo/python-list
Re: Importing variables non-deterministic?
Chris Angelico wrote: > On Mon, Aug 19, 2013 at 10:03 AM, Antoon Pardon > wrote: >> This is irrelevant. That some context defines a constant, and that you >> can use a variable with the same name as a constant in python, doesn't >> contradict the statement that python (as a language) doesn't has >> constants. There is nothing in the language that would prevent buggy >> code from changing any of those variables. So from a python point of >> views these are just global variables. Just as the struct_global.y was >> in the original contribution. > > And there's nothing preventing a program from using ctypes to > overwrite an object's refcount, thus causing a segfault. So? The issue > was regarding imports, and it's perfectly safe to import a constant, > even if the interpreter doesn't protect you from then being a total > idiot and changing it. Come on, breaking a "gentlemen's agreement" by rebinding a name and using ctypes to manipulate the internal state of the cpython imlementation are very different things. If that proves anything I'll best you with a Python script that controls a robot which in turn destroys the computer running the script with a hammer ;) If Antoon's point is that global "constants" in Python are only constants because the programmer thinks of them that way I'd say that's an important addition to put Steve's "global variables are considered harmful" into perspective. -- http://mail.python.org/mailman/listinfo/python-list
Re: Importing variables non-deterministic?
On Mon, Aug 19, 2013 at 10:03 AM, Antoon Pardon wrote: > This is irrelevant. That some context defines a constant, and that you > can use a variable with the same name as a constant in python, doesn't > contradict the statement that python (as a language) doesn't has > constants. There is nothing in the language that would prevent buggy > code from changing any of those variables. So from a python point of > views these are just global variables. Just as the struct_global.y was > in the original contribution. And there's nothing preventing a program from using ctypes to overwrite an object's refcount, thus causing a segfault. So? The issue was regarding imports, and it's perfectly safe to import a constant, even if the interpreter doesn't protect you from then being a total idiot and changing it. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Importing variables non-deterministic?
Op 19-08-13 10:32, Chris Angelico schreef: > On Mon, Aug 19, 2013 at 9:16 AM, Antoon Pardon > wrote: >> Op 19-08-13 09:45, Dave Angel schreef: >>> Antoon Pardon wrote: I think you are overstating your case. Classes and functions are variables too and in general nobody seems to have a problem with them being global. >>> >>> It's global *variables* that are to be avoided. constants like clsases >>> and functions are fine. On the other hand, class attributes can be >>> variable, and thus are to be avoided when reasonable. >> >> Python has no constants. Classes and functions can be changed just like >> any other variable. I agree that classes and function are generally >> meant to be constant, but often enought so are global int variables. > > # telnet.py > IAC = 0xFF > GA = 0xF9 > WILL = 0xFB > WONT = 0xFC > DO = 0xFD > DONT = 0xFE > > > # connection.py > from telnet import IAC,DO,DONT > > > To be sure, Python won't stop me from changing the value of DONT. But > it's a constant, and its value is defined elsewhere (RFC 854). (In > this instance, an enum would probably be the better option; but this > is an example of a more general case.) This is irrelevant. That some context defines a constant, and that you can use a variable with the same name as a constant in python, doesn't contradict the statement that python (as a language) doesn't has constants. There is nothing in the language that would prevent buggy code from changing any of those variables. So from a python point of views these are just global variables. Just as the struct_global.y was in the original contribution. -- Antoon Pardon -- http://mail.python.org/mailman/listinfo/python-list
Re: refresing the edited python function
Thank you Dieter, I never thought it will be so difficult task, All I was thinking was that, I just do not know how it is done. I wonder how the code developers work in this case every time a function is modified one has to restart the console is a nightmare... Hope one day some solution will be evolved. with best regards, Sudheer > > From: dieter >To: python-list@python.org >Sent: Monday, 19 August 2013 11:48 AM >Subject: Re: refresing the edited python function > > >Sudheer Joseph writes: > >> I have been using ipython and ipython with qtconsole and working on a code >> with functions. Each time I make a modification in function >> >> I have to quit IPTHON console (in both with and with out qt console ) and >> reload the function freshly. If I need to see the changed I made in the >> function. I tried below options >> del function name >> >> import the module again by issuing "from xxx.py import yy" >> import xxx.py >> make changes >> reload(xxx.py) >> this >> works only if the the function in the code has same name as the code. >> But even this do not reflect the changes made by editing the code. >> So what is the standard way to update the function for further tests after >> an edit? > >Getting changes into a running application is difficult. >Python has not been designed to make this easy. > >The "reload" above is one partial way to achieve something like this. >The "reload" causes the module to be reloaded. If you have changed >the modules code, these changes will be reflected *inside* the reloaded >module. However, other modules may have imported objects from >this module (as in your "from xxx.py import yy"). To see changes >in those objects, they, too, must repeat the import (otherwise, >they continue to use the old, unchanged object). > >There is an additional approach, used e.g. by "plone.reload". >In this approach, the objects are modified "in place". All usage >points of the modified object will see changes. >However, there are (quite severe) limitations to what changes >can be made "in place". Thus, this, too, does not give a complete >solution. > >In simple cases, one of those approaches can avoid a restart >after modifications. However, in general, a restart is required. > >-- >http://mail.python.org/mailman/listinfo/python-list > >-- http://mail.python.org/mailman/listinfo/python-list
Re: Importing variables non-deterministic?
On Mon, Aug 19, 2013 at 9:16 AM, Antoon Pardon wrote: > Op 19-08-13 09:45, Dave Angel schreef: >> Antoon Pardon wrote: >>> I think you are overstating your case. Classes and functions are >>> variables too and in general nobody seems to have a problem with them >>> being global. >>> >> >> It's global *variables* that are to be avoided. constants like clsases >> and functions are fine. On the other hand, class attributes can be >> variable, and thus are to be avoided when reasonable. > > Python has no constants. Classes and functions can be changed just like > any other variable. I agree that classes and function are generally > meant to be constant, but often enought so are global int variables. # telnet.py IAC = 0xFF GA = 0xF9 WILL = 0xFB WONT = 0xFC DO = 0xFD DONT = 0xFE # connection.py from telnet import IAC,DO,DONT To be sure, Python won't stop me from changing the value of DONT. But it's a constant, and its value is defined elsewhere (RFC 854). (In this instance, an enum would probably be the better option; but this is an example of a more general case.) In connection.py, I don't care that I've taken a "copy" of the integer 0xFE. It's never going to change; it is a constant in the best tradition of "named number". I could hard-code 0xFE everywhere and the code would work *just fine*, but it'd be less readable, so I don't. Python does have constants. It just doesn't have interpreter support for them. Same as private members, in fact. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Importing variables non-deterministic?
Op 19-08-13 09:45, Dave Angel schreef: > Antoon Pardon wrote: > >> Op 17-08-13 17:01, Steven D'Aprano schreef: >>> >>> And here you re-import the name "y" from struct_global. That rebinds the >>> current module's "y" with whatever value struct_global.y has *now*, >>> rather than a second (or a minute, or an hour) earlier when the first >>> import took place. Obviously at some point between the first import and >>> the second import, struct_global.y must have been reassigned from -1 to >>> 62. >>> >>> This goes to show why global variables are considered harmful, and why >>> clean, modern program design tries to reduce the use of them as much as >>> possible. Global variables are too easily modified by, well, *anything*. >>> The sort of behaviour you are seeing is sometimes called "action at a >>> distance" -- something, anything, anywhere in your program, possibly >>> buried deep, deep down inside some function you might never suspect, is >>> changing the global variable. >> >> I think you are overstating your case. Classes and functions are >> variables too and in general nobody seems to have a problem with them >> being global. >> > > It's global *variables* that are to be avoided. constants like clsases > and functions are fine. On the other hand, class attributes can be > variable, and thus are to be avoided when reasonable. Python has no constants. Classes and functions can be changed just like any other variable. I agree that classes and function are generally meant to be constant, but often enought so are global int variables. And some of those that do change, only do so in the initialisation phase and should be considered constant for the rest of the program. My point was that Steven has no way of knowing what exactly is going on here and so shouldn't be making such a sweeping statement. -- Antoon Pardon -- http://mail.python.org/mailman/listinfo/python-list
Re: Importing variables non-deterministic?
Antoon Pardon wrote: > Op 17-08-13 17:01, Steven D'Aprano schreef: >> >> And here you re-import the name "y" from struct_global. That rebinds the >> current module's "y" with whatever value struct_global.y has *now*, >> rather than a second (or a minute, or an hour) earlier when the first >> import took place. Obviously at some point between the first import and >> the second import, struct_global.y must have been reassigned from -1 to >> 62. >> >> This goes to show why global variables are considered harmful, and why >> clean, modern program design tries to reduce the use of them as much as >> possible. Global variables are too easily modified by, well, *anything*. >> The sort of behaviour you are seeing is sometimes called "action at a >> distance" -- something, anything, anywhere in your program, possibly >> buried deep, deep down inside some function you might never suspect, is >> changing the global variable. > > I think you are overstating your case. Classes and functions are > variables too and in general nobody seems to have a problem with them > being global. > It's global *variables* that are to be avoided. constants like clsases and functions are fine. On the other hand, class attributes can be variable, and thus are to be avoided when reasonable. There *are* places where global variables make sense, such as for caching, or counting. But those are typically hidden, so they are global in lifetime, but not in scope. -- DaveA -- http://mail.python.org/mailman/listinfo/python-list
Re: How to I do this in Python ?
On Sun, 18 Aug 2013 22:36:01 +0530, Ganesh Pal wrote: > Please find the comments >>> inline Please don't do that! "Arrows" > are used for quoting in emails. If you prefix your *new* comments using >>> it looks like they were quoted *three messages back*. You should be able to configure your email or news client to prefix quoted text with a >, and then you just type your own comments with no prefix, like I'm doing here. Even Gmail can do that. You seem to have copied-and-pasted my response into a new email, and then added your comments. Am I right? The normal way to reply to an email is to use Reply or Reply All. [...] Thanks for the suggestion on creating empty files and they worked > fine . I was today playing with the temp-file module to create > temporary files and directories , > Iam yet to explore it completely, but in current context , I > had a > quick question using temp-file module is its possible to create empty > temporary files and save them on disk in the user-defined path ? You shouldn't normally care about where temporary files are stored, since they're temporary and will disappear as soon as you are done with them. But yes, tempfile has the ability to control where the files are stored. Both tempfile.NamedTemporaryFile and tempfile.TemporaryFile take an optional directory argument. To read the documentation, run these two commands at the interactive prompt: import tempfile help(tempfile) or read it on the web: http://docs.python.org/2/library/tempfile.html http://docs.python.org/3/library/tempfile.html > If " yes " then can this also be an alternative and does this > have any drawback ? Alternative to what? If you mean, alternative to *not* storing it in the user's directory, then yes, it is :-) Drawbacks -- yes. I hate it when applications dump temporary files in my home directory. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Importing variables non-deterministic?
Op 17-08-13 17:01, Steven D'Aprano schreef: > > And here you re-import the name "y" from struct_global. That rebinds the > current module's "y" with whatever value struct_global.y has *now*, > rather than a second (or a minute, or an hour) earlier when the first > import took place. Obviously at some point between the first import and > the second import, struct_global.y must have been reassigned from -1 to > 62. > > This goes to show why global variables are considered harmful, and why > clean, modern program design tries to reduce the use of them as much as > possible. Global variables are too easily modified by, well, *anything*. > The sort of behaviour you are seeing is sometimes called "action at a > distance" -- something, anything, anywhere in your program, possibly > buried deep, deep down inside some function you might never suspect, is > changing the global variable. I think you are overstating your case. Classes and functions are variables too and in general nobody seems to have a problem with them being global. -- Antoon Pardon -- http://mail.python.org/mailman/listinfo/python-list
Re: Encapsulation unpythonic?
On Sun, 18 Aug 2013 18:15:10 +0100, Joshua Landau wrote: > On 17 August 2013 17:17, Steven D'Aprano > wrote: >> On Sat, 17 Aug 2013 05:26:32 -0700, fsaldan1 wrote: >>> how do I >>> deal with the fact that other programmers can easily alter the values >>> of members of my classes? >> ... >> If they insist on messing with your private single-underscore >> _attributes, you can't stop them, but that's okay, you don't have to be >> sympathetic when they shoot their foot off. Just slap them with a large >> halibut[1] and laugh. > > I know I've cropped your points but I just want to mention here that the > only reason to monkey-patch code in these ways where you'd want to stop > them is when the alternative is *worse*. It's like removing railings > from a cliff to stop people hitting the bars. I'm not actually talking about monkey-patching. I'm talking about just normal inheritance of classes. E.g. If a module has this class: class Parrot: def __init__(self): self._name = "Polly" def talk(self): print "%s wants a cracker!" % self._name I might be tempted to do this: class MyParrot: def __init__(self): super(MyParrot, self).__init__() self._name = "George" No monkey-patching involved. But, if the author of Parrot class changes his implementation and gets rid of "_name", or even makes it public "name", my subclass will stop working. Sucks to be me. In this toy example, both parties are at fault: the author of Parrot for unnecessary data-hiding of something which is so obviously a useful piece of information and should be part of the public interface, and me for nevertheless ignoring that warning and using the private attribute in my own code. More realistic examples may be different. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
