Re: Question about Source Control
"Frank Millman" wrote in message news:lgbe6g$j9o$1...@ger.gmane.org... > > > To recap my basic setup, I have machine A which holds the source > directory, machine B which is used to edit the program, and machines B and > C which are both used to run the program. > > Initially, to prove that I understand the concept, I propose to install > Mercurial on all three machines. Machine A will hold the central > repository, which I will clone onto machines B and C. After editing on B, > I will 'push' to A, and then from C 'pull' from A to get the latest > version. > Ok, I did that, and it worked. I think I may be on the path to enlightenment. One thing still confuses me. Over the lifetime of a project, there could be many thousands of changesets. Some of those could be tagged as 'major releases'. Someone wishing to clone the project from scratch may want to start from the latest major release, and not download every changeset since the project started. How is this handled in practice? Thanks Frank -- https://mail.python.org/mailman/listinfo/python-list
Re: Question about Source Control
On Thu, Mar 20, 2014 at 5:48 PM, Frank Millman wrote: > One thing still confuses me. Over the lifetime of a project, there could be > many thousands of changesets. Some of those could be tagged as 'major > releases'. Someone wishing to clone the project from scratch may want to > start from the latest major release, and not download every changeset since > the project started. > > How is this handled in practice? There are several ways, but the most common is to simply tag a revision along the way; Pike does this, and I do the same in Gypsum. Pike 7.8.700 is commit 1ace5c: http://pike-git.lysator.liu.se/gitweb.cgi?p=pike.git;a=commit;h=1ace5c8e7c5c14fcaeeefd307b1ec99b80560311 Gypsum 1.1.0 is commit d937bf: https://github.com/Rosuav/Gypsum/tree/v1.1.0 You can then offer a non-source-control means of downloading that specific revision. Github does this for me automatically: https://github.com/Rosuav/Gypsum/archive/v1.1.0.zip Pike goes further and publishes binaries for various systems, too, and the source archive isn't quite a pure snapshot of git at that point (it has some intermediate files so as to reduce dependencies), but the effect is the same - if you want to get Pike 7.8.700, you don't need all the changes: http://pike.lysator.liu.se/download/pub/pike/latest-stable/ Python also snapshots like that, but with a much more complicated history than either of the above; the Python download pages offer you source tarballs and compiled binaries. If you want to find version 3.3.1 in source control, just look that up in the .hgtags file, which says that "v3.3.1" is d9893d. (I'm not familiar with hg-web, so I can't provide a link. But it's effectively the same as I showed above.) ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: [Python-Dev] Issues about relative& absolute import way for Portingfrom python2.4 to python2.7
北冰洋 wrote: > I just wrote a sample like this: > testPy/ > __init__.py > client.py > SoamFactory.c > SoamFactory.so > soamapi.py > sample/testP.py > export PYTHONPATH=$(TEST_LOCATION):$(TEST_LOCATION)/testPy > I found that soamapi was imported twice, and I investigated this is > I don't know how to fix it. Is there any official way about how to porting > this scenario or better idea? Without looking into the details -- I believe that your problem stems from having a path into the package: > export PYTHONPATH=$(TEST_LOCATION):$(TEST_LOCATION)/testPy The above means that a module testPy.foo can also successfully be imported as foo. Try changing the path to export PYTHONPATH=$(TEST_LOCATION) If you get failing imports change every failing import import foo to from testPy import foo -- https://mail.python.org/mailman/listinfo/python-list
Re: Problem with pickle and restarting a program
Peace writes:
> ...
> The serial number field always remains empty even though I enter from the GUI
> and the receiveSerialNumber function is called and I explicitly initialize it
> to the variable in the model.
> I'm trying to save the state of the program so that next time I open the
> application it resumes from where it left off. The problem is when I restart
> the application, the serial number is empty. What am I doing wrong here?
> Whenever I get a change in state (the RC value), I pickle and save to a file
> (restoreinfo.p). When I restart the application, the serial number is no
> longer there even though I enter it. Could you please let me know what is
> going wrong? Thank you.
You may want to use debugging to determine what goes on in detail.
There are commercial debuggers with a graphical user interface
(maybe even free ones). Python comes with a simple command line
debugger ("pdb").
--
https://mail.python.org/mailman/listinfo/python-list
Decorator
Hi guys, Is there a difference between accessing decorators via '@' symbol and hard coding that ? esp when the function passed to the decorator is a recursive one? See attachments result from deco_with@ is 1 1 0 1 1 0 1 1 0 result from deco_without@ is 1 1 2 3 5 8 13 21 34 1 1 0 3 5 0 13 21 0 Thanks , muru #--- # Name:module1 # Purpose: # # Author: Ratna # # Created: 20/03/2014 # Copyright: (c) Ratna 2014 # Licence: #--- import math def isOddMy(func): def innerOdd(x): y = func(x) if math.fmod(y, 2) == 0 : return 0 else: if y is not None: return y else: return 0 return innerOdd @isOddMy def fib(n): #print n, if n == 0 : return 0 elif n == 1 : return 1 else: return fib(n-2) + fib(n-1) def main(): #oddFibi = isOdd(fib) #print [i for i in oddFibi(100)] for i in range(1,10): print fib(i), '''print fib1 = isOddMy(fib) for i in range(1,10): print fib1(i),''' if __name__ == '__main__': main() #--- # Name:module1 # Purpose: # # Author: Ratna # # Created: 20/03/2014 # Copyright: (c) Ratna 2014 # Licence: #--- import math def isOddMy(func): def innerOdd(x): y = func(x) if math.fmod(y, 2) == 0 : return 0 else: if y is not None: return y else: return 0 return innerOdd #@isOddMy def fib(n): #print n, if n == 0 : return 0 elif n == 1 : return 1 else: return fib(n-2) + fib(n-1) def main(): #oddFibi = isOdd(fib) #print [i for i in oddFibi(100)] for i in range(1,10): print fib(i), print fib1 = isOddMy(fib) for i in range(1,10): print fib1(i), if __name__ == '__main__': main() -- https://mail.python.org/mailman/listinfo/python-list
Re: Decorator
muru kessan wrote: > Is there a difference between accessing decorators via '@' symbol and > hard coding that ? esp when the function passed to the decorator is a > recursive one? The difference is not the decorator but the recursive function call. Consider Case 1: @deco def f(): ... f() # calls the decorated function ... f() Case 2: def f() ... f() # calls the undecorated function ... g = deco(f) g() The function call f() will invoke whatever the global name f is bound to a the time of invocation. So Case 3: def f() ... f() # calls the decorated function ... f = deco(f) f() In your code change fib1 = isOddMy(fib) to fib = isOddMy(fib) and the without@ version will produce the same output as the with@ version. -- https://mail.python.org/mailman/listinfo/python-list
Re: Decorator
Peter Otten <__pete...@web.de> Wrote in message: > > In your code change > > fib1 = isOddMy(fib) > > to > > fib = isOddMy(fib) > > and the without@ version will produce the same output as the with@ version. > > I expect that one more thing is needed, since the above is inside a function: global fib fib = isOdd (fib) -- DaveA -- https://mail.python.org/mailman/listinfo/python-list
PyDev 3.4.1 Released
What is PyDev? --- PyDev is an open-source Python IDE on top of Eclipse for Python, Jython and IronPython development. It comes with goodies such as code completion, syntax highlighting, syntax analysis, code analysis, refactor, debug, interactive console, etc. Details on PyDev: http://pydev.org Details on its development: http://pydev.blogspot.com What is LiClipse? --- LiClipse is a PyDev standalone with goodies such as support for Multiple cursors, theming and a number of other languages such as Django Templates, Kivy Language, Mako Templates, Html, Javascript, etc. It's also a commercial counterpart which helps supporting the development of PyDev. Details on LiClipse: http://brainwy.github.io/liclipse/ Release Highlights: --- - **Important**: PyDev requires Eclipse 3.8 or 4.3 onwards and Java 7! For older versions, keep using PyDev 2.x (or LiClipse for a PyDev standalone with all requirements bundled). - **Interactive Console**: * **Send a single line to the interactive console with F2** (akin to Ctrl+Alt+Enter but only for the current line). - **Debugger**: * **Added support for debugging spawned subprocesses.** * New Django launches no longer have -noreload to take advantage of that (but existing launches have to be manually edited -- or removed and recreated). * When terminating a process its subprocesses are also killed (avoiding django zombie processes). * In the debugger, locals are now also properly saved on PyPy (requires a newer version of PyPy too). * Remote Debugger: when specifying items in PATHS_FROM_ECLIPSE_TO_PYTHON pathnames are normalized. * Fixes to work with Jython 2.1 and Jython 2.2.1 * Always setting PYTHONUNBUFFERED environment variable to 1. * The python default encoding is no longer changed (only PYTHONIOENCODING is used now and not sys.setdefaultencoding). * Minor improvements on get referrers. - **General**: * **Cython: .pxd and .pxi files are properly supported.** * Interpreter configuration: It's possible to reorder PYTHONPATH entries with drag and drop. * Fixed django interactive shell to work with newer versions of Django. * Rename working properly for files without extensions. * Fixed issue where specifying the type of a variable with a comment was not detected in the code-completion. * Fixed issue where we'd open a file as if it was an external file when it was actually a file in the workspace or inside a source folder. * PyDev Package Explorer: fixed issue where some errors would remain showing when they didn't exist anymore. * PyDev Package Explorer: fixed issue where items could change its order depending on decorations. * On a double-click on spaces, all the spaces are selected. - **Test Runner**: * **Improved py.test integration**: it's now possible to select which tests to run with Ctrl+F9 (even if not under a class). * No longer breaks if a file which was in a launch config is removed (still runs other tests in the launch). * After a test run finishes, if there are non-daemon threads running they're printed to the output. * Fixed UnicodeDecodeError when running unit-tests under python 2.x * Fixed issue on test discovery on Linux. - **Sorting Imports**: * Sort of imports no longer adds spaces at end of imports. * Sort of imports no longer passes the number of available columns specified. * It's now also possible to keep the names of 'from' imports sorted. Cheers, -- Fabio Zadrozny -- Software Developer LiClipse http://brainwy.github.io/liclipse PyDev - Python Development Environment for Eclipse http://pydev.org http://pydev.blogspot.com -- https://mail.python.org/mailman/listinfo/python-list
Re: Decorator
Dave Angel wrote: > Peter Otten <__pete...@web.de> Wrote in message: > >> >> In your code change >> >> fib1 = isOddMy(fib) >> >> to >> >> fib = isOddMy(fib) >> >> and the without@ version will produce the same output as the with@ >> version. >> >> > > I expect that one more thing is needed, since the above is inside > a function: > > global fib > fib = isOdd (fib) Yes, sorry, I missed that. -- https://mail.python.org/mailman/listinfo/python-list
Dictionaries
Hi,
This might sound weird, but is there a limit how many dictionaries a
can create/use in a single script?
My reason for asking is I split a 2-column-csv (phone#, ref#) file into
a dict and am trying to put duplicated phone numbers with different ref
numbers into new dictionaries. The script deducts the duplicated 46
numbers but it only creates batch1.csv. Since I obviously can't see the
wood for the trees here, can someone pls punch me into the right
direction
...(No has_key is fine, its python 2.7)
f = open("file.csv", 'r')
myDict = {}
Batch1 = {}
Batch2 = {}
Batch3 = {}
for line in f:
if line.startswith('Number' ):
print "First line ignored..."
else:
k, v = line.split(',')
myDict[k] = v
f.close()
for k, v in myDict.items():
if Batch1.has_key(k):
if k in Batch2.has_key(k):
Batch3[k] = v
else:
Batch2[k] = v
else:
Batch1[k] = v
for k, v in Batch1.items():
newLine = "%s,%s" % (k, v)
with open("batch1.csv", "a") as f:
f.write(newLine)
for k, v in Batch2.items():
newLine = "%s,%s" % (k, v)
with open("batch2.csv", "a") as f:
f.write(newLine)
for k, v in Batch3.items():
newLine = "%s,%s" % (k, v)
with open("batch3.csv", "a") as f:
f.write(newLine)
--
https://mail.python.org/mailman/listinfo/python-list
Re: Dictionaries
ishish wrote:
> This might sound weird, but is there a limit how many dictionaries a
> can create/use in a single script?
No.
> My reason for asking is I split a 2-column-csv (phone#, ref#) file into
> a dict and am trying to put duplicated phone numbers with different ref
> numbers into new dictionaries. The script deducts the duplicated 46
> numbers but it only creates batch1.csv. Since I obviously can't see the
> wood for the trees here, can someone pls punch me into the right
> direction
> ...(No has_key is fine, its python 2.7)
>
> f = open("file.csv", 'r')
Consider a csv with the lines
Number...
123,first
123,second
456,third
> myDict = {}
> Batch1 = {}
> Batch2 = {}
> Batch3 = {}
>
> for line in f:
> if line.startswith('Number' ):
> print "First line ignored..."
> else:
> k, v = line.split(',')
> myDict[k] = v
the first time around the assignment is
myDict["123"] = "first\n"
the second time it is
myDict["123"] = "second\n"
i. e. you are overwriting the previous value and only keep the value
corresponding to the last occurrence of a key.
A good approach to solve the problem of keeping an arbitrary number of
values per key is to make the dict value a list:
myDict = {}
with open("data.csv") as f:
next(f) # skip first line
for line in f:
k, v = line.split(",")
myDict.setdefault(k, []).append(v)
This will produce a myDict
{
"123": ["first\n", "second\n"],
"456": ["third\n"]
}
You can then proceed to find out the number of batches:
num_batches = max(len(v) for v in myDict.values())
Now write the files:
for index in range(num_batches):
with open("batch%s.csv" % (index+1), "w") as f:
for key, values in myDict.items():
if len(values) > index: # there are more than index duplicates
f.write("%s,%s" % (key, values[index]))
--
https://mail.python.org/mailman/listinfo/python-list
Re: Dictionaries
In ishish writes: > The script [...] only creates batch1.csv. If the script only creates batch1.csv, that means Batch2 and Batch3 must be empty. > for k, v in myDict.items(): > if Batch1.has_key(k): > if k in Batch2.has_key(k): > Batch3[k] = v > else: > Batch2[k] = v > else: > Batch1[k] = v 'if k in Batch2.has_key(k):' is a very strange line of code. In fact, it should produce a syntax error if it were ever executed, because the 'in' keyword requires an iterable as the second part, and has_key() returns only True or False. Therefore, I would say that line of code never executes, which means that the preceding 'if Batch1.has_key(k)' statement always evaluates to False. Which therefore means that Batch2 and Batch3 never accumulate any items, matching your observed output. -- John Gordon Imagine what it must be like for a real medical doctor to gor...@panix.comwatch 'House', or a real serial killer to watch 'Dexter'. -- https://mail.python.org/mailman/listinfo/python-list
Re:Dictionaries
Please don't leave new questions in an existing thread, and
especially without changing subject line. Compose a new message
with meaningful subject line.
ishish Wrote in message:
> Hi,
>
> This might sound weird, but is there a limit how many dictionaries a
> can create/use in a single script?
No, unless you run out of RAM.
>
> My reason for asking is I split a 2-column-csv (phone#, ref#) file into
> a dict and am trying to put duplicated phone numbers with different ref
> numbers into new dictionaries. The script deducts the duplicated 46
> numbers but it only creates batch1.csv. Since I obviously can't see the
> wood for the trees here, can someone pls punch me into the right
> direction
> ...(No has_key is fine, its python 2.7)
But has_key is deprecated, and you're using it wrong anyway.
>
> f = open("file.csv", 'r')
>
> myDict = {}
> Batch1 = {}
> Batch2 = {}
> Batch3 = {}
>
> for line in f:
> if line.startswith('Number' ):
> print "First line ignored..."
> else:
> k, v = line.split(',')
> myDict[k] = v
> f.close()
>
> for k, v in myDict.items():
> if Batch1.has_key(k):
> if k in Batch2.has_key(k):
I'm surprised this doesn't throw an exception. has_key returns a
bool, and in isn't meaningful on a bool. Just use
if k in Batch2:
> Batch3[k] = v
> else:
> Batch2[k] = v
> else:
> Batch1[k] = v
>
> for k, v in Batch1.items():
> newLine = "%s,%s" % (k, v)
> with open("batch1.csv", "a") as f:
This is unusual, and a performance killer, to repeatedly open
the file. But you may have some reason.
> f.write(newLine)
There's no newline there, so your csv is going to be one long
line. You probably want newLine+'\n' inside those
parens.
>
> for k, v in Batch2.items():
> newLine = "%s,%s" % (k, v)
> with open("batch2.csv", "a") as f:
> f.write(newLine)
>
> for k, v in Batch3.items():
> newLine = "%s,%s" % (k, v)
> with open("batch3.csv", "a") as f:
> f.write(newLine)
>
--
DaveA
--
https://mail.python.org/mailman/listinfo/python-list
Re: Dictionaries
Thanks Peter for the fast response, but the prob is solved. My colleague just verbally slapped me because a dict SHOULDN'T have duplicate keys... I change it around to duplicate values and it works fine I think I need coffee now... lots of it. -- https://mail.python.org/mailman/listinfo/python-list
running python 2 vs 3
Dumb noob questions: I've installed python 3.3 on my Slack box, which by default comes with python 2.7. I know how to fire up the different IDLE environments, but how do I differentiate between the scripts? IOW, up till now, I've used .py on all my 2.7 files. How do I know not to run a .py in python3 or visa versa? Or do I? What's the excepted convention for differentiating between the two? nb -- https://mail.python.org/mailman/listinfo/python-list
Re: running python 2 vs 3
notbob : > I've installed python 3.3 on my Slack box, which by default comes with > python 2.7. I know how to fire up the different IDLE environments, but > how do I differentiate between the scripts? IOW, up till now, I've > used .py on all my 2.7 files. How do I know not to run a .py in > python3 or visa versa? Or do I? What's the excepted convention for > differentiating between the two? That's a bit of a sore spot. On a linux box, the initial line of the script indicates the interpreter: #!/usr/bin/env python2 for Python 2.x #!/usr/bin/env python3 for Python 3.x. All tutorials will tell you to start it with #!/usr/bin/env python which will start python2 on all (?) existing linux distros, but is expected to start python3 within the next decade. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: running python 2 vs 3
On 2014-03-20, Marko Rauhamaa wrote: > That's a bit of a sore spot. > > On a linux box, the initial line of the script indicates the > interpreter: > >#!/usr/bin/env python2 > > for Python 2.x > >#!/usr/bin/env python3 > > for Python 3.x. > > All tutorials will tell you to start it with > >#!/usr/bin/env python > > which will start python2 on all (?) existing linux distros, but is > expected to start python3 within the next decade. Ahhh! now a shabang I understand. So, I guess the only way, short of looking at the actual file, is to include the version in the filename. Can I safely assume I can run all 2.7 files w/o a shebang (which I have not, so far, and was wondering how I got away with that) and only include a py3 shebang in the py3 files, yes/no? nb -- https://mail.python.org/mailman/listinfo/python-list
Re: running python 2 vs 3
On 3/20/14 9:58 AM, notbob wrote: I've installed python 3.3 on my Slack box, which by default comes with python 2.7. I know how to fire up the different IDLE environments, but how do I differentiate between the scripts? hi notbob, the two (or more) IDLE environments run very nicely side-by-side. If you access your scripts from the same directory (I do not) there really is no problem. The reason is that the .pyc files created for python2.x are only used by python2. The .pyc files for python3.x are kept (by a naming convention) in __pycache__ , so there really is no problem. Having said that, the only problem is that your script for python3 might not run in python2 (for various reasons) but the problem is not that the scripts are contained in the same folder. I keep my python2 scripts in one folder ~/Documents/Python2/ and my python3 scripts in another one ~/Documents/Python3/ I add the two folders in the python paths browser (using site-packages) so that when I start IDLE for python2 it pulls its scripts from ~/Documents/Python2/ and when I start IDLE for python3 it pulls its scripts from ~/Documents/Python3/ There are *many* ways to organize this. Often I have to maintain two scripts (packages) one for each version. Although, I try to make my scripts run in both environments. Often I have IDLE(2) ane IDLE(3) running and testing at the same time on the same box. This works very well. marcus -- https://mail.python.org/mailman/listinfo/python-list
Re: running python 2 vs 3
On Thu, Mar 20, 2014 at 11:00 AM, notbob wrote: > Ahhh! now a shabang I understand. So, I guess the only way, short > of looking at the actual file, is to include the version in the > filename. Can I safely assume I can run all 2.7 files w/o a shebang > (which I have not, so far, and was wondering how I got away with that) > and only include a py3 shebang in the py3 files, yes/no? If I understand your question: you're probably better off putting a shebang line in all of the files that you intend to run directly. Use "/usr/bin/env python2" for your Python 2 scripts, "/usr/bin/env python3" for your Python 3 scripts, and "/usr/bin/env python" for scripts that can run under either interpreter. You can also be more version-specific if you need to; use "python2.7", "python3.3", etc. as necessary. That way, you can invoke the script directly and the right interpreter will run it. If you're specifying the interpreter in your command (by calling "python .py", etc), the shebang won't mean anything anyway. -- Zach -- https://mail.python.org/mailman/listinfo/python-list
Re: running python 2 vs 3
On 2014-03-20, Zachary Ware wrote: > If you're specifying the interpreter in your command (by calling > "python .py", etc), the shebang won't mean anything > anyway. DOH! I was following you, fine, until that last sentence. Then how should I invoke the scripts? as your example is exactly how I've been doing it with 2.7, as per Learn Python the Hard Way. Simply ./.py from the appropriate directory (assuming I keep both vers in separate dirs)? nb -- https://mail.python.org/mailman/listinfo/python-list
Re: running python 2 vs 3
On 2014-03-20, Mark H Harris wrote: > not) there really is no problem. The reason is that the .pyc files > created for python2.x are only used by python2. Lordy, what hath I wrought!? ;) What the heck is a .pyc file and how are they created? Actually, I can see it's a compiled binary, but I where did it come from? I went back to my ~/python/ dir and noticed one .pyc file out of 15 .py files I created from following Learning Python the Hard Way. No one said anything about creating a binary. I know I discovered how to create/edit python scripts from IDLE. Is that it? I've been using gedit and emacs up till now. Seems the file with the .pyc file is the one I edited in IDLE. Is that why LPtHW eschews IDLE for gedit? Why do I feel like I've really stepped in it? ;) nb -- https://mail.python.org/mailman/listinfo/python-list
Re: running python 2 vs 3
On Fri, Mar 21, 2014 at 4:23 AM, notbob wrote: > On 2014-03-20, Mark H Harris wrote: > >> not) there really is no problem. The reason is that the .pyc files >> created for python2.x are only used by python2. > > Lordy, what hath I wrought!? ;) > > What the heck is a .pyc file and how are they created? Actually, I > can see it's a compiled binary, but I where did it come from? > > I went back to my ~/python/ dir and noticed one .pyc file out of 15 > .py files I created from following Learning Python the Hard Way. No > one said anything about creating a binary. I know I discovered how to > create/edit python scripts from IDLE. Is that it? I've been using > gedit and emacs up till now. Seems the file with the .pyc file is the > one I edited in IDLE. Is that why LPtHW eschews IDLE for gedit? > > Why do I feel like I've really stepped in it? ;) > You should be able to completely ignore .pyc files, most of the time. The only thing to remember is that you should delete them any time you delete the corresponding .py files. They're a cached version that Python will use to speed up imports, nothing more. Nowadays they'll be pushed away into a separate directory, which makes them easier for you to ignore. This is a good thing. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: running python 2 vs 3
On Fri, Mar 21, 2014 at 4:10 AM, notbob wrote: > On 2014-03-20, Zachary Ware wrote: > >> If you're specifying the interpreter in your command (by calling >> "python .py", etc), the shebang won't mean anything >> anyway. > > DOH! > > I was following you, fine, until that last sentence. Then how should > I invoke the scripts? as your example is exactly how I've been > doing it with 2.7, as per Learn Python the Hard Way. Simply > ./.py from the appropriate directory (assuming I keep both > vers in separate dirs)? That's a fine way to do it. Zachary is mentioning an alternative, and showing that the shebang doesn't hurt (it's a comment to Python), so go ahead and put the shebang in all your scripts. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: running python 2 vs 3
On 3/20/14 12:23 PM, notbob wrote: What the heck is a .pyc file and how are they created? Actually, I can see it's a compiled binary, but I where did it come from? The world according to me: python is an interpreter (vs compiler) which converts your source code into tokens and then into a bytecode. The process takes time. So, the solution is to place the tokenized stuff into a .pyc file so that the process does not have to be repeated unless, of course, the source has changed since the last .pyc file create. It used to be that the .pyc files went into the same dir as the source (that's how it works for python2) but now with python3 they go into a directory in your source tree called __pycache__, and they are named based on python version (a way better scheme for sure). If you wanted to you could run your python scripts from the .pyc file alone. In other words, you may import as long as the .pyc file exists and the source does not need to be there. Some folks use this (not recommended) trick to hide or obfuscate their source from their users). marcus -- https://mail.python.org/mailman/listinfo/python-list
Re: running python 2 vs 3
Chris Angelico : > Nowadays they'll be pushed away into a separate directory, which makes > them easier for you to ignore. This is a good thing. Still, I don't think Python should go and soil my directories without an explicit permission. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: running python 2 vs 3
Mark H Harris : > If you wanted to you could run your python scripts from the .pyc file > alone. In other words, you may import as long as the .pyc file exists > and the source does not need to be there. Some folks use this (not > recommended) trick to hide or obfuscate their source from their > users). I've seen it done, but at least in those Python 2 days the pyc format changed between minor releases of Python, so Python itself had to be shipped with the pyc files. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: running python 2 vs 3
On 03/20/2014 10:10 AM, notbob wrote: On 2014-03-20, Zachary Ware wrote: If you're specifying the interpreter in your command (by calling "python .py", etc), the shebang won't mean anything anyway. DOH! I was following you, fine, until that last sentence. Then how should I invoke the scripts? as your example is exactly how I've been doing it with 2.7, as per Learn Python the Hard Way. Simply ./.py from the appropriate directory (assuming I keep both vers in separate dirs)? nb If you mark your script as executable (chmod ...) and include the shebang line, and place it in a directory included in your search path (mine is ~/bin), then you run it as you run any installed program: Just type it's name followed by any command line args. I usually remove the .py portion of the name as I copy it into my bin directory so it really does look like any other installed program. If you need to be in a specific directory when you run it, then perhaps you should consider a bit of a rewrite to remove this constraint. Gary Herron -- https://mail.python.org/mailman/listinfo/python-list
Installing ssdeep on Portable Python
Portable Python 2.7 for Windows, the Python application have dependency on ssdeep-2.10, which is a binary exe. The ssdeep (libfuzzy) installation example was shown for Linux platform only: a) libfuzzy can be installed via apt-get: $ sudo apt-get install libfuzzy2 b) to install libfuzzy from source, download the gzipped tarball from http://ssdeep.sourceforge.net/#download, then run: $ tar -zxvf ssdeep-2.10.tar.gz $ cd ssdeep-2.10 && ./configure && make && sudo make install - I need install it on PortablePython for Windows, so it's not clear how to make this: where should be placed ssdeep Windows binary files, that Python application can found it? -- https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
Re: Problem with pickle and restarting a program
On Thursday, March 20, 2014 1:20:03 AM UTC-7, dieter wrote:
> Peace <> writes:
>
> > ...
>
> > The serial number field always remains empty even though I enter from the
> > GUI and the receiveSerialNumber function is called and I explicitly
> > initialize it to the variable in the model.
>
> > I'm trying to save the state of the program so that next time I open the
> > application it resumes from where it left off. The problem is when I
> > restart the application, the serial number is empty. What am I doing wrong
> > here? Whenever I get a change in state (the RC value), I pickle and save to
> > a file (restoreinfo.p). When I restart the application, the serial number
> > is no longer there even though I enter it. Could you please let me know
> > what is going wrong? Thank you.
>
>
>
> You may want to use debugging to determine what goes on in detail.
>
>
>
> There are commercial debuggers with a graphical user interface
>
> (maybe even free ones). Python comes with a simple command line
>
> debugger ("pdb").
I tried doing that. I still could not figure out what was wrong. Thank you.
--
https://mail.python.org/mailman/listinfo/python-list
Re: running python 2 vs 3
On 3/20/14 1:47 PM, Marko Rauhamaa wrote: Mark H Harris : If you wanted to you could run your python scripts from the .pyc file alone. In other words, you may import as long as the .pyc file exists and the source does not need to be there. Some folks use this (not recommended) trick to hide or obfuscate their source from their users). I've seen it done, but at least in those Python 2 days the pyc format changed between minor releases of Python, so Python itself had to be shipped with the pyc files. Python3 still makes no guarantees about the compatibility of bytecode (and therefore .pyc files) across versions of Python, so if you want to run from pure .pyc files, you have to be sure to use the same version of Python that produced the files. --Ned. Marko -- Ned Batchelder, http://nedbatchelder.com -- https://mail.python.org/mailman/listinfo/python-list
Re: running python 2 vs 3
On 20/03/2014 15:21, Marko Rauhamaa wrote: notbob : I've installed python 3.3 on my Slack box, which by default comes with python 2.7. I know how to fire up the different IDLE environments, but how do I differentiate between the scripts? IOW, up till now, I've used .py on all my 2.7 files. How do I know not to run a .py in python3 or visa versa? Or do I? What's the excepted convention for differentiating between the two? That's a bit of a sore spot. On a linux box, the initial line of the script indicates the interpreter: #!/usr/bin/env python2 for Python 2.x #!/usr/bin/env python3 for Python 3.x. All tutorials will tell you to start it with #!/usr/bin/env python which will start python2 on all (?) existing linux distros, but is expected to start python3 within the next decade. Marko The above is also true on windows via the 'Python launcher for windows' see http://legacy.python.org/dev/peps/pep-0397/ -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com -- https://mail.python.org/mailman/listinfo/python-list
Re: running python 2 vs 3
In notbob writes: > On 2014-03-20, Zachary Ware wrote: > > If you're specifying the interpreter in your command (by calling > > "python .py", etc), the shebang won't mean anything > > anyway. > DOH! > I was following you, fine, until that last sentence. Then how should > I invoke the scripts? as your example is exactly how I've been > doing it with 2.7, as per Learn Python the Hard Way. Simply > ./.py from the appropriate directory (assuming I keep both > vers in separate dirs)? There are two ways (at least!) to run a python script: 1. Execute the python interpreter manually, supplying the python script name as an arugment, like so: python myscript.py python2 otherscript.py python3 yetanotherscript.py This lets you choose on-the-fly which version of python is being used to interpret the script. 2. Execute the python script directly by just typing its name, like so: myscript.py ./otherscript.py /other/directory/yetanotherscript.py Depending on your operating system, this may require: a. Permissions on the script file be set to allow execution; b. A 'shebang' entry as the first line in the file which specifies the program that shall be executed; -- John Gordon Imagine what it must be like for a real medical doctor to gor...@panix.comwatch 'House', or a real serial killer to watch 'Dexter'. -- https://mail.python.org/mailman/listinfo/python-list
Re: running python 2 vs 3
Le 20/03/2014 16:21, Marko Rauhamaa a écrit : > All tutorials will tell you to start it with > >#!/usr/bin/env python > > which will start python2 on all (?) existing linux distros, but is > expected to start python3 within the next decade. With Arch-Linux, python is python3... -- https://mail.python.org/mailman/listinfo/python-list
Re: running python 2 vs 3
On 3/20/14 12:47 PM, Marko Rauhamaa wrote: I've seen it done, but at least in those Python 2 days the pyc format changed between minor releases of Python, so Python itself had to be shipped with the pyc files. hi Marko, yeah, I have not done this; being that the concept is contrary to my principles and sensibilities these days. So, 1) no intellectual property 2) no software idea patents 3) no obfuscated code 4) ship the source, or don't ship anything/ In my view coding (and all other aspects of computer science including software engineering) is a liberal art; it should be open, free (libre), and available to everyone. People learn best by doing, and the do best by reading what others have done before them. marcus -- https://mail.python.org/mailman/listinfo/python-list
Re: running python 2 vs 3
On 3/20/2014 11:21 AM, Marko Rauhamaa wrote: On a linux box, the initial line of the script indicates the interpreter: #!/usr/bin/env python2 for Python 2.x #!/usr/bin/env python3 for Python 3.x. All tutorials will tell you to start it with #!/usr/bin/env python which will start python2 on all (?) existing linux distros, but is expected to start python3 within the next decade. Marko I presume it would still be a good idea to test both python interpreters against any script that you didn't knowingly write with a feature that will only work in one of the two python versions. If it works fine in both - and many will, then use: #!/usr/bin/env python Only use the "python2" or "python3" versions if you really have a reason to do so. Yes? No? Alan -- https://mail.python.org/mailman/listinfo/python-list
File Path/Global name issue
I am currently running code for a program called HotNet
(https://github.com/raphael-group/hotnet)
In its simpleRun.py file, there is a place to insert a file path to be run.
parser.add_argument('-mf', '--infmat_file', required=True,
help='Path to .mat file containing influence matrix')
My path file is /home/lai/Downloads/influence_matrix_files/hprd_inf_.mat
And I have tried to add it in as such:
Input:
parser.add_argument('-mf', '--infmat_file', required=True,
help=
/home/lai/Downloads/influence_matrix_file/hprd_inf_.mat)
Output:
File "simpleRun.py", line 29
help= ~/home/lai/Downloads/influence_matrix_files/hprd_inf_.mat)
^
SyntaxError: invalid syntax
I have also tried to place the path in ' ' but that isn't processed.
I have tried removing the / however that just returns the following error:
NameError: global name 'home' is not defined
Completely new at this, so thank you for bearing with me and for the help!
--
https://mail.python.org/mailman/listinfo/python-list
Re: File Path/Global name issue
On Thu, Mar 20, 2014 at 2:55 PM, wrote: > File "simpleRun.py", line 29 > help= ~/home/lai/Downloads/influence_matrix_files/hprd_inf_.mat) >^ > SyntaxError: invalid syntax You need quotes around the filename. It's a string literal. Skip -- https://mail.python.org/mailman/listinfo/python-list
Re: File Path/Global name issue
Hi Skip! Thank you so much for the response. When I put quotes around the file name I receive this output. simpleRun.py: error: argument -mf/--infmat_file is required -- https://mail.python.org/mailman/listinfo/python-list
Re: running python 2 vs 3
Alan Meyer : > I presume it would still be a good idea to test both python > interpreters against any script that you didn't knowingly write with a > feature that will only work in one of the two python versions. > > If it works fine in both - and many will, then use: > > #!/usr/bin/env python > > Only use the "python2" or "python3" versions if you really have a > reason to do so. > > Yes? No? No. Even if you managed to do that, it would mean getting the worst of both worlds. The language dialects are too far apart. When you start your Python project, you decide between Python 2 and Python 3 and go all in. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: running python 2 vs 3
On 3/20/14 2:53 PM, Alan Meyer wrote: #!/usr/bin/env python Only use the "python2" or "python3" versions if you really have a reason to do so. It gets tricky for distribution (you need docs for your distros, imho) because #!/usr/bin/env python means different things on different systems. I actually have three major versions of python2 and 2 major versions of python3 on my primary system at this point. On my machine python2.6 is "python". That is because that system shipped with 2.6 and many of the subsystem stuff depends on python2.6 / When I call python2 that means python2.7.6 / When I call python3 that means python3.3.4 / I can also call python2.7, which is 2.7.2 / You get the idea. There is no one set rule, because there are many distros (gnu/linux) that use python at various versions, and they all us different setups. Really , you need an install script to snoop out the configurables. marcus -- https://mail.python.org/mailman/listinfo/python-list
Re: File Path/Global name issue
On Thu, Mar 20, 2014 at 3:08 PM, wrote: > simpleRun.py: error: argument -mf/--infmat_file is required I think you are misinterpreting the actual purpose of the parser_add_argument() call. It's telling you that *on the command line* you can specify it using either -mf some-file-name or --infmat_file=some-file-name It also tells you that it is a required argument. I don't believe you are supposed to have to modify the source to run the program. I'd set the argument to the "help=..." parameter back to however it was set when you got it and try either of the above command line args. Skip -- https://mail.python.org/mailman/listinfo/python-list
Re: running python 2 vs 3
On 20/03/2014 20:08, Marko Rauhamaa wrote: Alan Meyer : I presume it would still be a good idea to test both python interpreters against any script that you didn't knowingly write with a feature that will only work in one of the two python versions. If it works fine in both - and many will, then use: #!/usr/bin/env python Only use the "python2" or "python3" versions if you really have a reason to do so. Yes? No? No. Even if you managed to do that, it would mean getting the worst of both worlds. The language dialects are too far apart. When you start your Python project, you decide between Python 2 and Python 3 and go all in. Marko I do not agree that the dialects are too far apart, not that it really matters. There are several libraries available to enable code to run under both versions. The starter is 2to3 which had been in the standard library for what seems like an eternity to me. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com -- https://mail.python.org/mailman/listinfo/python-list
Re: File Path/Global name issue
roy.snuff...@gmail.com wrote:
> I am currently running code for a program called HotNet
> (https://github.com/raphael-group/hotnet)
>
> In its simpleRun.py file, there is a place to insert a file path to be
> run.
>
> parser.add_argument('-mf', '--infmat_file', required=True,
> help='Path to .mat file containing influence
> matrix')
>
> My path file is /home/lai/Downloads/influence_matrix_files/hprd_inf_.mat
>
> And I have tried to add it in as such:
>
> Input:
>
> parser.add_argument('-mf', '--infmat_file', required=True,
>help=
>/home/lai/Downloads/influence_matrix_file/hprd_inf_.mat)
>
> Output:
>
> File "simpleRun.py", line 29
> help= ~/home/lai/Downloads/influence_matrix_files/hprd_inf_.mat)
>^
> SyntaxError: invalid syntax
>
> I have also tried to place the path in ' ' but that isn't processed.
>
> I have tried removing the / however that just returns the following error:
>
> NameError: global name 'home' is not defined
>
>
> Completely new at this, so thank you for bearing with me and for the help!
Reread the documentation, you are misunderstanding it. You don't have to
modify the simpleRun.py script, you should invoke it from the commandline
with the file as one of its arguments:
$ python simpleRun.py --infmat_file
/home/lai/Downloads/influence_matrix_files/hprd_inf_.mat
As there are more required arguments you will end up with a very long
command line. But there is an alternative. Create a config file like the
following
https://github.com/raphael-group/hotnet/blob/master/example/configs/simple.config
where you replace all the file names with those of your actual files and
then invoke simpleRun.py with
$ python simpleRun.py @roy_snuffles.config
--
https://mail.python.org/mailman/listinfo/python-list
Re: running python 2 vs 3
On 3/20/14 3:07 PM, Eric Jacoboni wrote: Le 20/03/2014 16:21, Marko Rauhamaa a écrit : All tutorials will tell you to start it with #!/usr/bin/env python which will start python2 on all (?) existing linux distros, but is expected to start python3 within the next decade. With Arch-Linux, python is python3... Yes, and they have been told many times that this was foolish and wrong, but it persists, much to our pain. -- Ned Batchelder, http://nedbatchelder.com -- https://mail.python.org/mailman/listinfo/python-list
Re: running python 2 vs 3
On 3/20/14 4:08 PM, Marko Rauhamaa wrote: Alan Meyer : I presume it would still be a good idea to test both python interpreters against any script that you didn't knowingly write with a feature that will only work in one of the two python versions. If it works fine in both - and many will, then use: #!/usr/bin/env python Only use the "python2" or "python3" versions if you really have a reason to do so. Yes? No? No. Even if you managed to do that, it would mean getting the worst of both worlds. The language dialects are too far apart. When you start your Python project, you decide between Python 2 and Python 3 and go all in. Plenty of people have adopted a dual-support strategy, with one code base that supports both Python 2 and Python 3. The six module can help a great deal with this. Marko -- Ned Batchelder, http://nedbatchelder.com -- https://mail.python.org/mailman/listinfo/python-list
Re: running python 2 vs 3
Mark Lawrence : > The starter is 2to3 which had been in the standard library for what > seems like an eternity to me. No problem there. It helps you transition from python2 to python3. However, python3 is here and you should be able to write genuine python3 code with the appropriate bytes and string facilities. It would be very confusing to try to mix the two regimes. I must say, though, that Python3 destroyed "print" forever for me. To avoid nausea, I write sys.stdout.write() in all Python3 code. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: running python 2 vs 3
On Thu, Mar 20, 2014 at 8:21 AM, Marko Rauhamaa wrote: > notbob : > >> I've installed python 3.3 on my Slack box, which by default comes with >> python 2.7. I know how to fire up the different IDLE environments, but >> how do I differentiate between the scripts? IOW, up till now, I've >> used .py on all my 2.7 files. How do I know not to run a .py in >> python3 or visa versa? Or do I? What's the excepted convention for >> differentiating between the two? > > That's a bit of a sore spot. > > On a linux box, the initial line of the script indicates the > interpreter: > >#!/usr/bin/env python2 > > for Python 2.x > >#!/usr/bin/env python3 > > for Python 3.x. > > All tutorials will tell you to start it with > >#!/usr/bin/env python Actually, I formerly used /usr/bin/env, but have recently (within the last couple of years) stopped. This is because the env trick doesn't play nicely with top IME. Also, it's a trick. -- https://mail.python.org/mailman/listinfo/python-list
Re: running python 2 vs 3
On Thu, Mar 20, 2014 at 3:30 PM, Marko Rauhamaa wrote: > I must say, though, that Python3 destroyed "print" forever for me. To > avoid nausea, I write sys.stdout.write() in all Python3 code. To each their own :). I can't stand using 'print' as a statement. It's a very nice trick to be able to write a script, think "oh, all those prints should really be sending that output somewhere else", and then instead of changing every individual print, just define a different 'print' function at the top of the file (which may be as simple as `print = functools.partial(print, file=sys.stderr)` or `print = logging.debug`). -- Zach -- https://mail.python.org/mailman/listinfo/python-list
Re: running python 2 vs 3
Ned Batchelder : > Plenty of people have adopted a dual-support strategy, with one code > base that supports both Python 2 and Python 3. The six module can help > a great deal with this. I wonder how easy the resulting code is to the eyes and how easy it is for the casual maintainer to accidentally break the delicate balance. In a word, I wouldn't go there. Stay with Python2 as long as you must and then, migrate and leave it behind. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: running python 2 vs 3
On 20/03/2014 20:30, Marko Rauhamaa wrote: Mark Lawrence : The starter is 2to3 which had been in the standard library for what seems like an eternity to me. No problem there. It helps you transition from python2 to python3. However, python3 is here and you should be able to write genuine python3 code with the appropriate bytes and string facilities. It would be very confusing to try to mix the two regimes. I must say, though, that Python3 destroyed "print" forever for me. To avoid nausea, I write sys.stdout.write() in all Python3 code. Not for me, I was using from __future__ import print_function for years so got used to typing those two extra brackets, plus print very kindly inserts the newlines for me. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com -- https://mail.python.org/mailman/listinfo/python-list
Re: running python 2 vs 3
Dan Stromberg : > Actually, I formerly used /usr/bin/env, but have recently (within the > last couple of years) stopped. > > This is because the env trick doesn't play nicely with top IME. Also, > it's a trick. I'm not sure I like it either, but it's a standard idiom in Pythonland. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: running python 2 vs 3
On 3/20/14 4:42 PM, Marko Rauhamaa wrote: Ned Batchelder : Plenty of people have adopted a dual-support strategy, with one code base that supports both Python 2 and Python 3. The six module can help a great deal with this. I wonder how easy the resulting code is to the eyes and how easy it is for the casual maintainer to accidentally break the delicate balance. In a word, I wouldn't go there. Stay with Python2 as long as you must and then, migrate and leave it behind. This is fine advice for applications, but tools, libraries, and frameworks may want to support more than one version at the same time. It's an extreme case, but the latest released version of coverage.py supports Python 2.3 through 3.3 with one code base. To do it, there's a compatibility layer (akin to six). Then you stay away from features that aren't available on all versions. In a few places, you might need to have version checks, and the code can get a little idiomatic to continue to work. It's a tradeoff: you have to decide for yourself whether the effort is worth the benefit. I was glad to be able to drop support for 2.3, 2.4, and 2.5, and now only support 2.6-3.4 in coverage.py. Marko -- Ned Batchelder, http://nedbatchelder.com -- https://mail.python.org/mailman/listinfo/python-list
Re: running python 2 vs 3
Mark Lawrence : > On 20/03/2014 20:30, Marko Rauhamaa wrote: >> I must say, though, that Python3 destroyed "print" forever for me. To >> avoid nausea, I write sys.stdout.write() in all Python3 code. > > Not for me, I was using from __future__ import print_function for > years so got used to typing those two extra brackets, plus print very > kindly inserts the newlines for me. That very realization helped me wean myself from "print." Its sole raison d'être is the insertion of the newline, which it would be nicer to micromanage anyway; that's how it's done in other programming languages as well: C, perl, guile, ... (Well, ok, "echo" is the exception.) Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: running python 2 vs 3
Ned Batchelder : > It's an extreme case, but the latest released version of coverage.py > supports Python 2.3 through 3.3 with one code base. To do it, there's > a compatibility layer (akin to six). Then you stay away from features > that aren't available on all versions. In a few places, you might need > to have version checks, and the code can get a little idiomatic to > continue to work. Well, with proper care, I suppose the same code base could support perl as well. ;) Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: running python 2 vs 3
On Thu, Mar 20, 2014 at 1:59 PM, Marko Rauhamaa wrote: > Well, with proper care, I suppose the same code base could support perl > as well. ;) > Go even farther; how about C, PHP, and bash? I'm sure if you tried, you could mix in some Python as well. http://en.wikipedia.org/wiki/Polyglot_(computing) Chris -- https://mail.python.org/mailman/listinfo/python-list
Re: running python 2 vs 3
On 2014-03-20, Mark H Harris wrote: > When I call python2 that means python2.7.6 / > > When I call python3 that means python3.3.4 / > > I can also call python2.7, which is 2.7.2 / > > You get the idea. There is no one set rule, because there are many > distros (gnu/linux) that use python at various versions, and they all us > different setups. Really , you need an install script to snoop out the > configurables. Weeping Chryst on the cross!!. No wonder the latest O'Reilly book, Learning Python, 5th ed, is 1600 pgs. I coulda swore someone sed python is easy. ;) nb -- https://mail.python.org/mailman/listinfo/python-list
Re: running python 2 vs 3
On 3/20/14 4:59 PM, Marko Rauhamaa wrote: Ned Batchelder : It's an extreme case, but the latest released version of coverage.py supports Python 2.3 through 3.3 with one code base. To do it, there's a compatibility layer (akin to six). Then you stay away from features that aren't available on all versions. In a few places, you might need to have version checks, and the code can get a little idiomatic to continue to work. Well, with proper care, I suppose the same code base could support perl as well. ;) I'm not sure how to take this comment. I feel like you are mocking my choice. I wanted to make coverage.py available to as broad an audience as possible, something that I think is worthwhile. Yes, there was an engineering cost, but the tradeoff was worth it. Marko -- Ned Batchelder, http://nedbatchelder.com -- https://mail.python.org/mailman/listinfo/python-list
Re: running python 2 vs 3
On 2014-03-20, Ned Batchelder wrote: > On 3/20/14 3:07 PM, Eric Jacoboni wrote: >> With Arch-Linux, python is python3... >> > Yes, and they have been told many times that this was foolish and wrong, > but it persists, much to our pain. I've read that 2.7 is the defacto std for python (default on Slack 14.1). I installed py3 on Slack box cuz I'd gotten the little "Programming the Raspberry Pi" book, which is a pretty good lil' book, clarifying many confusing (to me) python issues. Only prob is, it's fer python 3x. I guess I coulda kept the two platforms separate, but then raspi has 2X and 3x, also, so I guess I need to get this issue straight in my feeble geezer head, right outta the gate. I'm plum grateful to all you kind folks who are taking the time to educate this slow ol' curmudgeon. ;) nb -- https://mail.python.org/mailman/listinfo/python-list
Re: File Path/Global name issue
In <2089d20b-aa60-462f-aad0-51109849c...@googlegroups.com>
roy.snuff...@gmail.com writes:
> I am currently running code for a program called HotNet
> (https://github.com/raphael-group/hotnet)
> In its simpleRun.py file, there is a place to insert a file path to be run.
> parser.add_argument('-mf', '--infmat_file', required=True,
> help='Path to .mat file containing influence matrix')
> My path file is /home/lai/Downloads/influence_matrix_files/hprd_inf_.mat
You're completely misunderstanding the purpose of this line of code. Its
intent is to allow you to pass the matrix file location to the script by
using the '-mf' or '--infmat_file' arguments, thus not requiring you to
edit the script at all.
The 'help' parameter provides a message explaining the usage of that
particular argument if the simpleRun.py script is executed with the '-help'
option.
For example, if you were unsure how to use the simpleRun.py script, you
might run this command:
simpleRun.py -help
And you might see output that looks like this:
Usage: simpleRun.py [options]
Options:
-h, --helpshow this help message and exit
-mf, --infmat_filePath to .mat file containing influence matrix
-d, --dance do a little dance
-l, --lovemake a little love
The help message thus informs you that you can provide the location to an
influence matrix file by using the '-mf' or '--infmat_file' arguments.
There are also -d and -l options that do ... something.
--
John Gordon Imagine what it must be like for a real medical doctor to
gor...@panix.comwatch 'House', or a real serial killer to watch 'Dexter'.
--
https://mail.python.org/mailman/listinfo/python-list
Re: running python 2 vs 3
On 20/03/2014 20:50, Marko Rauhamaa wrote: Mark Lawrence : On 20/03/2014 20:30, Marko Rauhamaa wrote: I must say, though, that Python3 destroyed "print" forever for me. To avoid nausea, I write sys.stdout.write() in all Python3 code. Not for me, I was using from __future__ import print_function for years so got used to typing those two extra brackets, plus print very kindly inserts the newlines for me. That very realization helped me wean myself from "print." Its sole raison d'être is the insertion of the newline, which it would be nicer to micromanage anyway; that's how it's done in other programming languages as well: C, perl, guile, ... (Well, ok, "echo" is the exception.) Marko The end keyword argument to the print function defaults to newline but you can make it anything you like, see http://docs.python.org/3/library/functions.html#print -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com -- https://mail.python.org/mailman/listinfo/python-list
Re: running python 2 vs 3
On 3/20/14 4:28 PM, notbob wrote: No wonder the latest O'Reilly book, Learning Python, 5th ed, is 1600 pgs. I coulda swore someone sed python is easy. ;) nb Python is easy, but its not simple. Python is elegant, and full of art, but it has no paucity of constructs, types, and opportunities for confusion. My goal for designing SimplyPy (for instance)is to present the beautiful heart of python (as Mark Summerfield calls it) and subsume the complexities of the fulness of python within a simple interface, BUT without limiting it. Python is easy enough to teach children (I've done it), but its "complete and elegant enough" for the most scientific of professionals. You do not need to know the fulness of python in order to use it. It is possible (even elegant) to use python (in a Rexx style) not at all recognized as "pythonized" code, and yet very very simple and powerful. The beauty of python, in my view, is the flexibility and extensibility of the namespace with something more than the minimalist approach of Lisp, BUT with the elegance of the language called python. Get Mark Summerfield's Programming Python 3. Its really quite good, and in my opinion better that the O'Reilly book, especially for new users. Just an opinion of course. marcus -- https://mail.python.org/mailman/listinfo/python-list
Re: running python 2 vs 3
On 3/20/2014 1:23 PM, notbob wrote: What the heck is a .pyc file and how are they created? .pyc contained compiled bytecode. They are created when, and only when, you import a module. Imported library files are often big and stable, so their compiled forms get cached. Top-level scripts are typically short and often volotile. They may be as short as "from start import run; run()" in order to have as much as possible stored in compiled form. This has nothing to do with Idle. I went back to my ~/python/ dir and noticed one .pyc file out of 15 .py files I created from following Learning Python the Hard Way. That must be the only one you imported. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: running python 2 vs 3
On 3/20/2014 3:07 PM, John Gordon wrote: There are two ways (at least!) to run a python script: 1. Execute the python interpreter manually, supplying the python script name as an arugment, like so: python myscript.py python2 otherscript.py python3 yetanotherscript.py This lets you choose on-the-fly which version of python is being used to interpret the script. 2. Execute the python script directly by just typing its name, like so: myscript.py ./otherscript.py /other/directory/yetanotherscript.py Depending on your operating system, this may require: a. Permissions on the script file be set to allow execution; b. A 'shebang' entry as the first line in the file which specifies the program that shall be executed; c. An association between '.py' and some version of python. 3. Use the python launcher py.exe with version selection. py -2 myscript.py py -3 myscript.py As far as I know, this is only for Windows at present. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: running python 2 vs 3
On 03/20/2014 11:10 AM, notbob wrote: > On 2014-03-20, Zachary Ware wrote: > >> If you're specifying the interpreter in your command (by calling >> "python .py", etc), the shebang won't mean anything >> anyway. > > DOH! > > I was following you, fine, until that last sentence. Then how should > I invoke the scripts? as your example is exactly how I've been > doing it with 2.7, as per Learn Python the Hard Way. Simply > ./.py from the appropriate directory (assuming I keep both > vers in separate dirs)?' If you want to run a script with python3, just invoke the python3 interpreter: python3 blah.py -- https://mail.python.org/mailman/listinfo/python-list
Re: running python 2 vs 3
notbob : > Weeping Chryst on the cross!!. No wonder the latest O'Reilly book, > Learning Python, 5th ed, is 1600 pgs. I coulda swore someone sed > python is easy. ;) It's not that bad. There are two principal dialects: python2 and python3. Take the oldest python version you have to support and write your code for that version. Python documentation carefully explains what language and library facilities are available in whichever version. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: Question about Source Control
Chris Angelico wrote: You can then offer a non-source-control means of downloading that specific revision. Just keep in mind the downside that you can't then push or pull your changes directly back into the main repository. You can generate a patch file for the project maintainer to apply, however. Hg makes it very easy to produce a patch file between any two revisions. Also, unless the project is truly ancient, the whole history might not be as big as you expect. The code presumably grew to its present size incrementally, in an approximately monotonic manner, so the sum of all the diffs is probably about the same order of magnitude as the current code size. As an experiment, I just cloned a copy of the CPython repository, and it's about 300MB. A tarball of Python 3.2 that I downloaded and compiled earlier is about 75MB. That's a ratio of about 4, and CPython is a pretty ancient project! -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: running python 2 vs 3
On 2014-03-20, Terry Reedy wrote: > That must be the only one you imported. So it is. Thank you. nb -- https://mail.python.org/mailman/listinfo/python-list
Re: running python 2 vs 3
Ned Batchelder : > On 3/20/14 4:59 PM, Marko Rauhamaa wrote: >> Well, with proper care, I suppose the same code base could support perl >> as well. ;) > > I'm not sure how to take this comment. I feel like you are mocking my > choice. I wanted to make coverage.py available to as broad an audience > as possible, something that I think is worthwhile. Yes, there was an > engineering cost, but the tradeoff was worth it. I can't judge if your particular choice was the right one. My only point is that python2 and python3 are so far apart as to be regarded as independent languages. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: Question about Source Control
On Fri, Mar 21, 2014 at 9:19 AM, Gregory Ewing wrote: > Chris Angelico wrote: >> >> You can then offer a non-source-control means of downloading that >> specific revision. > > Just keep in mind the downside that you can't then > push or pull your changes directly back into the main > repository. You can generate a patch file for the > project maintainer to apply, however. Hg makes it > very easy to produce a patch file between any two > revisions. Yes, but a lot of people just want to get the software, they don't actually need to generate patch files :) > Also, unless the project is truly ancient, the > whole history might not be as big as you expect. > The code presumably grew to its present size > incrementally, in an approximately monotonic > manner, so the sum of all the diffs is probably > about the same order of magnitude as the current > code size. > > As an experiment, I just cloned a copy of the > CPython repository, and it's about 300MB. A > tarball of Python 3.2 that I downloaded and > compiled earlier is about 75MB. That's a ratio > of about 4, and CPython is a pretty ancient > project! Yep! But cloning requires that you have Mercurial installed and, more importantly, know how to use it. We don't have a huge proliferation of source control systems these days, but if someone says "Our code is available via Perforce", I'm going to just look for a tarball download, rather than figure out a source control system I don't know. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: running python 2 vs 3
On Thu, 20 Mar 2014 22:30:57 +0200, Marko Rauhamaa wrote: > To avoid nausea, I write sys.stdout.write() in all Python3 code. Now that's funny. I-know-I-shouldn't-respond-to-obvious-trolling-but-I-can't-help-myself-ly yrs, -- Steven D'Aprano -- https://mail.python.org/mailman/listinfo/python-list
Re: running python 2 vs 3
On 20/03/2014 22:23, Marko Rauhamaa wrote: Ned Batchelder : On 3/20/14 4:59 PM, Marko Rauhamaa wrote: Well, with proper care, I suppose the same code base could support perl as well. ;) I'm not sure how to take this comment. I feel like you are mocking my choice. I wanted to make coverage.py available to as broad an audience as possible, something that I think is worthwhile. Yes, there was an engineering cost, but the tradeoff was worth it. I can't judge if your particular choice was the right one. My only point is that python2 and python3 are so far apart as to be regarded as independent languages. And I still say this is complete nonsense. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com -- https://mail.python.org/mailman/listinfo/python-list
Re: running python 2 vs 3
On Fri, Mar 21, 2014 at 7:08 AM, Marko Rauhamaa wrote: > Alan Meyer : > >> I presume it would still be a good idea to test both python >> interpreters against any script that you didn't knowingly write with a >> feature that will only work in one of the two python versions. >> >> If it works fine in both - and many will, then use: >> >> #!/usr/bin/env python >> >> Only use the "python2" or "python3" versions if you really have a >> reason to do so. >> >> Yes? No? > > No. Even if you managed to do that, it would mean getting the worst of > both worlds. The language dialects are too far apart. When you start > your Python project, you decide between Python 2 and Python 3 and go all > in. They're not that far apart. It's not difficult to write code that runs happily on both. However, it does mean you can't take advantage of Python 3 features, so it's probably better to write for one or the other, unless you specifically want wide distribution. For your own projects, just put whichever you need. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
CallBack function in C Libraries.
Hello. I want to use a c library. It is a complete graphic widget set.
Here code working. But i have problem with the callback function. The callback
is executed while ClikOnForm is executed but i get a error message (see after
code )
file fpgui-test.py
from ctypes import*
def TheProc(c_int): fpgui.fpgFormWindowTitle(0, 'Boum')
return 0
CMPFUNC = CFUNCTYPE(c_int)
TheProcF = CMPFUNC(TheProc)
fpgui = cdll.LoadLibrary("fpgui-32.dll")
fpgui.fpgInitialize() fpgui.fpgSetStyle('Demo Style') fpgui.fpgFormCreate(0,
-1) fpgui.fpgFormSetPosition(0, 300,100,400,200) fpgui.fpgFormWindowTitle(0,
'Hello world!')
fpgui.fpgFormOnClick(0,TheProcF)
fpgui.fpgButtonCreate(0,0,-1) ; fpgui.fpgButtonSetPosition(0,0, 15, 10 , 150 ,
40) fpgui.fpgButtonSetText(0,0, 'BUTTON1')
fpgui.fpgButtonCreate(0,1,-1) ; fpgui.fpgButtonSetPosition(0,1, 15, 70 , 150,
40) fpgui.fpgButtonSetText(0,1, 'Clickme')
fpgui.fpgFormShow(0) fpgui.fpgRun()
Here the error message if i click on form :
Traceback (most recent call last): File "_ctypes/callbacks.c", line 314, in
'calling callback function' TypeError: TheProc() takes exactly 1 argument (0
given)
What is wrong ?
Many thanks.
--
https://mail.python.org/mailman/listinfo/python-list
Re: running python 2 vs 3
On Fri, Mar 21, 2014 at 9:23 AM, Marko Rauhamaa wrote:
> Ned Batchelder :
>> On 3/20/14 4:59 PM, Marko Rauhamaa wrote:
>>> Well, with proper care, I suppose the same code base could support perl
>>> as well. ;)
>>
>> I'm not sure how to take this comment. I feel like you are mocking my
>> choice. I wanted to make coverage.py available to as broad an audience
>> as possible, something that I think is worthwhile. Yes, there was an
>> engineering cost, but the tradeoff was worth it.
>
> I can't judge if your particular choice was the right one. My only point
> is that python2 and python3 are so far apart as to be regarded as
> independent languages.
They're definitely not independent languages. The biggest change is
str/unicode->bytes/str, and you can get part of that in Python 2.6/2.7
with "from __future__ import unicode_literals". You may still run into
problems with some functions that expect str and won't take unicode
(or vice versa), but it's easy to make code that runs across both
versions that way. Then toss in "from __future__ import
print_function" and happily use the expanded features of print, or go
for the lowest common denominator:
print("some single string")
which works happily in all versions of Python.
I've written code that runs on 2.6+/3.2+. (Or maybe it's 3.1+;
whichever version Debian Squeeze ships with.) It's pretty easy. It's
certainly a lot easier than writing code that runs as either Pike or
C++, for instance. THOSE are independent languages. (And yes, I've
written that sort of code. Had a #define block up the top to handle
some naming differences, and then restricted myself to a *really*
narrow set of common operations. Was a neat way to prove correctness,
though.)
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: CallBack function in C Libraries.
On 3/20/14 6:16 PM, fienspr...@gmail.com wrote: def TheProc(c_int): fpgui.fpgFormWindowTitle(0, 'Boum') return 0 TheProcF = CMPFUNC(TheProc) Traceback (most recent call last): File "_ctypes/callbacks.c", line 314, in 'calling callback function' TypeError: TheProc() takes exactly 1 argument (0 given) What is wrong ? You defined TheProc(c_init) to take exactly 1 argument. But when you called it, you didn't provide the argument. So, you got a traceback indicating that TheProc() takes exactly one argument. Give the function call its required argument and the error will go away... well, at least that one. Cheers -- https://mail.python.org/mailman/listinfo/python-list
Re: CallBack function in C Libraries.
> Give the function call its required argument and the error will go > > away... well, at least that one. Yep, many thanks for the answer. But... im totally beginner with Python. I develop in Pascal and C and want to understand the basics of Python. In concrete, what must i change in the code ? Many thanks. -- https://mail.python.org/mailman/listinfo/python-list
Re: CallBack function in C Libraries.
On Friday, March 21, 2014 7:56:43 AM UTC+8, fiens...@gmail.com wrote: > > Give the function call its required argument and the error will go > > > > > > away... well, at least that one. > > > > Yep, many thanks for the answer. > > But... im totally beginner with Python. > > I develop in Pascal and C and want to understand the basics of Python. > > > > In concrete, what must i change in the code ? > > > > Many thanks. Python is a dynamical typed functional language with OOP supports in the revisons, and well suited in the giga-byte dram capacity personal toy era that can relplace her mother lisp's unrealized AI project . -- https://mail.python.org/mailman/listinfo/python-list
Installing ssdeep on Portable Python /advice
Portable Python 2.7 for Windows, the Python application have dependency on ssdeep-2.10, which is a binary exe. The ssdeep (libfuzzy) installation example was shown for Linux platform only: a) libfuzzy can be installed via apt-get: $ sudo apt-get install libfuzzy2 b) to install libfuzzy from source, download the gzipped tarball from http://ssdeep.sourceforge.net/#download, then run: $ tar -zxvf ssdeep-2.10.tar.gz $ cd ssdeep-2.10 && ./configure && make && sudo make install - I need install it on PortablePython for Windows, so it's not clear how to make this: where should be placed ssdeep Windows binary files, that Python application can found it? -- https://mail.python.org/mailman/listinfo/python-list
Re: Installing ssdeep on Portable Python /advice
On 21/03/2014 00:16, laguna...@mail.com wrote: Portable Python 2.7 for Windows, the Python application have dependency on ssdeep-2.10, which is a binary exe. The ssdeep (libfuzzy) installation example was shown for Linux platform only: a) libfuzzy can be installed via apt-get: $ sudo apt-get install libfuzzy2 b) to install libfuzzy from source, download the gzipped tarball from http://ssdeep.sourceforge.net/#download, then run: $ tar -zxvf ssdeep-2.10.tar.gz $ cd ssdeep-2.10 && ./configure && make && sudo make install - I need install it on PortablePython for Windows, so it's not clear how to make this: where should be placed ssdeep Windows binary files, that Python application can found it? You've changed the subject line but other than that this appears to be identical to the question you posed almost exactly six hours ago. It is considered polite to wait for at least 24 hours before again asking for assistance. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com -- https://mail.python.org/mailman/listinfo/python-list
Re: running python 2 vs 3
On Thu, 20 Mar 2014 21:28:43 +, notbob wrote: > On 2014-03-20, Mark H Harris wrote: > >> When I call python2 that means python2.7.6 / >> >> When I call python3 that means python3.3.4 / >> >> I can also call python2.7, which is 2.7.2 / >> >> You get the idea. There is no one set rule, because there are many >> distros (gnu/linux) that use python at various versions, and they all >> us different setups. Really , you need an install script to snoop out >> the configurables. > > Weeping Chryst on the cross!!. No wonder the latest O'Reilly book, > Learning Python, 5th ed, is 1600 pgs. I coulda swore someone sed python > is easy. ;) This has nothing to do with Python. It has to do with the way executables (applications) are mapped to file names on Unix and Unix-like systems. And that in turn is not terribly different from the way that it works on Windows as well. When you type "python" at the command prompt, your system locates an executable named "python", then runs it. If you wanted to be annoying, you could alias or link the python name to a completely different language. Or use a different name altogether: steve@orac:~$ alias snake=python steve@orac:~$ snake Python 2.6.6 (r266:84292, Dec 27 2010, 00:02:40) [GCC 4.4.5] on linux2 Type "help", "copyright", "credits" or "license" for more information. This has nothing to do with Python, it's the way Linux works. -- Steven D'Aprano http://import-that.dreamwidth.org/ -- https://mail.python.org/mailman/listinfo/python-list
Re: running python 2 vs 3
On Thu, 20 Mar 2014 16:26:39 -0400, Ned Batchelder wrote: > On 3/20/14 3:07 PM, Eric Jacoboni wrote: >> Le 20/03/2014 16:21, Marko Rauhamaa a écrit : >> >> >>> All tutorials will tell you to start it with >>> >>> #!/usr/bin/env python >>> >>> which will start python2 on all (?) existing linux distros, but is >>> expected to start python3 within the next decade. >> >> With Arch-Linux, python is python3... >> >> > Yes, and they have been told many times that this was foolish and wrong, > but it persists, much to our pain. How bizarre. I've been looking forward with great pleasure to Fedora moving to Python 3 as the standard system Python, expecting that this move from one of the big distros will start a chain reaction of others doing the same thing. Perhaps Arch-Linux is guilty of being prematurely Python 3, a little like those people hauled up to explain themselves to the House Unamerican Activities Committee to explain why they were a "premature anti-fascist". I have no idea what "our pain" you are referring to, or who "our" refers to. In the three or five years or so since Arch-Linux moved to Python 3 by default, I don't recall ever seeing even a single email from somebody confused by Arch-Linux's move, not here, or on the tutor mailing list, or on Python-Dev or Python-Ideas. Nor have I seen any signs of difficulty or confusion on Python-related blogs, or StackOverflow. That's not to say that there has been absolutely none at all. The Internet is a big place, and I daresay I've missed something. But given how small the Arch-Linux share of the Linux space is, I would be astonished if their move caused more than a tiny little ripple. Perhaps a paper-cut worth of pain. I expect that there have been far more angry words written over this issue than the actual consequences of the move itself. Unless you're in the unfortunate situation of having to migrate and maintain scripts across a network of mixed Linux distros including some that are Arch-Linux, it's difficult to see exactly what pain they could be causing even in principle. -- Steven D'Aprano http://import-that.dreamwidth.org/ -- https://mail.python.org/mailman/listinfo/python-list
Re: running python 2 vs 3
On Thu, 20 Mar 2014 16:53:25 -0400, Ned Batchelder wrote: > On 3/20/14 4:42 PM, Marko Rauhamaa wrote: >> Ned Batchelder : >> >>> Plenty of people have adopted a dual-support strategy, with one code >>> base that supports both Python 2 and Python 3. The six module can help >>> a great deal with this. >> >> I wonder how easy the resulting code is to the eyes and how easy it is >> for the casual maintainer to accidentally break the delicate balance. >> In a word, I wouldn't go there. Stay with Python2 as long as you must >> and then, migrate and leave it behind. > > This is fine advice for applications, but tools, libraries, and > frameworks may want to support more than one version at the same time. +1 Actually, even applications may want to support multiple versions. If I have a Python script that does something, I might not want to tie it to one specific version. In principle there's not much difference between "this will run under Python 2.6 and 2.7" and "this will run under Python 2.7 and 3.3". In practice, it's a little trickier to cross the 2/3 barrier than the 2.6/2.7 barrier. But it is still quite achievable, with a little extra effort. But you know that even better than I -- I take my hat off to you for supporting all the way back to Python 2.3, that is far more dedicated than I am. In my experience, such as it is, the hard part about writing code that works from 2.4 to 3.4 is not the 3 versions but the 2.4 and 2.5 versions. > It's an extreme case, but the latest released version of coverage.py > supports Python 2.3 through 3.3 with one code base. To do it, there's a > compatibility layer (akin to six). Then you stay away from features > that aren't available on all versions. In a few places, you might need > to have version checks, and the code can get a little idiomatic to > continue to work. > > It's a tradeoff: you have to decide for yourself whether the effort is > worth the benefit. I was glad to be able to drop support for 2.3, 2.4, > and 2.5, and now only support 2.6-3.4 in coverage.py. Sounds like your experience agrees with mine. -- Steven D'Aprano http://import-that.dreamwidth.org/ -- https://mail.python.org/mailman/listinfo/python-list
Re: running python 2 vs 3
On Thu, 20 Mar 2014 22:50:45 +0200, Marko Rauhamaa wrote: > Mark Lawrence : > >> On 20/03/2014 20:30, Marko Rauhamaa wrote: >>> I must say, though, that Python3 destroyed "print" forever for me. To >>> avoid nausea, I write sys.stdout.write() in all Python3 code. >> >> Not for me, I was using from __future__ import print_function for years >> so got used to typing those two extra brackets, plus print very kindly >> inserts the newlines for me. > > That very realization helped me wean myself from "print." Its sole > raison d'être is the insertion of the newline, which it would be nicer > to micromanage anyway; that's how it's done in other programming > languages as well: C, perl, guile, ... (Well, ok, "echo" is the > exception.) echo is not "the" exception. *Many* languages handle the newline when printing: Pascal, Ruby, Io, Dylan, Haskell, Rebol, Tcl, Perl6, Java, Ocaml, ... either add a newline by default, or provide two functions for printing, one which adds newline and one which doesn't. The rule of three applies here: anything you do in three different places ought to be managed by a function. Printing a newline at the end of a line of output is *incredibly* common. Any language which fails to provide a print-with-newline function is, frankly, sub-standard. -- Steven D'Aprano http://import-that.dreamwidth.org/ -- https://mail.python.org/mailman/listinfo/python-list
Re: running python 2 vs 3
On 3/20/14 8:32 PM, Steven D'Aprano wrote: On Thu, 20 Mar 2014 16:26:39 -0400, Ned Batchelder wrote: On 3/20/14 3:07 PM, Eric Jacoboni wrote: Le 20/03/2014 16:21, Marko Rauhamaa a écrit : All tutorials will tell you to start it with #!/usr/bin/env python which will start python2 on all (?) existing linux distros, but is expected to start python3 within the next decade. With Arch-Linux, python is python3... Yes, and they have been told many times that this was foolish and wrong, but it persists, much to our pain. How bizarre. I've been looking forward with great pleasure to Fedora moving to Python 3 as the standard system Python, expecting that this move from one of the big distros will start a chain reaction of others doing the same thing. Perhaps Arch-Linux is guilty of being prematurely Python 3, a little like those people hauled up to explain themselves to the House Unamerican Activities Committee to explain why they were a "premature anti-fascist". My understanding is that Fedora's move will not include making the word "python" mean Python 3. Their move means that Python 3 will be installed by default, and that their Python programs that are part of the distro will be Python 3 programs. They can still refer to it as "python3". I have no idea what "our pain" you are referring to, or who "our" refers to. In the three or five years or so since Arch-Linux moved to Python 3 by default, I don't recall ever seeing even a single email from somebody confused by Arch-Linux's move, not here, or on the tutor mailing list, or on Python-Dev or Python-Ideas. Nor have I seen any signs of difficulty or confusion on Python-related blogs, or StackOverflow. In the #python IRC channel, there's a steady flow of people who run programs they find online, and they get a syntax error on "print", and we say, "Arch?" and they say, "yup". Perhaps I overstated the amount of pain. But Arch's move prompted a PEP to be written explaining what the word "python" should mean: http://python.org/dev/peps/pep-0394/ Note that they say there that "for the time being" the word python should mean Python 2, anticipating that eventually it will be OK to change it to Python 3. But I think that change would always cause confusion, and we should not change it over. I understand that this is a controversial view, and don't hold it strongly enough to defend it. :) That's not to say that there has been absolutely none at all. The Internet is a big place, and I daresay I've missed something. But given how small the Arch-Linux share of the Linux space is, I would be astonished if their move caused more than a tiny little ripple. Perhaps a paper-cut worth of pain. It caused enough of a ripple to get PEP 394 written so that people wouldn't do it again. I expect that there have been far more angry words written over this issue than the actual consequences of the move itself. Unless you're in the unfortunate situation of having to migrate and maintain scripts across a network of mixed Linux distros including some that are Arch-Linux, it's difficult to see exactly what pain they could be causing even in principle. -- Ned Batchelder, http://nedbatchelder.com -- https://mail.python.org/mailman/listinfo/python-list
Re: running python 2 vs 3
In article <532b8f0d$0$29994$c3e8da3$54964...@news.astraweb.com>, Steven D'Aprano wrote: > The rule of three applies here: anything you do in three different places > ought to be managed by a function. I prefer the rule of two :-) -- https://mail.python.org/mailman/listinfo/python-list
Re: running python 2 vs 3
On Fri, Mar 21, 2014 at 11:32 AM, Steven D'Aprano wrote: > Perhaps Arch-Linux is guilty of being prematurely Python 3... > > I have no idea what "our pain" you are referring to, or who "our" refers > to. In the three or five years or so since Arch-Linux moved to Python 3 > by default, I don't recall ever seeing even a single email from somebody > confused by Arch-Linux's move, not here, or on the tutor mailing list, or > on Python-Dev or Python-Ideas. Nor have I seen any signs of difficulty or > confusion on Python-related blogs, or StackOverflow. > > That's not to say that there has been absolutely none at all. There definitely has been a little. Scripts that began with a "python" shebang and assumed 2.x would suddenly fail on Arch. But not a huge amount of confusion. I expect that there'll be a progressive shift - more distros will start shipping 3.x under the name "python", so script authors will be more and more aware of the difference, and before long we'll settle on explicit use of "python2" or "python3" for anything that matters. Think of the bug reports: "Your program doesn't work on Ubuntu 14.04, but change the shebang and it'll work, without breaking it for anything else". Easy fix. And then once Debian and Red Hat move to 3.x as the default system Python, everyone'll use "python2" for 2.7 (by that time, I doubt 2.6 or earlier will be supported much anywhere) and "python" for 3.x, and the transition will be complete. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: running python 2 vs 3
On Fri, Mar 21, 2014 at 11:59 AM, Steven D'Aprano wrote: > The rule of three applies here: anything you do in three different places > ought to be managed by a function. Printing a newline at the end of a > line of output is *incredibly* common. Any language which fails to > provide a print-with-newline function is, frankly, sub-standard. I wouldn't go that far. There are plenty of languages where the default (printf, write, werror, etc) doesn't add the newline, and I wouldn't call the *language* sub-standard for that. But yes, it does bug me now and then. I use my "say" function to produce one or more lines of output in Gypsum, and it guarantees complete lines (because the system works with lines, not streams of characters); and then if I use the "werror" function to write to stderr, I have to remember to add the newline. However, I think Py2's print statement has way too many weirdnesses - the trailing comma (reminiscent of BASIC, where I never liked it either), the whole "soft space" concept, etc. Py3's print function, with the keyword end="", is a lot better, though still a tad verbose. (I don't know of any solution to that.) ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: running python 2 vs 3
On 3/20/14 9:06 PM, Ned Batchelder wrote: On 3/20/14 8:32 PM, Steven D'Aprano wrote: On Thu, 20 Mar 2014 16:26:39 -0400, Ned Batchelder wrote: On 3/20/14 3:07 PM, Eric Jacoboni wrote: Le 20/03/2014 16:21, Marko Rauhamaa a écrit : All tutorials will tell you to start it with #!/usr/bin/env python which will start python2 on all (?) existing linux distros, but is expected to start python3 within the next decade. With Arch-Linux, python is python3... Yes, and they have been told many times that this was foolish and wrong, but it persists, much to our pain. How bizarre. I've been looking forward with great pleasure to Fedora moving to Python 3 as the standard system Python, expecting that this move from one of the big distros will start a chain reaction of others doing the same thing. Perhaps Arch-Linux is guilty of being prematurely Python 3, a little like those people hauled up to explain themselves to the House Unamerican Activities Committee to explain why they were a "premature anti-fascist". My understanding is that Fedora's move will not include making the word "python" mean Python 3. Their move means that Python 3 will be installed by default, and that their Python programs that are part of the distro will be Python 3 programs. They can still refer to it as "python3". From http://fedoraproject.org/wiki/Changes/Python_3_as_Default : Users shouldn't notice any changes, ... /usr/bin/python will still point to Python 2 and depending on result of discussions with FPC, "yum install python-foo" will still install Python 2 version of the package. -- Ned Batchelder, http://nedbatchelder.com -- https://mail.python.org/mailman/listinfo/python-list
Re: running python 2 vs 3
On 03/20/2014 05:37 PM, Steven D'Aprano wrote: In my experience, such as it is, the hard part about writing code that works from 2.4 to 3.4 is not the 3 versions but the 2.4 and 2.5 versions. +1000! (yes, that's factorial ;) -- ~Ethan~ -- https://mail.python.org/mailman/listinfo/python-list
Re: Question about Source Control
On 21Mar2014 09:34, Chris Angelico wrote: > On Fri, Mar 21, 2014 at 9:19 AM, Gregory Ewing > > Also, unless the project is truly ancient, the > > whole history might not be as big as you expect. > > The code presumably grew to its present size > > incrementally, in an approximately monotonic > > manner, so the sum of all the diffs is probably > > about the same order of magnitude as the current > > code size. > > > > As an experiment, I just cloned a copy of the > > CPython repository, and it's about 300MB. A > > tarball of Python 3.2 that I downloaded and > > compiled earlier is about 75MB. That's a ratio > > of about 4, and CPython is a pretty ancient > > project! > > Yep! But cloning requires that you have Mercurial installed and, more > importantly, know how to use it. We don't have a huge proliferation of > source control systems these days, but if someone says "Our code is > available via Perforce", I'm going to just look for a tarball > download, rather than figure out a source control system I don't know. Someone intending to clone the project and develop will probably want the whole repository; as Gregory says - they can then easily push/pull with others. For Frank, the size of the repo is not the size of the bare code * number of changesets. There are many diff-level steps in there, making for a much smaller size. And code is small; really really small. Regarding having Mercurial installed, that is very easy, and after you've gone (eg): hg clone https://bitbucket.org/cameron_simpson/css my-copy-of-cameron's-css (or wherever the public repository is published), you can of course then walk away and work. You no longer need the public copy at all. With a DVCS the threshold is low and the advantages are high (hg or git; I'm an hg person myself). Cheers, -- Cameron Simpson I am returning this otherwise good typing paper to you because someone has printed gibberish all over it and put your name at the top. - English Professor, Ohio University -- https://mail.python.org/mailman/listinfo/python-list
Re: CallBack function in C Libraries.
On Thu, 20 Mar 2014 23:56:43 -, wrote: Give the function call its required argument and the error will go away... well, at least that one. Yep, many thanks for the answer. But... im totally beginner with Python. I develop in Pascal and C and want to understand the basics of Python. In concrete, what must i change in the code ? In abstract, exactly the same thing that you would change if a C compiler had complained to you that you had failed to give a function call the right number of arguments. More than that I have no idea; it's your code, presumably you know what it should be doing. I have absolutely no idea how TheProc() is being called by your widgets. Are you sure it should be declared as taking a single parameter? I'm afraid it doesn't help that GoogleGroups has badly mangled the formatting of your code. I'm not quite sure what to suggest since it isn't one of the usual problems, but you might find reading https://wiki.python.org/moin/GoogleGroupsPython helpful. It will certainly help with the double-spacing in your quote above. -- Rhodri James *-* Wildebeest Herder to the Masses -- https://mail.python.org/mailman/listinfo/python-list
Re: Question about Source Control
On Fri, Mar 21, 2014 at 12:33 PM, Cameron Simpson wrote: > Regarding having Mercurial installed, that is very easy, and after > you've gone (eg): > > hg clone https://bitbucket.org/cameron_simpson/css my-copy-of-cameron's-css > > (or wherever the public repository is published), you can of course > then walk away and work. You no longer need the public copy at all. > > With a DVCS the threshold is low and the advantages are high (hg > or git; I'm an hg person myself). Yes, it's not hard to get Mercurial. And it's not hard to get git. But it is an extra barrier, and trying to tell people they need this-that-and-the-other just to get your software is a pain. Personally, I'm quite happy fetching from either git or hg, because I'm at least broadly familiar with both (more with git), but if it's something I'm *not* familiar with (cvs? Haven't used it in forever), less happy. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: running python 2 vs 3
On Fri, Mar 21, 2014 at 12:06 PM, Roy Smith wrote: > In article <532b8f0d$0$29994$c3e8da3$54964...@news.astraweb.com>, > Steven D'Aprano wrote: > >> The rule of three applies here: anything you do in three different places >> ought to be managed by a function. > > I prefer the rule of two :-) The way I explain it is: Three is a rule of thumb. Sometimes it's blatantly obvious at two, and other times you need four or five similar pieces of code before you can see which part should become the function. If the code's absolutely identical and reasonably long/complex, then yes, two's all you need, but how often is that? Usually it's similar, rather than congruent... err I mean identical. That's where the third usage comes in. Or if it's maybe 2-3 lines, used in two places, it doesn't necessarily need to be a function. Again, a third usage is a strong hint that it should be broken out. The rule doesn't say that anything that *isn't* in three places yet should *not* be broken out. :) ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: running python 2 vs 3
On Friday, March 21, 2014 2:23:25 AM UTC+5:30, Ned Batchelder wrote: > On 3/20/14 4:42 PM, Marko Rauhamaa wrote: > > Ned Batchelder : > >> Plenty of people have adopted a dual-support strategy, with one code > >> base that supports both Python 2 and Python 3. The six module can help > >> a great deal with this. > > I wonder how easy the resulting code is to the eyes and how easy it is > > for the casual maintainer to accidentally break the delicate balance. In > > a word, I wouldn't go there. Stay with Python2 as long as you must and > > then, migrate and leave it behind. > This is fine advice for applications, but tools, libraries, and > frameworks may want to support more than one version at the same time. > It's an extreme case, but the latest released version of coverage.py > supports Python 2.3 through 3.3 with one code base. To do it, there's a > compatibility layer (akin to six). Then you stay away from features > that aren't available on all versions. In a few places, you might need > to have version checks, and the code can get a little idiomatic to > continue to work. > It's a tradeoff: you have to decide for yourself whether the effort is > worth the benefit. I was glad to be able to drop support for 2.3, 2.4, > and 2.5, and now only support 2.6-3.4 in coverage.py. Ned is talking to (and from) a lib-writer perspective Marko is talking from noob perspective (which is what the OP looks like) Good to choose our hats appropriately -- https://mail.python.org/mailman/listinfo/python-list
Re: running python 2 vs 3
On 3/20/2014 3:07 PM, John Gordon wrote: There are two ways (at least!) to run a python script: > On 21/03/2014 8:05 AM, Terry Reedy wrote: 3. [...] "Our chief weapon is..." -- https://mail.python.org/mailman/listinfo/python-list
Python - Caeser Cipher Not Giving Right Output
Hello good people I am working on a caeser cipher program for class. However, I
ran into a problem with my outputs. Up to a certain point for example:
1. two('y', 'z')
Would give a '\x92' output instead of a 'x' output.
Currently this is my code so far:
def chartonum(ch):
return ord(ch) - 97
def numtochar(n):
return chr(n + 97)
def two(c1 , c2):
c1 = chartonum(c1)
c2 = chartonum(c2)
return numtochar(c1 + c2 %26)
I am thinking I have messed up on my mod 26, however, I am at a lost where I
might have went wrong in that. Any help would be appreciated.
--
https://mail.python.org/mailman/listinfo/python-list
Re:Python - Caeser Cipher Not Giving Right Output
dtran...@gmail.com Wrote in message:
> Hello good people I am working on a caeser cipher program for class. However,
> I ran into a problem with my outputs. Up to a certain point for example:
>
> 1. two('y', 'z')
>
> Would give a '\x92' output instead of a 'x' output.
>
> Currently this is my code so far:
>
> def chartonum(ch):
> return ord(ch) - 97
>
> def numtochar(n):
> return chr(n + 97)
>
> def two(c1 , c2):
> c1 = chartonum(c1)
> c2 = chartonum(c2)
> return numtochar(c1 + c2 %26)
You're missing some parentheses in that line. To test your
understanding, try picking some numbers for c1 and c2. Display
c1 + c2 % 26, and see if the result is always between 0 and
25.
Or look up the term precedence in your textbook.
>
> I am thinking I have messed up on my mod 26, however, I am at a lost where I
> might have went wrong in that. Any help would be appreciated.
>
--
DaveA
--
https://mail.python.org/mailman/listinfo/python-list
Re: running python 2 vs 3
On Thu, 20 Mar 2014 21:06:24 -0400, Ned Batchelder wrote: > In the #python IRC channel, there's a steady flow of people who run > programs they find online, and they get a syntax error on "print", and > we say, "Arch?" and they say, "yup". When you install random programs you find online without going through your package manager, you have no guarantee that all the dependencies will be met. Particularly of third-party libraries, but also of standard Python libraries too: http://bytes.com/topic/python/answers/448757-how-enable-rotor-python-2-4-2-a If your script uses xreadlines, rotor, or mpz, using "python" to refer to both pre-2.4 and post-2.4 will cause breakage. Likewise, I've seen Python 2.6 break applications because it removed string exceptions. So I'm not seeing anything out of the ordinary with Arch: any version change has the possibility to break scripts. Python 3 is just more obvious because of the change to print, which I daresay is a little more common than rotor... Arch happens to be at the bleeding edge of that, bless them, but if you use Arch, that's what you're letting yourself into. You know what they say -- even Slackware users think Arch users are nuts :-) I've also seen scripts broken because the script used a hard-coded path to the Python executable, like /usr/bin/python or /usr/local/bin/python. Or because they've hard-coded the version number. Or because they didn't hard-code the version number. I haven't seen scripts broken because "env" has moved, but I guess that's only a matter of time. Frankly, hash-bang lines are a dirty hack, and like all dirty hacks, they work really well until they suddenly don't. -- Steven D'Aprano http://import-that.dreamwidth.org/ -- https://mail.python.org/mailman/listinfo/python-list
Re: Python - Caeser Cipher Not Giving Right Output
On Thursday, March 20, 2014 11:16:50 PM UTC-4, Dave Angel wrote:
> dtran...@gmail.com Wrote in message:
>
> > Hello good people I am working on a caeser cipher program for class.
> > However, I ran into a problem with my outputs. Up to a certain point for
> > example:
>
> >
>
> > 1. two('y', 'z')
>
> >
>
> > Would give a '\x92' output instead of a 'x' output.
>
> >
>
> > Currently this is my code so far:
>
> >
>
> > def chartonum(ch):
>
> > return ord(ch) - 97
>
> >
>
> > def numtochar(n):
>
> > return chr(n + 97)
>
> >
>
> > def two(c1 , c2):
>
> > c1 = chartonum(c1)
>
> > c2 = chartonum(c2)
>
> > return numtochar(c1 + c2 %26)
>
>
>
> You're missing some parentheses in that line. To test your
>
> understanding, try picking some numbers for c1 and c2. Display
>
> c1 + c2 % 26, and see if the result is always between 0 and
>
> 25.
>
>
>
> Or look up the term precedence in your textbook.
>
>
>
> >
>
> > I am thinking I have messed up on my mod 26, however, I am at a lost where
> > I might have went wrong in that. Any help would be appreciated.
>
> >
>
>
>
>
>
> --
>
> DaveA
Thanks for your input Dave. Would the line be:
return numtochar(c1 + c2 %26)
c1 and c2 are lower-case letters. And I was wondering how I would add the
partenthesis because I tried:
return numtochar(c1 + c2 (%26)) and it gave me an error.
--
https://mail.python.org/mailman/listinfo/python-list
Re: running python 2 vs 3
On Fri, Mar 21, 2014 at 2:16 PM, Steven D'Aprano wrote: > I haven't seen scripts broken because "env" > has moved, but I guess that's only a matter of time. That usage is extremely common, and isn't it also specified by POSIX? I think that's about as dependable as you can get. Course, it does depend on the user's $PATH... ChrisA -- https://mail.python.org/mailman/listinfo/python-list
