Re: PEP 450 Adding a statistics module to Python
Ben Finney, 10.08.2013 07:05: > Skip Montanaro writes: >> Given that installing numpy or scipy is generally no more difficult >> that executing "pip install (scipy|numpy)" I'm not really feeling the >> need for a battery here... > > See the Rationale of PEP 450 for more reasons why “install NumPy” is not > a feasible solution for many use cases, and why having ‘statistics’ as a > pure-Python, standard-library package is desirable. The rationale suggests that the module is meant as a simple toolset for non-NumPy users. Are the APIs (class model, function names, etc.) similar enough to make it easy to switch, preferably in both directions? It would be good if a stdlib statistics module could be used as a SciPy fallback for the "simple" things, and if users of the stdlib module could easily switch their code to SciPy if they need more speed/features/whatever at some point, without having to relearn the name of each single function. I'm not asking for compatibility (doesn't sound reasonable without NumPy arrays), but I think that a similarity in terms of API naming (as far as it makes sense) should be clearly stated, e.g. in the Design Decisions section. Stefan -- http://mail.python.org/mailman/listinfo/python-list
Re: Get filename using filefialog.askfilename
Sarcastic what the kcuf ¿?¿?¿? My english is SO bad? Do you know me? I can not understand this paranoia i only was giving thanks. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 3 and SSH Tunnel
What about the security though? To be specific, i need to create an application (python 3.3 strictly) where users will save/load their settings online to a remote hosted database. I do not wish to change the database from listening to any other thing than localhost for security reasons, so i assume the best solution for me would be to make the program create some ssh tunnels before the saving/loading happens. But would this policy make my database (or the rest of the databases that im running on that machine) unsecure? Is there any workaround this? How would you do that online saving/loading? -- http://mail.python.org/mailman/listinfo/python-list
Python 3.3 + QtSql + ssh tunnel - Connection problem
Im using python 3.3 on win7 64bit and trying to connect to a MySQL database on
a remote server through a putty ssh tunnel.
Running the script below im getting "Physical connection to the database did
not activate!". What im i doing wrong?! I tried to find a working example but
couldnt find one. thx in advance guys
from PyQt5 import QtSql
def main():
db = QtSql.QSqlDatabase.addDatabase("QMYSQL")
db.setHostName("127.0.0.1")
db.setPort(3306)
db.setDatabaseName("username_databasename")
db.setUserName(username)
db.setPassword(userpassword)
ok = db.open()
if ok:
print ("Physical connection to the database activated")
else:
print ("Physical connection to the database did not activate!")
return
create_table(db)
db.close()
main()
--
http://mail.python.org/mailman/listinfo/python-list
Re: ftplib returns EOFError
print "\t\tUploading file %s..." % newname
try:
self.ftp.storbinary("STOR %s" % newname, open(file))
except EOFError: # yep??
self.ftp.connect(self.ftpServ) # reconnecting
self.ftp.login(ftpUser, ftpPass)
self.ftp.storbinary("STOR %s" % newname, open(file))
print "\t\tFile %s uploaded" % newname
--
http://mail.python.org/mailman/listinfo/python-list
Re: PEP 450 Adding a statistics module to Python
In article , Skip Montanaro wrote: > Given that installing numpy or scipy is generally no more difficult > that executing "pip install (scipy|numpy)" I'm not really feeling the > need for a battery here... I just tried installing numpy in a fresh virtualenv on an Ubuntu Precise box. I ran "pip install numpy". It took 1.5 minutes. It printed almost 1800 lines of build crap, including 383 warnings and 83 errors. For a newbie, that can be pretty intimidating. That's for the case where I've already installed numpy elsewhere on that box, so I already had the fortran compiler, and the rest of the build chain. For fun, I just spun up a new Ubuntu Precise instance in AWS. It came pre-installed with Python 2.7.3. I tried "pip install numpy", which told me that pip was not installed. At least it told me what I needed to do to get pip installed. Unfortunately, I didn't read the message carefully enough and typed "sudo apt-get install pip", which of course got me another error because the correct name of the package is python-pip. Doing "sudo apt-get install python-pip" finally got me to the point where I could start to install numpy. Of course, if I didn't have sudo privs on the box (most corporate environments), I never would have gotten that far. At this point, "sudo pip install numpy" got me a bunch of errors culminating in "RuntimeError: Broken toolchain: cannot link a simple C program", and no indication of how to get any further. At this point, most people would give up. I don't remember the full set of steps I needed to do the first time. Obviously, I would start with installing gcc, but I seem to remember there were additional steps needed to get fortran support. Having some simple statistics baked into the standard python package would be a big win. As shown above, installing numpy can be an insurmountable hurdle for people with insufficient sysadmin-fu. PEP-450 makes cogent arguments why rolling your own statistics routines is fraught with peril. Looking over our source tree, I see we've implemented std deviation in python at least twice. I'm sure they're both naive implementations of the sort PEP-450 warns about. And, yes, backporting to 2.7 would be a big win too. I know the goal is to get everybody onto 3.x, but my pip external dependency list includes 40 modules. It's going to be a long and complicated road to get to the point where I can move to 3.x, and I imagine most non-trivial projects are in a similar situation. -- http://mail.python.org/mailman/listinfo/python-list
Re: Get filename using filefialog.askfilename
On 10 August 2013 11:37, wrote: > Sarcastic what the kcuf ¿?¿?¿? > > My english is SO bad? > > Do you know me? > > I can not understand this paranoia i only was giving thanks. Sarcasm and a lack thereof is very hard to see over the Internet. It's probably just a misunderstanding :). -- http://mail.python.org/mailman/listinfo/python-list
Re: PEP 450 Adding a statistics module to Python
On 10 August 2013 12:50, Roy Smith wrote: > In article , > Skip Montanaro wrote: > >> Given that installing numpy or scipy is generally no more difficult >> that executing "pip install (scipy|numpy)" I'm not really feeling the >> need for a battery here... > > I just tried installing numpy in a fresh virtualenv on an Ubuntu Precise > box. I ran "pip install numpy". It took 1.5 minutes. It printed > almost 1800 lines of build crap, including 383 warnings and 83 errors. > For a newbie, that can be pretty intimidating. > > That's for the case where I've already installed numpy elsewhere on that > box, so I already had the fortran compiler, and the rest of the build > chain. For fun, I just spun up a new Ubuntu Precise instance in AWS. > It came pre-installed with Python 2.7.3. I tried "pip install numpy", > which told me that pip was not installed. > > At least it told me what I needed to do to get pip installed. > Unfortunately, I didn't read the message carefully enough and typed > "sudo apt-get install pip", which of course got me another error because > the correct name of the package is python-pip. Doing "sudo apt-get > install python-pip" finally got me to the point where I could start to > install numpy. > > Of course, if I didn't have sudo privs on the box (most corporate > environments), I never would have gotten that far. > > At this point, "sudo pip install numpy" got me a bunch of errors > culminating in "RuntimeError: Broken toolchain: cannot link a simple C > program", and no indication of how to get any further. You should use apt-get for numpy/scipy on Ubuntu. Although unfortunately IIRC this doesn't work as well as it should since Ubuntu doesn't install the appropriate BLAS/LAPACK libraries by default (leaving you with numpy's fallback libraries). On Windows you should use the MSI installer (or easy_install). Hopefully numpy/scipy will start distributing wheels soon and pip install numpy will actually work. Oscar -- http://mail.python.org/mailman/listinfo/python-list
Re: PEP 450 Adding a statistics module to Python
Skip Montanaro wrote: > >> installing numpy or scipy is generally no more difficult > >> that executing "pip install (scipy|numpy)" I described the problems I had trying to follow that advice. In article , Oscar Benjamin wrote: > You should use apt-get for numpy/scipy on Ubuntu. Although > unfortunately IIRC this doesn't work as well as it should since Ubuntu > doesn't install the appropriate BLAS/LAPACK libraries by default > (leaving you with numpy's fallback libraries). That really kind of proves my point. It's *not* easy to install. Theres' a choice of methods, some of which work in some environments, some of which work in others. And even if apt-get is the preferred install method on Ubuntu, it's a method which is unavailable to people without root access (and may be undesirable if you rely on virtualenv to keep multiple projects cleanly separated). And, what happens if you don't have the right libraries? Do you end up with an install which is missing some functionality, or one where all the calls work, but they're slower, or numerically unstable, or what? All these questions go away if it's packaged with the standard library. I'm not sure where the line should be drawn between "basic stuff that should be included" and "advanced stuff that you need an add-on to get", but certainly mean and std-dev should be in the default distribution. -- http://mail.python.org/mailman/listinfo/python-list
Re: PEP 450 Adding a statistics module to Python
On 10 August 2013 13:43, Roy Smith wrote: > > In article , > Oscar Benjamin wrote: > >> You should use apt-get for numpy/scipy on Ubuntu. Although >> unfortunately IIRC this doesn't work as well as it should since Ubuntu >> doesn't install the appropriate BLAS/LAPACK libraries by default >> (leaving you with numpy's fallback libraries). > > That really kind of proves my point. It's *not* easy to install. > Theres' a choice of methods, some of which work in some environments, > some of which work in others. And even if apt-get is the preferred > install method on Ubuntu, it's a method which is unavailable to people > without root access (and may be undesirable if you rely on virtualenv to > keep multiple projects cleanly separated). > > And, what happens if you don't have the right libraries? Do you end up > with an install which is missing some functionality, or one where all > the calls work, but they're slower, or numerically unstable, or what? AFAIK not having separate BLAS/LAPACK libraries just means that certain operations are a lot slower. If there are differences in accuracy then they aren't significant enough that I've noticed. I think that the reason Ubuntu doesn't install them by default is because it's not sure which ones you want to use. Possibly the best free setup comes from using ATLAS but this is optimised in a CPU-specific way at build time. Ubuntu doesn't provide binaries for it as using generic x86 executables would defeat much of the point of the library (they do make it a lot easier by providing a source package though). Oscar -- http://mail.python.org/mailman/listinfo/python-list
Calling Py_Main() and parsing the output from C
Hello Python & C-experts.
I'm trying to embed python27.dll in a C-program written in
MingW-gcc 4.7.2. I've successfully done these initial steps:
typedef int (*Py_Main_t) (int argc, char **argv);
handle = LoadLibrary ("python27.dll");
py_main = (Py_Main_t) GetProcAddress (handle, "Py_Main");
argv[0] = who_am_I;/* the .exe of the embedding program. python*.dll
doesn't seems to care what this is */
argv[1] = (char*) "-c";
argv[2] = PYTHON_CMD; /* see below */
argv[3] = NULL;
rc = (*py_main) (3, argv);
DEBUG: pyembed.c(76): Calling Py_Main():
argv[0] = "G:\vc_2010\VC\Projects\EnvTool\src\envtool.exe"
argv[1] = "-c"
argv[2] = "import sys;[sys.stdout.write('%s\n' % p) for (i,p) in
enumerate(sys.path)]"
argv[3] = NULL.
Which produces the expected 'sys.path[]:
g:\Programfiler\Python27\lib\site-packages\pyzmq-2.2.0.1-py2.7-win32.egg
g:\Programfiler\Python27\lib\site-packages\nose-1.2.1-py2.7.egg
...
But I'd like to grab the stdout from Py_Main() into a pipe, mmap-file or similar
for the calling program to parse. Before I used the embedding solution, I simply
spawned python.exe using my shell and popen(). Then parsed the output
using fgets(). This work fine. But I'd like to try embedding now. Since avoiding
the shell should be faster. No?
How can I accomplish the grabbing of Py_Main() output simplest? Is creating
a memory-mapped file in the calling program a good idea? Can Py_Main() print
to that? If so, how? I'm on Win-XP SP3.
--gv
--
http://mail.python.org/mailman/listinfo/python-list
Python Basic Doubt
Hi Fellow Python Friends, I am new to Python and recently subscribed to the mailing list.I have a doubt regarding the basics of Python. Please help me in understanding the below concept. So doubt is on variables and their contained value. Why does in the below example from Interpreter exploration value of c take pre existing memory location. >>> a=10 >>> id(a) 21665504 >>> b=a >>> id(b) 21665504 >>> c=10 >>> id(c) 21665504 I am actually assigning new value to c. But from the value of id() all three variables take same location. With variables a and b it is ok. But why c taking the same location? Regards, Krishnan -- http://mail.python.org/mailman/listinfo/python-list
Re: Python Basic Doubt
On 2013-08-10 21:03, Krishnan Shankar wrote: > >>> a=10 > >>> id(a) > 21665504 > >>> b=a > >>> id(b) > 21665504 > >>> c=10 > >>> id(c) > 21665504 > > I am actually assigning new value to c. But from the value of id() > all three variables take same location. With variables a and b it > is ok. But why c taking the same location? As an internal optimization, CPython caches small integer values >>> a = 256 >>> b = 256 >>> a is b True >>> a = 257 >>> b = 257 >>> a is b False Because it's an internal implementation detail, you shouldn't count on this behavior (Jython or Cython or IronPython may differ; or future versions of Python may cache a different range of numbers). Generally, if you are using the "is" operator to compare against anything other than None, you're doing it wrong. There are exceptions to this, but it takes knowing the particulars. -tkc -- http://mail.python.org/mailman/listinfo/python-list
Re: Python Basic Doubt
In article , Krishnan Shankar wrote: > Hi Fellow Python Friends, > > I am new to Python and recently subscribed to the mailing list.I have a > doubt regarding the basics of Python. Please help me in understanding the > below concept. > > So doubt is on variables and their contained value. > > Why does in the below example from Interpreter exploration value of c take > pre existing memory location. > > >>> a=10 > >>> id(a) > 21665504 > >>> b=a > >>> id(b) > 21665504 > >>> c=10 > >>> id(c) > 21665504 Python doesn't really expose anything about memory locations. The fact that id() returns something which looks like it might be a memory location is purely a detail of the particular implementation you're using. The next thing to understand is that python doesn't have variables. It has objects and names which are bound to those objects. So, what's happening in your example is: 1) a = 10 You're creating an integer object with the value 10, and binding the name "a" to that object. 2) b = a You're binding another name, "b" to the same object that "a" is bound to. 3) c = 10 This is the tricky one. You're using 10 again as a literal, and the interpreter is reusing the same existing (interned) integer object, and binding yet another name, "c" to it. This part is implementation dependent. Nothing says Python must intern integer literals, it's entirely free to create a new integer object every time you utter 10 in your source code. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python Basic Doubt
On Sat, Aug 10, 2013 at 4:33 PM, Krishnan Shankar wrote: > Hi Fellow Python Friends, > > I am new to Python and recently subscribed to the mailing list.I have a > doubt regarding the basics of Python. Please help me in understanding the > below concept. > > So doubt is on variables and their contained value. Tangential to this: Python doesn't have "variables" that "contain" anything, but rather has names that are bound to (point to, if you like) objects. You're mostly right, this is just a terminology point. > Why does in the below example from Interpreter exploration value of c take > pre existing memory location. > a=10 id(a) > 21665504 b=a id(b) > 21665504 c=10 id(c) > 21665504 > > I am actually assigning new value to c. But from the value of id() all three > variables take same location. With variables a and b it is ok. But why c > taking the same location? CPython caches a number of integer objects for efficiency. Whenever you ask for the integer 10, you'll get the _same_ integer 10. But if you try the same exercise with a much higher number, or with a different value, you should get a unique id. With immutable literals, the interpreter's allowed to reuse them. You don't normally care about the id() of an integer, and nor should you. Same goes for strings; the interpreter's allowed to intern them if it chooses. Generally, don't assume that they're different, don't assume they're the same either. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Python Basic Doubt
On 8/10/2013 11:33 AM, Krishnan Shankar wrote: Hi Fellow Python Friends, I am new to Python and recently subscribed to the mailing list.I have a doubt regarding the basics of Python. Please help me in understanding the below concept. So doubt is on variables and their contained value. It would be better English to say that you have a 'question' or even 'confusion', rather than a 'doubt'. From your subject line, I got the impression that you doubted that you should learn or use Python. That clearly is not what you meant. -- Terry Jan Reedy -- http://mail.python.org/mailman/listinfo/python-list
Re: Python Basic Doubt
Hello,
El 10/08/2013 18:40, Tim Chase escribió:
Generally, if you are using the "is" operator to compare against
anything other than None, you're doing it wrong. There are exceptions
to this, but it takes knowing the particulars.
Now I have one doubt, I use 'is' to compare basic types in python 3, for
example .-
v = []
if type(v) is list:
print('Is list...')
Because I think it is more clear and faster than .-
type(v) == [].__class__ ... or ... isinstance(v, list)
Is this correct?
Thanks.
--
Xavi
--
http://mail.python.org/mailman/listinfo/python-list
The meaning of "doubt", was Re: Python Basic Doubt
Terry Reedy wrote: > On 8/10/2013 11:33 AM, Krishnan Shankar wrote: >> Hi Fellow Python Friends, >> >> I am new to Python and recently subscribed to the mailing list.I have a >> doubt regarding the basics of Python. Please help me in understanding >> the below concept. >> >> So doubt is on variables and their contained value. > > It would be better English to say that you have a 'question' or even > 'confusion', rather than a 'doubt'. From your subject line, I got the > impression that you doubted that you should learn or use Python. That > clearly is not what you meant. Quoting http://en.wikipedia.org/wiki/Indian_English """ doubt = question or query; e.g. one would say, 'I have a doubt' when one wishes to ask a question. """ I'd say if Brits can cope (hard as it may be) with the American variant of the language, and native speakers can live with the broken English used to communicate in the rest of the world there is ample room for an Indian flavo(u)r now and then... -- http://mail.python.org/mailman/listinfo/python-list
Re: The meaning of "doubt", was Re: Python Basic Doubt
In article , Peter Otten <__pete...@web.de> wrote: > Quoting http://en.wikipedia.org/wiki/Indian_English > > """ > doubt = question or query; e.g. one would say, 'I have a doubt' when one > wishes to ask a question. > """ > > I'd say if Brits can cope (hard as it may be) with the American variant of > the language, and native speakers can live with the broken English used to > communicate in the rest of the world there is ample room for an Indian > flavo(u)r now and then... Yup. I used to work with a development team in Bangalore. One of the amusing aspects of the collaboration was the subtle language issues. For example, apparently, "Roy" is a common *last* name in India. No matter how many times I explained it, the guys over there couldn't seem to get that Roy is my first name and Smith is my last name. So, in settings where everybody was using first names, they would always call me Smith. I shudder to think what carnage I accidentally inflicted on their names :-) And, of course, since we're on the subject, this should be required reading for all programmers: http://www.kalzumeus.com/2010/06/17/falsehoods-programmers-believe-about- names/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 3 and SSH Tunnel
I think I missed an earlier thread of this and I'm not quite sure what your application is, but properly allocating user permissions on your databases should eliminate any security concerns there. Also, for the tunnel, whether you're using one account or multiple (one for each user), those accounts should be properly secured as well. Ignotus On 08/10/2013 06:39 AM, D. Xenakis wrote: What about the security though? To be specific, i need to create an application (python 3.3 strictly) where users will save/load their settings online to a remote hosted database. I do not wish to change the database from listening to any other thing than localhost for security reasons, so i assume the best solution for me would be to make the program create some ssh tunnels before the saving/loading happens. But would this policy make my database (or the rest of the databases that im running on that machine) unsecure? Is there any workaround this? How would you do that online saving/loading? -- http://mail.python.org/mailman/listinfo/python-list
Re: Python Basic Doubt
On Sat, 10 Aug 2013 20:00:58 +0200, Xavi wrote:
> Now I have one doubt, I use 'is' to compare basic types in python 3, for
> example .-
>
> v = []
> if type(v) is list:
> print('Is list...')
No, do not do this. This is unnecessarily restrictive.
> Because I think it is more clear and faster than .-
Clear? Maybe. Clear, but does the wrong thing. Using type rejects
subclasses, which is normally a bad idea. Using isinstance accepts
subclasses, which is what we nearly always should do.
As for being faster -- who cares? The difference between calling type and
calling isinstance is about 0.02 microseconds on my slow computer. You
should not try to optimize things which are so unimportant.
The first rule of optimization: Don't do it.
For experts only: Don't do it yet.
Until you have profiled your application, and discovered calling
isinstance is the bottleneck making your application too slow, you are
wasting your time trying to guess what will make it go faster.
> type(v) == [].__class__
You should not do that either. Names starting and ending with double-
underscore are reserved for Python. They are not quite private
implementation details, but you almost never need to use them directly.
Why keep a dog and then bark yourself? Python will check __class__ for
you, when and if needed. That is not your job. It is very rare to need to
use __dunder__ attributes by hand.
> ... or ... isinstance(v, list)
That's the right solution, 99.9% of the time.
Actually, 99% of the time you should not call isinstance at all, but just
catch any errors that occur; or better still, only catch them if you can
do something about it. Otherwise, just allow the exception to propagate
to the caller, who may catch it. Calling isinstance should be rare;
calling type to check for an exact class even rarer.
--
Steven
--
http://mail.python.org/mailman/listinfo/python-list
Re: The meaning of "doubt", was Re: Python Basic Doubt
On Sat, 10 Aug 2013 20:36:52 +0200, Peter Otten wrote: > Terry Reedy wrote: > >> On 8/10/2013 11:33 AM, Krishnan Shankar wrote: >>> Hi Fellow Python Friends, >>> >>> I am new to Python and recently subscribed to the mailing list.I have >>> a doubt regarding the basics of Python. Please help me in >>> understanding the below concept. >>> >>> So doubt is on variables and their contained value. >> >> It would be better English to say that you have a 'question' or even >> 'confusion', rather than a 'doubt'. From your subject line, I got the >> impression that you doubted that you should learn or use Python. That >> clearly is not what you meant. > > Quoting http://en.wikipedia.org/wiki/Indian_English > > """ > doubt = question or query; e.g. one would say, 'I have a doubt' when one > wishes to ask a question. > """ > > I'd say if Brits can cope (hard as it may be) with the American variant > of the language, and native speakers can live with the broken English > used to communicate in the rest of the world there is ample room for an > Indian flavo(u)r now and then... +1 Ill take broken English from a non native speaker over the confusion caused by our American cousins who seam to have everything arse about face (especially if you consider the word "Fanny" ) Seriously though I can usually work out what the meaning was, & it is certainly clearer than any attempt I could make in any other language, which is actually quite shameful. -- My way of joking is to tell the truth. That's the funniest joke in the world. -- Muhammad Ali -- http://mail.python.org/mailman/listinfo/python-list
Re: Python Basic Doubt
On 8/10/2013 2:00 PM, Xavi wrote:
Hello,
El 10/08/2013 18:40, Tim Chase escribió:
Generally, if you are using the "is" operator to compare against
anything other than None, you're doing it wrong. There are exceptions
to this, but it takes knowing the particulars.
Now I have one doubt, I use 'is' to compare basic types in python 3, for
example .-
v = []
if type(v) is list:
print('Is list...')
Because I think it is more clear and faster than .-
type(v) == [].__class__ ... or ... isinstance(v, list)
Is this correct?
It depends on the context. If one is writing a test for a function that
is defined as returning a list, such as the builtin function *sorted*,
then 'is list' would be correct.
When one knows the type, as in your toy snippet, 'is list' is nonsensical.
In a more typical situation, as when testing the argument to a function
in the body of a function, then 'isinstance(arg, list)' is almost
certainly more correct (but often still not best) as the function should
usually accept at least any list subclass instance.
def popslice(lis, start, stop=None, step=0):
if not isinstance(lis, list):
raise TypeError("Can only popslice a list")
if stop is None: # here is where is *should* be used
start, stop = 0, start
ret = lis[start:stop:step]
del lis[start:stop:step]
return ret
lis = list(range(10))
print(popslice(lis, 2, 9, 2), lis)
>>>
[2, 4, 6, 8] [0, 1, 3, 5, 7, 9]
However, why exclude a mutable sequence that support slices but is not
specifically a list?
def popslice(seq, start, stop=None, step=0):
if stop is None: # here is where is *should* be used
start, stop = 0, start
ret = seq[start:stop:step]
del seq[start:stop:step]
return ret
Bad inputs will raise TypeErrors.
TypeError: 'int' object is not subscriptable
TypeError: 'tuple' object doesn't support item deletion
It this is not good enough, wrap the body in
try:
...
except TypeError as e:
raise TypeError("your custom message here")
--
Terry Jan Reedy
--
http://mail.python.org/mailman/listinfo/python-list
Re: The meaning of "doubt", was Re: Python Basic Doubt
On 8/10/2013 2:36 PM, Peter Otten wrote: Terry Reedy wrote: On 8/10/2013 11:33 AM, Krishnan Shankar wrote: Hi Fellow Python Friends, I am new to Python and recently subscribed to the mailing list.I have a doubt regarding the basics of Python. Please help me in understanding the below concept. So doubt is on variables and their contained value. It would be better English to say that you have a 'question' or even 'confusion', rather than a 'doubt'. From your subject line, I got the impression that you doubted that you should learn or use Python. That clearly is not what you meant. Quoting http://en.wikipedia.org/wiki/Indian_English """ doubt = question or query; e.g. one would say, 'I have a doubt' when one wishes to ask a question. """ Thank you for verifying by suspicion (in the neutral sense) that this might be a generic Indian English usage. I'd say if Brits can cope (hard as it may be) with the American variant of the language, and native speakers can live with the broken English used to communicate in the rest of the world there is ample room for an Indian flavo(u)r now and then... The issue I raised was one of avoiding misunderstanding, especially in a short subject line. I almost skipped over the post because of it. I could have added a recommendation to be more specific. Any of "Question/confusion/doubt about int identity" would have been better. -- Terry Jan Reedy -- http://mail.python.org/mailman/listinfo/python-list
How many times does unittest run each test?
I am working on a library, and adding one feature broke a seemingly unrelated
feature. As I already had Test Cases written, I decided to try to incorporate
the logging module into my class, and turn on debugging at the logger before
the newly-broken test.
Here is an example script:
# -
#!/usr/bin/env python
import logging
def get_vals():
return ['a','b','c']
class SimpleChecker(object):
def __init__(self, callback=None):
self.callback = callback
self.logger = logging.getLogger(self.__class__.__name__)
h = logging.StreamHandler()
f = logging.Formatter("%(name)s - %(levelname)s - %(message)s")
h.setFormatter(f)
self.logger.addHandler(h)
def __call__(self, thing):
self.logger.debug('calling %s' % thing)
vals = self.callback()
return thing in vals
import unittest
class LoaderTC(unittest.TestCase):
def setUp(self):
self.checker = SimpleChecker(get_vals)
def tearDown(self):
del self.checker
def test_callable(self):
self.assertTrue(callable(self.checker),
'loader did not create callable object')
self.assertTrue(callable(self.checker.callback),
'loader did not create callable callback')
self.checker.logger.setLevel(logging.DEBUG)
self.assertTrue(self.checker('q') is False, "checker accepted bad
input")
class NameSpaceTC(unittest.TestCase):
def setUp(self):
self.checker = SimpleChecker(get_vals)
def tearDown(self):
del self.checker
def test_callable(self):
self.assertTrue(callable(self.checker),
'loader did not create callable object')
self.assertTrue(callable(self.checker.callback),
'loader did not create callable callback')
self.checker.logger.setLevel(logging.DEBUG)
self.assertTrue(self.checker('a'), "checker did not accept good value")
self.assertFalse(self.checker('f'), "checker accepted bad value")
if __name__=='__main__':
unittest.main(verbosity=0)
# ---
When I run this, I get:
SimpleChecker - DEBUG - calling q
SimpleChecker - DEBUG - calling a
SimpleChecker - DEBUG - calling a
SimpleChecker - DEBUG - calling f
SimpleChecker - DEBUG - calling f
--
Ran 2 tests in 0.013s
OK
Exit code: False
Why am I seeing those extra debugging lines? In the script I'm really trying to
debug, I see 12-13 debug messages repeated, making actual debugging difficult.
Josh English
--
http://mail.python.org/mailman/listinfo/python-list
Re: How many times does unittest run each test?
In article , Josh English wrote: > I am working on a library, and adding one feature broke a seemingly unrelated > feature. As I already had Test Cases written, I decided to try to incorporate > the logging module into my class, and turn on debugging at the logger before > the newly-broken test. > > Here is an example script: [followed by 60 lines of code] The first thing to do is get this down to some minimal amount of code that demonstrates the problem. For example, you drag in the logging module, and do some semi-complex configuration. Are you SURE your tests are getting run multiple times, or maybe it's just that they're getting LOGGED multiple times. Tear out all the logging stuff. Just use a plain print statement. You've got two different TestCases here. Does the problem happen with just LoaderTC, or with just NameSpaceTC? Keep tearing out code until you can no longer demonstrate the problem. Keep at it until there is not a single line of code remaining which isn't required to demonstrate. Then come back and ask your question again. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python Basic Doubt
In article , Dennis Lee Bieber wrote: > Because id(n) is not giving you the address of the NAME. It is giving > you the address of the "10" Actually, it is giving you the id of the int(10) object. Maybe it's an address, maybe it's not. Only your implementation knows for sure. -- http://mail.python.org/mailman/listinfo/python-list
Re: The meaning of "doubt", was Re: Python Basic Doubt
Peter Otten wrote: > > doubt > Oh bother, said Pooh, what's in a word ? http://en.wikipedia.org/wiki/Curry https://pypi.python.org/pypi/curry/ http://en.wikipedia.org/wiki/Currying -- Stanley C. Kitching Human Being Phoenix, Arizona -- http://mail.python.org/mailman/listinfo/python-list
Re: Python Basic Doubt
On Sat, Aug 10, 2013 at 7:00 PM, Xavi wrote:
> Now I have one doubt, I use 'is' to compare basic types in python 3, for
> example .-
>
> v = []
> if type(v) is list:
> print('Is list...')
>
> Because I think it is more clear and faster than .-
> type(v) == [].__class__ ... or ... isinstance(v, list)
>
> Is this correct?
> Thanks.
This really should be a separate thread, rather than a follow-up to
the previous one, since it's quite unrelated. But anyway.
The isinstance check is the better one, because it will also accept a
subclass of list, which the others won't.
ChrisA
--
http://mail.python.org/mailman/listinfo/python-list
Re: Python Basic Doubt
On 08/10/2013 11:00 AM, Xavi wrote:
Hello,
El 10/08/2013 18:40, Tim Chase escribió:
Generally, if you are using the "is" operator to compare against
anything other than None, you're doing it wrong. There are exceptions
to this, but it takes knowing the particulars.
Now I have one doubt, I use 'is' to compare basic types in python 3,
for example .-
v = []
if type(v) is list:
print('Is list...')
Because I think it is more clear and faster than .-
type(v) == [].__class__ ... or ... isinstance(v, list)
Is this correct?
Thanks.
No! Don't do that! If you want to compare values use the "==" operator.
This is an oversimplification, but generally useful for all beginner
(and most advanced) programmers:
Don't use "is" for comparisons. Use "==".
It 20 years of programming Python, I've *needed* to use "is" ... only
once or twice.
Beyond that, there is a small batch of comparisons where "is" is
slightly more Pythonic, but not really necessary. And beyond that,
there are several instances where the difference between "is" and "==""
are important.
Mostly, using "is" is inappropriate and will get you into compassions
that depend on implementation details. For instance don't use "is"
until you understand this:
q:~> python3
Python 3.3.1 (default, Apr 17 2013, 22:32:14)
[GCC 4.7.3] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> 101 is 1+100
True
>>> 1001 is 1+1000
False
Gary Herron
--
http://mail.python.org/mailman/listinfo/python-list
Re: Python Basic Doubt
On Sat, Aug 10, 2013 at 10:48 PM, Gary Herron wrote: > This is an oversimplification, but generally useful for all beginner (and > most advanced) programmers: > Don't use "is" for comparisons. Use "==". > It 20 years of programming Python, I've *needed* to use "is" ... only once > or twice. Hrm, I wouldn't make it that hard a rule. Both comparisons have their place. As has been mentioned earlier in this thread, checking if something is None is spelled "if something is None". Checking if it equals zero is spelled "if it == 0", which is a quite different check. The other common check that uses 'is' is with an argument default where absolutely anything could be passed: _notpassed = object() def frob(appendage, device=_notpassed): """Use some appendage to frob some device, or None to frob nothing. Omit device to frob whatever is currently held in that appendage""" if device is _notpassed: device = ... # whatever you need if device is not None: # frob the device But granted, equality comparisons are a LOT more common than identity comparisons. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: How many times does unittest run each test?
On Saturday, August 10, 2013 1:40:43 PM UTC-7, Roy Smith wrote:
> In article ,
>
> Josh English wrote:
> The first thing to do is get this down to some minimal amount of code
> that demonstrates the problem.
>
>
>
> For example, you drag in the logging module, and do some semi-complex
> configuration. Are you SURE your tests are getting run multiple times,
> or maybe it's just that they're getting LOGGED multiple times. Tear out
> all the logging stuff. Just use a plain print statement.
>
> You've got two different TestCases here. Does the problem happen with
> just LoaderTC, or with just NameSpaceTC?
>
Ok, then why would things get logged multiple times? The two test cases
actually test a loader function that I could strip out, because it wasn't
relevant. In these cases, the loader was being called with two different
configurations in the individual setUp methods.
I left them there to show that in LoaderTC, there is one debug log coming from
SimpleChecker, but in the NameSpaceTC, each debug message is printed twice. If
I print statements on each test_ method, they are called once.
As far as stripping down the code, I suppose 15 lines can be culled:
#-
import logging
class SimpleChecker(object):
def __init__(self,):
self.logger = logging.getLogger(self.__class__.__name__)
h = logging.StreamHandler()
f = logging.Formatter("%(name)s - %(levelname)s - %(message)s")
h.setFormatter(f)
self.logger.addHandler(h)
def __call__(self, thing):
self.logger.debug('calling %s' % thing)
return thing in ['a','b','c']
import unittest
class LoaderTC(unittest.TestCase):
def setUp(self):
self.checker = SimpleChecker()
def tearDown(self):
del self.checker
def test_callable(self):
self.checker.logger.setLevel(logging.DEBUG)
self.assertTrue(self.checker('q') is False, "checker accepted bad
input")
class NameSpaceTC(unittest.TestCase):
def setUp(self):
self.checker = SimpleChecker()
def tearDown(self):
del self.checker
def test_callable(self):
print "testing callable"
self.checker.logger.setLevel(logging.DEBUG)
self.assertTrue(self.checker('a'), "checker did not accept good value")
self.assertFalse(self.checker('f'), "checker accepted bad value")
if __name__=='__main__':
unittest.main(verbosity=0)
#---
The output:
SimpleChecker - DEBUG - calling q
setting up NameSpace
testing callable
SimpleChecker - DEBUG - calling a
SimpleChecker - DEBUG - calling a
SimpleChecker - DEBUG - calling f
SimpleChecker - DEBUG - calling f
--
Ran 2 tests in 0.014s
OK
Exit code: False
Josh
--
http://mail.python.org/mailman/listinfo/python-list
Re: How many times does unittest run each test?
Aha. Thanks, Ned. This is the answer I was looking for. I use logging in the real classes, and thought that turning setting the level to logging.DEBUG once was easier than hunting down four score of print statements. Josh On Sat, Aug 10, 2013 at 3:52 PM, Ned Batchelder wrote: > On 8/10/13 4:40 PM, Roy Smith wrote: >> >> In article , >> Josh English wrote: >> >>> I am working on a library, and adding one feature broke a seemingly >>> unrelated >>> feature. As I already had Test Cases written, I decided to try to >>> incorporate >>> the logging module into my class, and turn on debugging at the logger >>> before >>> the newly-broken test. >>> >>> Here is an example script: >> >> [followed by 60 lines of code] >> >> The first thing to do is get this down to some minimal amount of code >> that demonstrates the problem. >> >> For example, you drag in the logging module, and do some semi-complex >> configuration. Are you SURE your tests are getting run multiple times, >> or maybe it's just that they're getting LOGGED multiple times. Tear out >> all the logging stuff. Just use a plain print statement. > > Roy is right: the problem isn't the tests, it's the logging. You are > calling .addHandler in the SimpleChecker.__init__, then you are constructing > two SimpleCheckers, each of which adds a handler. In the LoaderTC test, > you've only constructed one, adding only one handler, so the "calling q" > line only appears once. Then the NameSpaceTC tests runs, constructs another > SimplerChecker, which adds another handler, so now there are two. That's > why the "calling a" and "calling f" lines appear twice. > > Move your logging configuration to a place that executes only once. > > Also, btw, you don't need the "del self.checker" in your tearDown methods: > the test object is destroyed after each test, so any objects it holds will > be released after each test with no special action needed on your part. > > --Ned. -- Josh English joshua.r.engl...@gmail.com http://www.joshuarenglish.com -- http://mail.python.org/mailman/listinfo/python-list
Re: How many times does unittest run each test?
On Saturday, August 10, 2013 1:40:43 PM UTC-7, Roy Smith wrote: > > For example, you drag in the logging module, and do some semi-complex > > configuration. Are you SURE your tests are getting run multiple times, > > or maybe it's just that they're getting LOGGED multiple times. Tear out > > all the logging stuff. Just use a plain print statement. In article <35d12db6-c367-4a45-a68e-8ed4c0ae1...@googlegroups.com>, Josh English wrote: > Ok, then why would things get logged multiple times? Maybe you've got two different handlers which are both getting the same logging events and somehow they both end up in your stderr stream. Likely? Maybe not, but if you don't have any logging code in the test at all, it becomes impossible. You can't have a bug in a line of code that doesn't exist (yeah, I know, that's a bit of a handwave). When a test (or any other code) is doing something you don't understand, the best way to start understanding it is to create a minimal test case; the absolute smallest amount of code that demonstrates the problem. I don't understand the whole SimpleChecker class. You've created a class, and defined your own __call__(), just so you can check if a string is in a list? Couldn't this be done much simpler with a plain old function: def checker(thing): print "calling %s" % thing return thing in ['a','b','c'] -- http://mail.python.org/mailman/listinfo/python-list
Re: How many times does unittest run each test?
On Sun, Aug 11, 2013 at 12:14 AM, Roy Smith wrote:
> Maybe you've got two different handlers which are both getting the same
> logging events and somehow they both end up in your stderr stream.
> Likely? Maybe not, but if you don't have any logging code in the test
> at all, it becomes impossible. You can't have a bug in a line of code
> that doesn't exist (yeah, I know, that's a bit of a handwave).
Likely? Very much so, to the extent that it is, if not a FAQ,
certainly a Not All That Uncommonly Asked Question. So many times
someone places logging code in something that gets called twice, and
ends up with two handlers. Personally, I much prefer to debug with
straight-up 'print' - much less hassle. I'd turn to the logging module
only if I actually need its functionality (logging to some place other
than the console, or leaving the log statements in and {en|dis}abling
them at run-time).
ChrisA
--
http://mail.python.org/mailman/listinfo/python-list
Re: How many times does unittest run each test?
On 8/10/13 4:40 PM, Roy Smith wrote: In article , Josh English wrote: I am working on a library, and adding one feature broke a seemingly unrelated feature. As I already had Test Cases written, I decided to try to incorporate the logging module into my class, and turn on debugging at the logger before the newly-broken test. Here is an example script: [followed by 60 lines of code] The first thing to do is get this down to some minimal amount of code that demonstrates the problem. For example, you drag in the logging module, and do some semi-complex configuration. Are you SURE your tests are getting run multiple times, or maybe it's just that they're getting LOGGED multiple times. Tear out all the logging stuff. Just use a plain print statement. Roy is right: the problem isn't the tests, it's the logging. You are calling .addHandler in the SimpleChecker.__init__, then you are constructing two SimpleCheckers, each of which adds a handler. In the LoaderTC test, you've only constructed one, adding only one handler, so the "calling q" line only appears once. Then the NameSpaceTC tests runs, constructs another SimplerChecker, which adds another handler, so now there are two. That's why the "calling a" and "calling f" lines appear twice. Move your logging configuration to a place that executes only once. Also, btw, you don't need the "del self.checker" in your tearDown methods: the test object is destroyed after each test, so any objects it holds will be released after each test with no special action needed on your part. --Ned. -- http://mail.python.org/mailman/listinfo/python-list
Re: How many times does unittest run each test?
On Saturday, August 10, 2013 4:14:09 PM UTC-7, Roy Smith wrote: > > > I don't understand the whole SimpleChecker class. You've created a > class, and defined your own __call__(), just so you can check if a > string is in a list? Couldn't this be done much simpler with a plain > old function: > > def checker(thing): > print "calling %s" % thing > return thing in ['a','b','c'] SimpleCheck is an extremely watered down version of my XML checker (https://pypi.python.org/pypi/XMLCheck/0.6.7). I'm working a feature that allows the checker to call a function to get acceptable values, instead of defining them at the start of the program. I included all of that because it's the shape of the script I'm working with. The real problem was setting additional handlers where they shouldn't be. Josh -- http://mail.python.org/mailman/listinfo/python-list
Re: Python Basic Doubt
On 08/10/2013 03:09 PM, Chris Angelico wrote: On Sat, Aug 10, 2013 at 10:48 PM, Gary Herron wrote: This is an oversimplification, but generally useful for all beginner (and most advanced) programmers: Don't use "is" for comparisons. Use "==". It 20 years of programming Python, I've *needed* to use "is" ... only once or twice. Hrm, I wouldn't make it that hard a rule. Both comparisons have their place. As has been mentioned earlier in this thread, checking if something is None is spelled "if something is None". Checking if it equals zero is spelled "if it == 0", which is a quite different check. The other common check that uses 'is' is with an argument default where absolutely anything could be passed: _notpassed = object() def frob(appendage, device=_notpassed): """Use some appendage to frob some device, or None to frob nothing. Omit device to frob whatever is currently held in that appendage""" if device is _notpassed: device = ... # whatever you need if device is not None: # frob the device But granted, equality comparisons are a LOT more common than identity comparisons. ChrisA Everything you say is true, and even reasonable for those who know what's up. But for each of your examples, using "==" is equivalent to using "is". Each of if something == None if device == _not passed if device != None would all work as expected. In none of those cases is "is" actually needed. Given that, and the implementation dependent oddities, I still believe that it is *highly* misleading to teach a beginner about "is". Here's a challenge: What is the simplest non-contrived example where an "is" comparison is *required*. Where substitution of an "==" comparison would cause the program to fail or be significantly less efficient? (I'm not including the nearly immeasurably small timing difference between v==None and v is None.) Gary Herron -- http://mail.python.org/mailman/listinfo/python-list
Re: How many times does unittest run each test?
On Saturday, August 10, 2013 4:21:35 PM UTC-7, Chris Angelico wrote:
> On Sun, Aug 11, 2013 at 12:14 AM, Roy Smith <> wrote:
>
> > Maybe you've got two different handlers which are both getting the same
> > loggingvents and somehow they both end up in your stderr stream.
> > Likely? Maybe not, but if you don't have any logging code in the test
> > at all, it becomes impossible. You can't have a bug in a line of code
> > that doesn't exist (yeah, I know, that's a bit of a handwave).
>
> Likely? Very much so, to the extent that it is, if not a FAQ,
> certainly a Not All That Uncommonly Asked Question. So many times
> someone places logging code in something that gets called twice, and
> ends up with two handlers. Personally, I much prefer to debug with
> straight-up 'print' - much less hassle. I'd turn to the logging module
> only if I actually need its functionality (logging to some place other
> than the console, or leaving the log statements in and {en|dis}abling
> them at run-time).
Yes, I definitely need the NUATAQ sheet for Python.
I'm using logging for debugging, because it is pretty straightforward and can
be activated for a small section of the module. My modules run long (3,000
lines or so) and finding all those dastardly print statements is a pain, and
littering my code with "if debug: print message" clauses. Logging just makes it
simple.
Josh
--
http://mail.python.org/mailman/listinfo/python-list
Re: Python Basic Doubt
On Sun, Aug 11, 2013 at 1:42 AM, Gary Herron wrote: > On 08/10/2013 03:09 PM, Chris Angelico wrote: >> _notpassed = object() >> def frob(appendage, device=_notpassed): >> """Use some appendage to frob some device, or None to frob nothing. >> Omit device to frob whatever is currently held in that appendage""" >> if device is _notpassed: >> device = ... # whatever you need >> if device is not None: >> # frob the device >> >> But granted, equality comparisons are a LOT more common than identity >> comparisons. >> >> ChrisA > > > Everything you say is true, and even reasonable for those who know what's > up. > > But for each of your examples, using "==" is equivalent to using "is". Each > of > if something == None > if device == _not passed > if device != None > would all work as expected. In none of those cases is "is" actually needed. Wrong. If you do equality comparisons, it's entirely possible for something to be passed in that compares equal to the RHS without actually being it, so "is" is precisely what's wanted. (Plus, why go through a potentially expensive comparison check when you can simply check object identity - which could be, for instance, an address check? But performance is a distant second to correctness here.) > Given that, and the implementation dependent oddities, I still believe that > it is *highly* misleading to teach a beginner about "is". > > Here's a challenge: What is the simplest non-contrived example where an > "is" comparison is *required*. Where substitution of an "==" comparison > would cause the program to fail or be significantly less efficient? (I'm > not including the nearly immeasurably small timing difference between > v==None and v is None.) All it takes is a slightly odd or buggy __eq__ implementation and the == versions will misbehave. To check if an argument is something, you use "is", not ==. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: How many times does unittest run each test?
On Sun, Aug 11, 2013 at 1:52 AM, Josh English wrote: > I'm using logging for debugging, because it is pretty straightforward and can > be activated for a small section of the module. My modules run long (3,000 > lines or so) and finding all those dastardly print statements is a pain, and > littering my code with "if debug: print message" clauses. Logging just makes > it simple. So logging might be the right tool for your job. Tip: Sometimes it helps, when trying to pin down an issue, to use an additional debugging aid. You're already using logging? Add print calls. Already got a heartbeat function? Run it through a single-stepping debugger as well. Usually that sort of thing just gives you multiple probes at the actual problem, but occasionally you'll get an issue like this, and suddenly it's really obvious because one probe behaves completely differently from the other. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Python Basic Doubt
On 8/10/2013 8:42 PM, Gary Herron wrote:
But for each of your examples, using "==" is equivalent to using "is".
Each of
if something == None
if device == _not passed
if device != None
would all work as expected. In none of those cases is "is" actually
needed.
class EqualAll:
def __eq__(self, other): return True
ea = EqualAll()
print(ea == None)
print(ea == float('nan'))
>>>
True
True
--
Terry Jan Reedy
--
http://mail.python.org/mailman/listinfo/python-list
Re: Python Basic Doubt
On Sun, Aug 11, 2013 at 2:25 AM, Terry Reedy wrote: > On 8/10/2013 8:42 PM, Gary Herron wrote: > >> But for each of your examples, using "==" is equivalent to using "is". >> Each of >> if something == None >> if device == _not passed >> if device != None >> would all work as expected. In none of those cases is "is" actually >> needed. > > > class EqualAll: > def __eq__(self, other): return True That's a contrived example, of course, but it's easy to have a bug in __eq__ that results in the same behaviour. I can't imagine any code that would actually WANT that, unless you're trying to represent Animal Farm. class EqualAll: def __eq__(self, other): if (isinstance(other, pig): return 3 # Some are more equal than others return True ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Am I not seeing the Error?
I am checking my 1292-line script for syntax errors. I ran the following
commands in a terminal to check for errors, but I do not see the error.
collier@Nacho-Laptop:/media/collier/AI/Pysh$ python3 -m py_compile
./beta_engine
File "./beta_engine", line 344
JOB_WRITEURGFILES =
multiprocessing.Process(write2file('./mem/ENGINE_PID', ENGINEPID);
write2file(SENTEMPPATH, ''); write2file(INPUTMEM, ''));
JOB_WRITEURGFILES.start()
^
SyntaxError: invalid syntax
collier@Nacho-Laptop:/media/collier/AI/Pysh$ pylint ./beta_engine
No config file found, using default configuration
* Module beta_engine
E:344,0: invalid syntax
Here is line 344:
JOB_WRITEURGFILES =
multiprocessing.Process(write2file('./mem/ENGINE_PID', ENGINEPID);
write2file(SENTEMPPATH, ''); write2file(INPUTMEM, ''));
JOB_WRITEURGFILES.start()
The ENGINEPID is a variable containing a string. My write2file function is
def write2file(openfile, WRITE):
with open(openfile, 'rw') as file:
file.write(WRITE)
Mahalo,
devyncjohn...@gmail.com
--
http://mail.python.org/mailman/listinfo/python-list
Re: Am I not seeing the Error?
On Sun, Aug 11, 2013 at 3:19 AM, Devyn Collier Johnson
wrote:
> am checking my 1292-line script for syntax errors. I ran the following
> commands in a terminal to check for errors, but I do not see the error.
>
> collier@Nacho-Laptop:/media/collier/AI/Pysh$ python3 -m py_compile
> ./beta_engine
> File "./beta_engine", line 344
> JOB_WRITEURGFILES =
> multiprocessing.Process(write2file('./mem/ENGINE_PID', ENGINEPID);
> write2file(SENTEMPPATH, ''); write2file(INPUTMEM, ''));
> JOB_WRITEURGFILES.start()
> ^
> SyntaxError: invalid syntax
When you get a syntax error you can't understand, look at the previous
line of code. Perhaps something there is incomplete; maybe you have
mismatched parentheses, so this line is considered to be part of the
same expression.
Next thing to do is split it into more lines. Why is all that in a single line?
ChrisA
--
http://mail.python.org/mailman/listinfo/python-list
Re: Am I not seeing the Error?
In article , Chris Angelico wrote: > When you get a syntax error you can't understand, look at the previous > line of code. Perhaps something there is incomplete; maybe you have > mismatched parentheses, so this line is considered to be part of the > same expression. > > Next thing to do is split it into more lines. Why is all that in a single > line? Also, try reformatting the code in a tool like emacs or eclipse which does syntax coloring and auto indenting. Often, if you're missing some piece of punctuation, it will become obvious when your tool tries to indent things in some unexpected way. Or suddenly starts coloring all of your program text as if it were a string literal :-) -- http://mail.python.org/mailman/listinfo/python-list
Re: Am I not seeing the Error?
On Sun, Aug 11, 2013 at 3:43 AM, Roy Smith wrote: > In article , > Chris Angelico wrote: > >> When you get a syntax error you can't understand, look at the previous >> line of code. Perhaps something there is incomplete; maybe you have >> mismatched parentheses, so this line is considered to be part of the >> same expression. >> >> Next thing to do is split it into more lines. Why is all that in a single >> line? > > Also, try reformatting the code in a tool like emacs or eclipse which > does syntax coloring and auto indenting. Often, if you're missing some > piece of punctuation, it will become obvious when your tool tries to > indent things in some unexpected way. Or suddenly starts coloring all > of your program text as if it were a string literal :-) Agreed. Though I've had some odd issues with SciTE in that way; I think its Python handling may have bugs in it here and there. But 95% of the time it's helpful. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Am I not seeing the Error?
On 8/10/2013 10:19 PM, Devyn Collier Johnson wrote:
I am checking my 1292-line script for syntax errors. I ran the following
commands in a terminal to check for errors, but I do not see the error.
collier@Nacho-Laptop:/media/collier/AI/Pysh$ python3 -m py_compile
./beta_engine
File "./beta_engine", line 344
JOB_WRITEURGFILES =
multiprocessing.Process(write2file('./mem/ENGINE_PID', ENGINEPID);
That should be a comma; so should the next semicolon below.
write2file(SENTEMPPATH, ''); write2file(INPUTMEM, ''));
This last one is 'correct', but delete it
JOB_WRITEURGFILES.start()
and put this statement on a line by itself.
--
Terry Jan Reedy
--
http://mail.python.org/mailman/listinfo/python-list
Re: Python Basic Doubt
Thanks Tim, This takes me to one more question. 'is' operator is used to compare objects and it should not be used to compare data. So can it be compared with 'False'. i.e. Is this code possible if a is False: print 'Yes' if b is False: print 'No' Because i recommended this should not be done. But my colleagues say it is correct. Regards, Krishnan On Sat, Aug 10, 2013 at 10:10 PM, Tim Chase wrote: > On 2013-08-10 21:03, Krishnan Shankar wrote: > > >>> a=10 > > >>> id(a) > > 21665504 > > >>> b=a > > >>> id(b) > > 21665504 > > >>> c=10 > > >>> id(c) > > 21665504 > > > > I am actually assigning new value to c. But from the value of id() > > all three variables take same location. With variables a and b it > > is ok. But why c taking the same location? > > As an internal optimization, CPython caches small integer values > > >>> a = 256 > >>> b = 256 > >>> a is b > True > >>> a = 257 > >>> b = 257 > >>> a is b > False > > Because it's an internal implementation detail, you shouldn't count > on this behavior (Jython or Cython or IronPython may differ; or > future versions of Python may cache a different range of numbers). > > Generally, if you are using the "is" operator to compare against > anything other than None, you're doing it wrong. There are exceptions > to this, but it takes knowing the particulars. > > -tkc > > > > -- http://mail.python.org/mailman/listinfo/python-list
Re: Python Basic Doubt
On Sun, Aug 11, 2013 at 4:09 AM, Krishnan Shankar wrote: > i.e. Is this code possible > > if a is False: > print 'Yes' > if b is False: > print 'No' You would use that if you want to check if a/b is the exact bool value False. Normally you would simply spell it thus: if not a: print 'Yes' if not b: print 'No' which will accept any value and interpret it as either empty (false) or non-empty (true). Using the equality operator here adds another level of potential confusion: >>> 0 == False True >>> [] == False False >>> 0.0 == False True >>> () == False False whereas if you use the normal boolean conversion, those ARE all false: >>> bool(0) False >>> bool([]) False >>> bool(0.0) False >>> bool(()) False ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Python Basic Doubt
On 08/10/2013 08:09 PM, Krishnan Shankar wrote:
Thanks Tim,
This takes me to one more question.
'is' operator is used to compare objects and it should not be used to
compare data.
So can it be compared with 'False'.
i.e. Is this code possible
if a is False:
print 'Yes'
if b is False:
print 'No'
Depends on what you want. If you want to differentiate between a value
of False, and other false-like values 0, (), [], {} and so on, then you
need to be explicit with
if a is False:
Normally, that's not what you want, so you use
if not a:
to catch any of those false-like values.
Because i recommended this should not be done. But my colleagues say
it is correct.
Regards,
Krishnan
On Sat, Aug 10, 2013 at 10:10 PM, Tim Chase
mailto:python.l...@tim.thechases.com>>
wrote:
On 2013-08-10 21:03, Krishnan Shankar wrote:
> >>> a=10
> >>> id(a)
> 21665504
> >>> b=a
> >>> id(b)
> 21665504
> >>> c=10
> >>> id(c)
> 21665504
>
> I am actually assigning new value to c. But from the value of id()
> all three variables take same location. With variables a and b it
> is ok. But why c taking the same location?
As an internal optimization, CPython caches small integer values
>>> a = 256
>>> b = 256
>>> a is b
True
>>> a = 257
>>> b = 257
>>> a is b
False
Because it's an internal implementation detail, you shouldn't count
on this behavior (Jython or Cython or IronPython may differ; or
future versions of Python may cache a different range of numbers).
Generally, if you are using the "is" operator to compare against
anything other than None, you're doing it wrong. There are exceptions
to this, but it takes knowing the particulars.
-tkc
--
http://mail.python.org/mailman/listinfo/python-list
Re: Python Basic Doubt
On 08/10/2013 06:00 PM, Chris Angelico wrote: On Sun, Aug 11, 2013 at 1:42 AM, Gary Herron wrote: On 08/10/2013 03:09 PM, Chris Angelico wrote: _notpassed = object() def frob(appendage, device=_notpassed): """Use some appendage to frob some device, or None to frob nothing. Omit device to frob whatever is currently held in that appendage""" if device is _notpassed: device = ... # whatever you need if device is not None: # frob the device But granted, equality comparisons are a LOT more common than identity comparisons. ChrisA Everything you say is true, and even reasonable for those who know what's up. But for each of your examples, using "==" is equivalent to using "is". Each of if something == None if device == _not passed if device != None would all work as expected. In none of those cases is "is" actually needed. Wrong. If you do equality comparisons, it's entirely possible for something to be passed in that compares equal to the RHS without actually being it, so "is" is precisely what's wanted. (Plus, why go through a potentially expensive comparison check when you can simply check object identity - which could be, for instance, an address check? But performance is a distant second to correctness here.) You're missing my point. Our knee-jerk reaction to beginners using "is" should be: Don't do that! You almost certainly want "==". Consider "is" an advanced topic. Then you can spend as much time as you want trying to coach them into an understanding of the precise details. But until they have that understanding, they are well served by a rule-of-thumb that says: Use "==" not "is" for comparisons. Given that, and the implementation dependent oddities, I still believe that it is *highly* misleading to teach a beginner about "is". Here's a challenge: What is the simplest non-contrived example where an "is" comparison is *required*. Where substitution of an "==" comparison would cause the program to fail or be significantly less efficient? (I'm not including the nearly immeasurably small timing difference between v==None and v is None.) All it takes is a slightly odd or buggy __eq__ implementation and the == versions will misbehave. To check if an argument is something, you use "is", not ==. No, sorry, but any use of the word "is" in an English sentence is way too ambiguous to specify a correct translation into code. To check "if a calculation of some value is a million", you'd write value == 100 not value is 100 even though there are plenty of other examples where "is" would be correct. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Python Basic Doubt
On 08/10/2013 09:09 PM, Krishnan Shankar wrote: > i.e. Is this code possible > > if a is False: > print 'Yes' > if b is False: > print 'No' > > Because i recommended this should not be done. But my colleagues say it is > correct. You are probably correct in your believe that this idiom should be avoided. As Chris says, it's much more pythonic to just use if not a. There is one case where the recommended idiom is to use the 'is' operator. That's when you want an empty list as a default parameter to a function. Since lists are mutable, often times using [] as a default parameter is the wrong thing to do. This is the recommended idiom: def my_func(mylist = None): if mylist is None: mylist = [] -- http://mail.python.org/mailman/listinfo/python-list
Elegant compare
class my_class: def __init__(self, attr1, attr2): self.attr1 = attr1 #string self.attr2 = attr2 #string def __lt__(self, other): if self.attr1 < other.attr1: return True else: return self.attr2 < other.attr2 I will run into problems if attr1 or attr2 is None, and they legitimately can be. I know I can check for attr1 or attr2 or both being None and react accordingly, but my real class has ten attributes and that approach will be long. What are my alternatives? -- http://mail.python.org/mailman/listinfo/python-list
Re: Python Basic Doubt
On Sun, Aug 11, 2013 at 4:21 AM, Gary Herron wrote: > On 08/10/2013 06:00 PM, Chris Angelico wrote: >> Wrong. If you do equality comparisons, it's entirely possible for >> something to be passed in that compares equal to the RHS without >> actually being it, so "is" is precisely what's wanted. (Plus, why go >> through a potentially expensive comparison check when you can simply >> check object identity - which could be, for instance, an address >> check? But performance is a distant second to correctness here.) > > You're missing my point. > > Our knee-jerk reaction to beginners using "is" should be: > Don't do that! You almost certainly want "==". Consider "is" an > advanced topic. > > Then you can spend as much time as you want trying to coach them into an > understanding of the precise details. But until they have that > understanding, they are well served by a rule-of-thumb that says: > Use "==" not "is" for comparisons. No, I'm not missing your point; I'm disagreeing with it. I think that 'is' should be taught, that it is every bit as important as '=='; you're walking down the path of "GOTO considered harmful", of decrying some particular language feature because it can be misused. >> All it takes is a slightly odd or buggy __eq__ implementation and the >> == versions will misbehave. To check if an argument is something, you >> use "is", not ==. > > No, sorry, but any use of the word "is" in an English sentence is way too > ambiguous to specify a correct translation into code. To check "if a > calculation of some value is a million", you'd write > value == 100 > not > value is 100 > even though there are plenty of other examples where "is" would be correct. Granted, English is a poor litmus test for code. But in this particular example, we're talking about immutable types (simple integers), where value and identity are practically the same. A Python implementation would be perfectly justified in interning *every* integer, in which case the 'is' would work perfectly here. The distinction between the two is important when the objects are mutable (so they have an identity that's distinct from their current values). ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Elegant compare
On Sun, Aug 11, 2013 at 4:41 AM, Jason Friedman wrote: > class my_class: > def __init__(self, attr1, attr2): > self.attr1 = attr1 #string > self.attr2 = attr2 #string > def __lt__(self, other): > if self.attr1 < other.attr1: > return True > else: > return self.attr2 < other.attr2 > > I will run into problems if attr1 or attr2 is None, and they > legitimately can be. > > I know I can check for attr1 or attr2 or both being None and react > accordingly, but my real class has ten attributes and that approach > will be long. What are my alternatives? The first question is: What should the comparison do with a None value? Should it be considered less than every string? If so, you could simply use: if (self.attr1 or "") < (other.attr1 or ""): which will treat any falsy value as blank. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Python Basic Doubt
On 11 August 2013 04:43, Chris Angelico wrote: > On Sun, Aug 11, 2013 at 4:21 AM, Gary Herron > wrote: >> On 08/10/2013 06:00 PM, Chris Angelico wrote: >>> All it takes is a slightly odd or buggy __eq__ implementation and the >>> == versions will misbehave. To check if an argument is something, you >>> use "is", not ==. >> >> No, sorry, but any use of the word "is" in an English sentence is way too >> ambiguous to specify a correct translation into code. To check "if a >> calculation of some value is a million", you'd write >> value == 100 >> not >> value is 100 >> even though there are plenty of other examples where "is" would be correct. > > Granted, English is a poor litmus test for code. But in this > particular example, we're talking about immutable types (simple > integers), where value and identity are practically the same. A Python > implementation would be perfectly justified in interning *every* > integer, in which case the 'is' would work perfectly here. The > distinction between the two is important when the objects are mutable > (so they have an identity that's distinct from their current values). I don't follow this argument. Tuples are immutable yet you're crazy if you check their equality with "is". In Python identity and equality are very distinct. I follow (and agree) with the other arguments: "is" is useful and should be used. It's just this part in particular sounds off. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python Basic Doubt
On 08/10/2013 08:43 PM, Chris Angelico wrote: On Sun, Aug 11, 2013 at 4:21 AM, Gary Herron wrote: On 08/10/2013 06:00 PM, Chris Angelico wrote: Wrong. If you do equality comparisons, it's entirely possible for something to be passed in that compares equal to the RHS without actually being it, so "is" is precisely what's wanted. (Plus, why go through a potentially expensive comparison check when you can simply check object identity - which could be, for instance, an address check? But performance is a distant second to correctness here.) You're missing my point. Our knee-jerk reaction to beginners using "is" should be: Don't do that! You almost certainly want "==". Consider "is" an advanced topic. Then you can spend as much time as you want trying to coach them into an understanding of the precise details. But until they have that understanding, they are well served by a rule-of-thumb that says: Use "==" not "is" for comparisons. No, I'm not missing your point; I'm disagreeing with it. I think that 'is' should be taught, that it is every bit as important as '=='; you're walking down the path of "GOTO considered harmful", of decrying some particular language feature because it can be misused. // I agree that both "==" and "is" must be taught. But it's the order in which things are introduced which I'm quibbling about. Something like this makes sense (to me): Lesson 1: Use "==" for comparisons, save "is" for a more advanced lesson. Lesson 2: Use "is" for singleton types like "if a is None:" and other easily defined circumstances. Lesson 3: The whole truth, accompanied by a whole chapter's worth of material that describes Python's data model and the difference between value versus identity and assignment versus binding ... A beginner, on his first program or two, can understand 1, and perhaps parrot 2 without understanding (or needing to). But the step from there to 3 is huge. It's folly to dump that on a first-time programmer. (It's probably even folly to dump that on a seasoned programmer just starting in Python. I still remember not understanding the explanation for "is" when I first read it. And it continued to make no sense until I had enough experience to understand the difference betwen C/C++ assignment to variables and Python's binding of variables.) All it takes is a slightly odd or buggy __eq__ implementation and the == versions will misbehave. To check if an argument is something, you use "is", not ==. No, sorry, but any use of the word "is" in an English sentence is way too ambiguous to specify a correct translation into code. To check "if a calculation of some value is a million", you'd write value == 100 not value is 100 even though there are plenty of other examples where "is" would be correct. Granted, English is a poor litmus test for code. But in this particular example, we're talking about immutable types (simple integers), where value and identity are practically the same. A Python implementation would be perfectly justified in interning *every* integer, in which case the 'is' would work perfectly here. The distinction between the two is important when the objects are mutable (so they have an identity that's distinct from their current values). Granted. But please note: There is *nothing* in that sentence which is fit for a beginner programmer. ... "immutable", "value/identity", "interning" ... In one ear and out the other. :-) ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Python Basic Doubt
On Sun, Aug 11, 2013 at 5:04 AM, Joshua Landau wrote: > On 11 August 2013 04:43, Chris Angelico wrote: >> The >> distinction between the two is important when the objects are mutable >> (so they have an identity that's distinct from their current values). > > I don't follow this argument. Tuples are immutable yet you're crazy if > you check their equality with "is". In Python identity and equality > are very distinct. True, it's not strictly an issue of mutability of that one level. But anything that's truly immutable (a tuple/frozenset of ints/strings) can in theory be interned. In some languages (no Pythons as far as I'm aware, though one could easily do so and still be fully compliant), all strings are automatically interned, so there's no difference between value and identity for them. A tuple containing a list, for instance, needs its identity; a tuple of three integers is identifiable entirely by its value. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Python Basic Doubt
On Sun, Aug 11, 2013 at 5:29 AM, Gary Herron wrote: > A beginner, on his first program or two, can understand 1, and perhaps > parrot 2 without understanding (or needing to). But the step from there to > 3 is huge. It's folly to dump that on a first-time programmer. (It's > probably even folly to dump that on a seasoned programmer just starting in > Python. I still remember not understanding the explanation for "is" when I > first read it. And it continued to make no sense until I had enough > experience to understand the difference betwen C/C++ assignment to variables > and Python's binding of variables.) See, that's where the problem is. You will never grok the difference between == and is if you're still thinking about C variables. (Though you *might* be able to explain it by talking solely about char* and the way two C strings can be the same but stored at different places in memory. But that would be unhelpful most of the time.) This is important *early* reading for a new Python programmer: http://mail.python.org/pipermail/tutor/2010-December/080505.html Note that it was originally posted on python-tutor, so it was definitely aimed at the inexperienced. > On 08/10/2013 08:43 PM, Chris Angelico wrote: > Granted, English is a poor litmus test for code. But in this > particular example, we're talking about immutable types (simple > integers), where value and identity are practically the same. A Python > implementation would be perfectly justified in interning *every* > integer, in which case the 'is' would work perfectly here. The > distinction between the two is important when the objects are mutable > (so they have an identity that's distinct from their current values). > > > Granted. But please note: There is *nothing* in that sentence which is fit > for a beginner programmer. ... "immutable", "value/identity", "interning" > ... In one ear and out the other. :-) Right. This isn't my explanation of 'is' and '=='; it's my explanation of why it's important to HAVE an explanation of the aforementioned. :) Though the difference between value and identity is significant and important, and mutability is bound to crop up fairly early on; so really, it's only the concept of interning that would be really advanced. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Paramiko Help. Execute command to Interactive Shell which is opened by SSHClient()
On Thursday, August 8, 2013 12:50:25 PM UTC+5:30, sagar varule wrote: > Hi All, > > > > Im using Paramiko for my SSH automation. Im using method that is shown in > demo_simple.py example which comes with Paramiko. Below is code from > demo_simple.py. > > > > As you can make out, below code opens SSH connection and opens Interactie > Shell, and then wait for the command from user. > > I want to submit the command to this Interactive Shell using code. > > > > try: > > client = paramiko.SSHClient() > > client.load_system_host_keys() > > client.set_missing_host_key_policy(paramiko.WarningPolicy()) > > print '*** Connecting...' > > client.connect(hostname, port, username, password) > > chan = client.invoke_shell() > > print repr(client.get_transport()) > > print '*** Here we go!' > > print > > interactive.interactive_shell(chan) > > chan.close() > > client.close() > > > > Well Another approach I tried is instead of opening interactive_shell, > directly issue command using; > > > > stdin, stdout, stderr = client.exec_command(bv_cmd) > > for line in stderr.readlines(): > > print line > > for line in stdout.readlines(): > > print line > > But problem here is client.exec_command(bv_cmd) waits for command to execute > completely and then it returns to stdout,stderr. And I want to see the ouput > from the command during its execution. Because my command takes long time for > execution. > > > > Big Picture in My Mind: Big Picture I that want to achieve is, Opening > different SSH connection to different host, and it will issue commands to all > host, wait for execution. All execution should happen parallel.(just wanted > to share my thought, and wanted to hear opinions from you all. Is this > possible??). I am not big programmer, just 2 years experience with asp.net C# > 2.0 so i would appreciate if discussion happens in simple english. Can any one comment on this.. -- http://mail.python.org/mailman/listinfo/python-list
Re: Paramiko Help. Execute command to Interactive Shell which is opened by SSHClient()
On 11 August 2013 06:18, sagar varule wrote: > Can any one comment on this.. If you don't get replies here it's probably because no-one knows Paramiko. I suggest posting elsewhere to see if there are any Paramiko users in other places willing to help. There might be a Paramiko mailing list. You also didn't say what didn't work with the first block of code. Also, what is "interactive"? -- http://mail.python.org/mailman/listinfo/python-list
Could you verify this, Oh Great Unicode Experts of the Python-List?
Basically, I think Twitter's broken.
For my full discusion on the matter, see:
http://www.reddit.com/r/learnpython/comments/1k2yrn/help_with_len_and_input_function_33/cbku5e8
Here's the first post of mine, ineffectually edited for this list:
"""
The obvious solution [to getting the length of a tweet]
is wrong. Like, slightly wrong¹.
Given tweet = b"caf\x65\xCC\x81".decode():
>>> tweet
'café'
But:
>>> len(tweet)
5
So the solution is:
>>> import unicodedata
>>> len(unicodedata.normalize("NFC", tweet))
4
Read twitter's commentary¹ for proof.
There are additional complications I'm trying to sort
out.
After further testing (I don't actually use Twitter) it seems the
whole thing was just smoke and mirrors. The linked article is a lie,
at least on the user's end.
On Linux you can prove this by running:
>>> p = subprocess.Popen(['xsel', '-bi'], stdin=subprocess.PIPE)
>>> p.communicate(input=b"caf\x65\xCC\x81")
(None, None)
"café" will be in your Copy-Paste buffer, and you can paste it in to
the tweet-box. It takes 5 characters. So much for testing ;).
¹ https://dev.twitter.com/docs/counting-characters#Definition_of_a_Character
"""
I know this isn't *really* Python-related, but there's Python involved
and you're the sort of people who'll be able to tell me what I've done
wrong, if anything.
--
http://mail.python.org/mailman/listinfo/python-list
