Re: pygresql
On Nov 4, 8:45 pm, JD <[EMAIL PROTECTED]> wrote: > Hi there. > > I'm trying to use python with postgresql. I decided to use psycopg to > interact with the postgresql server. When installing psycopg it > appeared that I needed mxDateTime. So I decided to install the mxbase > package. > > I received the following error message (the interesting bit seems to > be at the end): snipped > Thank you very much in advance for any assistance, > James. Why are you trying to install yourself instead of using apt? On my debian etch box the psycopg packages have dependencies to the python- egenix-mx* packages and installing psycopg pulls in the others without problems. And I guess ubuntu should be similar. -- http://mail.python.org/mailman/listinfo/python-list
python equivalent to heckle
heckle in ruby is inspired by jester for java. I quote: Heckle is a mutation tester. It modifies your code and runs your tests to make sure they fail. The idea is that if code can be changed and your tests don't notice, either that code isn't being covered or it doesn't do anything. from http://glu.ttono.us/articles/2006/12/19/tormenting-your-tests-with-heckle Is there anything similar for python?? -- http://mail.python.org/mailman/listinfo/python-list
Re: Python IDE
On Nov 10, 8:43 am, [EMAIL PROTECTED] wrote: > On Nov 3, 10:11 pm, Simon Pickles <[EMAIL PROTECTED]> wrote: > > > Hi, > > > I have recently moved from Windows XP to Ubuntu Gutsy. > > > I need a Python IDE and debugger, but have yet to find one as good as > > Pyscripter for Windows. Can anyone recommend anything? What are you all > > using? > > > Coming from a Visual Studio background, editing text files and using the > > terminal to execute them offends my sensibilities :) > > > Thanks > > > Si > > - > eclipse + pydev plugin will be a good choice. > thanks I had problems installing pydev because of mylin/mylar. These forums had the same issue a few days ago, see http://groups.google.com/group/comp.lang.python/msg/59394feeada558fd I was considering eclipse because I believe that eclipse gives good refactoring support. [And a client wanted it!] But then I found that eclipse uses pydev for python. And python uses bicycle repair man -- which is what emacs uses for refactoring! So might as well stay with emacs. To substantiate what Bruno says: The USP of python is that its an interpreter -- you can learn python by playing around without an elaborate compile-link-test-edit cycle. The USP of emacs (in this context) is its support for inferior interpreters along with good editing support. Hence the combo is quite hard to beat. -- http://mail.python.org/mailman/listinfo/python-list
Re: rope python-emacs problem
[EMAIL PROTECTED] wrote:
> On Oct 15, 7:19�pm, "Rustom Mody" <[EMAIL PROTECTED]> wrote:
> > Ive been trying to useropefor python in emacs and I get
> > a backtrace which starts with
> > AttributeError: 'module' object has no attribute 'samefile'
> >
> > Any ideas?
>
> I searched for a variable 'samefile' in ropemacs and its
> associated packages. I couldn't find one. That is not
> to say there wasn't one because ropemacs is in flux more
> than most packages with frequent rewrites.
Two points here.
1. googling around suggests that this kind of error ('samefile'...) is
often related to circular imports in python.
2. I passed this on to the rope mailing list and the author -- Ali
Gholami Rudi -- has corrected the problem
>
> May I can suggest to start again and use the most recent
> packages- Pymacs-0.24beta1, rope-0.9, and ropemacs-0.6.
> I installed these about a week ago when I installed
> Python 2.6, and it was painless (Windows OS and Emacs 22).
I am running python 2.5 rope 0.9 pymacs 0.23.
Do you expect the instability to come out of these versions
(mis)matches?
--
http://mail.python.org/mailman/listinfo/python-list
Re: Emacs users: feedback on diffs between python-mode.el and python.el?
On Oct 16, 8:37 am, Michele Simionato <[EMAIL PROTECTED]> wrote: > On Oct 14, 7:37 pm, [EMAIL PROTECTED] wrote: > > > If you're an Emacs user who has used both python-mode.el (the python mode > > code distributed with Python and XEmacs) and python.el (the python mode code > > distributed with GNU Emacs), I'd like to get your impressions on how they > > compare and where you feel the bugs lie. I'm nominally one of the > > python-mode.el maintainers (though not very active) but have never tried the > > GNU python.el. > > > Thanks, > > > -- > > Skip Montanaro - [EMAIL PROTECTED] -http://www.webfast.com/~skip/ > > I second Bruno's points, the older python-mode.el is much > better, also because of the included class browser, which > is missing in python.el. python.el seems to be integrated > with pymacs out of the box, but I do not use it so I cannot say for > sure if it works well or no. I am interested in knowing which mode supports better the use of pdb inside emacs? Is it python-mode? -- http://mail.python.org/mailman/listinfo/python-list
Re: Emacs users: feedback on diffs between python-mode.el and python.el?
On Oct 16, 12:54 am, Bruno Desthuilliers <[EMAIL PROTECTED]> wrote: > Lawrence D'Oliveiro a écrit : > > > I find Emacs modes just too confusing. I do all my editing in fundamental > > mode. > > Sounds like buying a cray supercomputer to end up doing computation by > hand... Reminds me of a funny story about one of our university profs. At a time when we used DOS and unix (on terminals) he got a very high end SGI workstation. And promptly shouted at the sysads because he could not see his C:> prompt. -- http://mail.python.org/mailman/listinfo/python-list
suid/sudo in python
Im trying to write a program that has su permissions for some file system tasks and is non-su elsewhere. This is typically done in C with suid root owned code. What is the python paradigm for this kind of thing? (if at all) -- http://mail.python.org/mailman/listinfo/python-list
Re: Re. suid/sudo in python
On Mar 30, 6:47 pm, [email protected] wrote: > On Mar 30, 1:16 pm, Rustom Mody wrote: > > > > > Ben Finney wrote > > > > The key thing to realise is that, having relinquished privilege, the same > > > process can't get it back again as easily. So if you need to > > > do some tasks as a privileged user, do those *very* early and then drop > > > the privileges for the rest of the life of the process. > > > > Taking this further, you should isolate exactly what tasks need root > > > privilege into a separate process altogether, and make > > > that process as well-tested and simple as possible: it should do nothing > > > *but* those tasks for which it needs root privilege. > > > I dont think this would be easy or convenient (if at all possible) in my > > case. > > > I am trying to write a tiny web based application that will give an > > overall picture of LVM, Volume groups, Raid, SCSI and the underlying > > disk partitions. The administrative tools dealing with low level > > storage stack (e.g. fdisk, pvcreate, vgcreate, lvcreate, mdadm etc.) > > need to be run as root. > > > However since this runs behind apache. Apache creates a separate user > > for the webserver. Hence the CGI scripts or any other tools that they > > call run as that user. > > > The solution currently is > > - Write the CGI program in C, put setuid(0), setgid(0) statements in > > that file and then perform any other actions (including calling other > > scripts) > > - Set the S bit of the executable of the CGI binary compiled from the > > C file (chmod +S xxx.cgi) > > > Yeah yeah "Security! HOLE!!" etc but please note that this is running > > on linux on vmware on an otherwise secure system. > > > So whats the best way of doing this in python? > > Have a 'server process' running with root privilege ( a script started > by a privileged account) and implement a protocol to ask for system > info from your cgi scripts under apache. In python this is a lot > easier than it sounds. > The simplest case would be that to send a 'system command' to the > server through a unix socket, the server > executes the command as received and returns the command output. Not > more than a day work, I believe. Not much more secure that > a setuid python script, also, maybe less :-) Well the current C root owned setuid-ing and calling out to shell is simple enough I guess. The shell could be replaced by python of course. > A better implementation would be such that the protocol only allows > for a set of pre-defined safe requests ... -- http://mail.python.org/mailman/listinfo/python-list
Re: Re. suid/sudo in python
On Mar 30, 9:41 pm, "Martin P. Hellwig" wrote: > Rustom Mody wrote: > > The essence of your program is that you only want information, that is > great! Since that makes it all a bit simpler. > > How about writing a cronjob that outputs the require information into a > file and then write a separate program that reads the output and > displays it on the web site when requested? I dont 'only want information.' I want to do everything that root can do through a web interface > I don't think this is necessary a python problem but a generic, SUID > scripts considered dangerous, problem. Yeah I know and I'm prepared for the consequences -- think of it as running with the hardware ethernet interfaces down-ed. Seems to contradict the web thing above so let me explain: Machine runs vista -> Vista runs VMware -> VMware hosts ubuntu Ubuntu behaves like a disk rack. Through the web client running on Vista, I want to view and *Control* the ubuntu disk rack (somewhat like manipulating the cups printer via localhost://631) The context is that we want to teach a course on LVM, RAID, SCSI actual disks etc and during that we would like a nice summarised picture in front of the class rather than arcane playing-around-ing with fdisk, pvcreate, vgcreate, lvcreate, mdadm etc command lines. I think I know what I am going to try (Got it from an old python list posting here http://mail.python.org/pipermail/python-list/2000-July/044690.html which explains how perl does it) Copy /usr/bin/python to ~/bin/python-su make it suid run the scripts under python-su Any major holes (apart from the security ones :-) ) in my plan?? -- http://mail.python.org/mailman/listinfo/python-list
Re: Thoughts on language-level configuration support?
I am not sure I understand your solution. I certainly think that the problem is big, very much bigger than is appreciated. Think of the hoopla in the RoR world about convention-over- configuration. On the other hand I feel that emacs is becoming messier and messier because it has taken up something like your idea. Originally there was only setq (lisp for assignment). Now there is the whole customize- mess. Then again I guess its not the idea that is wrong but its current state of implementation. To elaborate on this mess would be too OT for this list. Nevertheless its a good starting point for the kind of thing you are talking of. -- http://mail.python.org/mailman/listinfo/python-list
Re: help with recursive whitespace filter in
On May 10, 9:49 pm, Steve Howell wrote:
> On May 10, 9:10 am, Rustom Mody wrote:
>
>
>
> > I am trying to write a recursive filter to remove whitespace-only
> > nodes for minidom.
> > The code is below.
>
> > Strangely it deletes some whitespace nodes and leaves some.
> > If I keep calling it -- like so: fws(fws(fws(doc))) then at some
> > stage all the ws nodes disappear
>
> > Does anybody have a clue?
>
> > from xml.dom.minidom import parse
>
> > #The input to fws is the output of parse("something.xml")
>
> > def fws(ele):
> > """ filter white space (recursive)"""
>
> > for c in ele.childNodes:
> > if isWsNode(c):
> > ele.removeChild(c)
> > #c.unlink() Makes no diff whether this is there or not
> > elif c.nodeType == ele.ELEMENT_NODE:
> > fws(c)
>
> > def isWsNode(ele):
> > return (ele.nodeType == ele.TEXT_NODE and not ele.data.strip())
>
> I would avoid doing things like delete/remove in a loop. Instead
> build a list of things to delete.
Yeah I know. I would write the whole damn thing functionally if I knew
how. But cant figure out the API.
I actually started out to write a (haskell-style) copy out the whole
tree minus the unwanted nodes but could not figure it out
--
http://mail.python.org/mailman/listinfo/python-list
Re: using urlretrive/urlopen
On May 16, 6:30 am, "Gabriel Genellina"
wrote:
> En Fri, 15 May 2009 12:03:09 -0300, Rustom Mody
> escribió:
>
> > I am trying to talk to a server that runs on localhost
> > The server runs onhttp://localhost:7000/and that opens alright in a
> > web browser.
>
> > However if I use urlopen or urlretrieve what I get is this 'file' --
> > obviously not the one that the browser gets:
>
> >
> > Query 'http://localhost:7000/'not implemented
> >
> > Any tips/clues?
>
> Please post the code you're using to access the server.
> Do you have any proxy set up?
>
> --
> Gabriel Genellina
Thanks Gabriel!
urlopen("http://localhost:7000";, proxies={})
seems to be what I needed.
--
http://mail.python.org/mailman/listinfo/python-list
Re: making a python program in windows
On May 21, 3:19 pm, "Martin P. Hellwig" wrote: > Rustom Mody wrote: > > I know how to make a python script behave like a (standalone) program > > in unix -- > > 1. put a #! path/to/python as the first line > > 2. make the file executable > > > The closest I know how to do this in windows is: > > r-click the file in win-explorer > > goto properties > > goto open with > > change pythonw to python > > > Can someone enlighten me about a more scriptish way of doing this? > > Basically if I have to setup that program on other (windows) m/cs is > > there some .bat or .vbs or some regedit thingy Ive to do to avoid the > > Rt-click routine? > > Since you don't know for sure if a Python environment is available on > the other windows machine and whether the file associations are > configured correctly, the best thing you can do is to use something like > py2exe and distribute the result of that. Oh - Oh! Not an exe please! I dont want to move away from readable text files if possible. I certainly know that python2.6 is installed. Why that installation by default does not put python.exe on the path I dont know but that is best corrected by hand. Bottom Line: Assume that from a command line (cmd) python runs and gives its interpreter prompt. When run from cygwin it hangs but thats another story. Just dont assume cygwin. i suppose the question is entirely about setting properly (and grokking) file associations -- why is a .py file associated with pythonw and not python? And is making this association right enough to make a .py file in windows behave like a shebang file in unix? [And is there a more appropriate list for such questions?] Thanks -- http://mail.python.org/mailman/listinfo/python-list
Re: making a python program in windows
On May 21, 5:09 pm, Duncan Booth wrote: > rustom wrote: > > i suppose the question is entirely about setting properly (and > > grokking) file associations -- why is a .py file associated with > > pythonw and not python? And is making this association right enough to > > make a .py file in windows behave like a shebang file in unix? > > I think the question about the file association is one you have to answer > for yourself. When you install Python it associates .pyw with pythonw and > .py with python. If something on your system has changed this the best > thing you can do is to change it back. > > Try typing the following commands and then fixing any differences by typing > the expected output as the command parameter > (e.g. "assoc .py=Python.File"): > > C:\>assoc .py > .py=Python.File > > C:\>assoc .pyw > .pyw=Python.NoConFile > > C:\>ftype Python.file > Python.file="C:\Python26\python.exe" "%1" %* > > C:\>ftype Python.NoConFile > Python.NoConFile="C:\Python26\pythonw.exe" "%1" %* > > -- > Duncan Boothhttp://kupuguy.blogspot.com Thanks for this (and all other) tips. Strangely now my m/c shows things exactly like so. A new .py file gets associated with python but two days ago it was with pythonw?! Any recos on where I could read up on this stuff? -- http://mail.python.org/mailman/listinfo/python-list
Re: 4 hundred quadrillonth?
On May 22, 6:56 am, AggieDan04 wrote: > The error in this example is roughly equivalent to the width of a red > blood cell compared to the distance between Earth and the sun. There > are very few applications that need more accuracy than that. For a mathematician there are no inexact numbers; for a physicist no exact ones. Our education system is on the math side; reality it seems is on the other. -- http://mail.python.org/mailman/listinfo/python-list
Re: What text editor is everyone using for Python
I dont think Ive seen it said on this thread (if yes sorry for missing it) If you use emacs 1. DONT use the python.el that comes with emacs but use python-mode.el that comes from python 2. Use python as an interpreter ie not as you would use C or Java or ... which is to say 2.1 Start python as an interpreter under emacs ... which (assuming emacs is set up properly) means 2.1.1 M-x py-shell or 2.1.2 From a python source file C-c C-c 2.2 Dont (PLEASE) start a shell and start python in that; start a genuine 'inferior' python under emacs (yes emacs-speak is a bit weird but once you get used to it it has no replacement) 3. The most useful paradigm of noob hacking of python in emacs is to split the window into 2, keep your python file in one and the inferior python interpreter in the other. 4. After you've graduated out of noob status you may like to look at 4.1 pdb (Ive not managed to get this to run on windows) 4.2 doctest mode 4.3 rope 4.4 ipython -- http://mail.python.org/mailman/listinfo/python-list
Re: what I would like python.el to do (and maybe it does)
> But since i like to do it The Right Way, I would > like to let the python-mode worry about this... > > Sorry if this is just a bunch of obvious thoughts to most of you. > > Regards, > Giovanni I dont see whats the problem. Heres my attempt to show you my emacs windows using python-mode (python.el never worked for me) ## Window 1 file foo.py (python mode) x = 1 y = 2 ## Window 2 python interpreter >>> Goto the python file (foo.py) Select the x=1 line C-c | (which is py-execute-region) Goto python interpreter window >>> x 1 >>> y ... NameError: y not defined What more/less/else do you want? Are you using python-mode.el or python.el? -- http://mail.python.org/mailman/listinfo/python-list
Re: Java or C++?
On Apr 14, 11:44 am, [EMAIL PROTECTED] wrote: > Hello, I was hoping to get some opinions on a subject. I've been > programming Python for almost two years now. Recently I learned Perl, > but frankly I'm not very comfortable with it. Now I want to move on > two either Java or C++, but I'm not sure which. Which one do you think > is a softer transition for a Python programmer? Which one do you think > will educate me the best? The movement from knowing no programming language to knowing one is invariably a much larger one than the shift from one to two (see http://en.wikipedia.org/wiki/Diminishing_returns). That is you are likely to get much less from this shift than what you got from python two years ago. So before you make this shift do ask yourself: have you got the best of what python has to offer? I taught python in the univ for a number of years and I would always tell my students that the library reference gave a better conspectus of modern day computer science/IT than anything else I knew of. [That not too many of them listened is another matter :-) ] Then python has a lot of advanced (new) stuff: generators and generator expressions, comprehensions, lambdas and functional programming, descriptors and protocols That said you can of course choose your second language to optimize your learning (where optimize could be minimize or maximize!) One language that is promising (and under active development) is curl. (http://www.curl.com) It is targeted to be like C++ in efficiency (native compiler not VM or interpreter) like C#/Java in its OOP with gc style like Javascript in supporting dynamic rich web apps in addition to replacing HTML -- http://mail.python.org/mailman/listinfo/python-list
Re: diffing and uniqing directories
On Apr 27, 12:31 am, [EMAIL PROTECTED] wrote: > On Apr 26, 1:14 pm, "Rustom Mody" <[EMAIL PROTECTED]> wrote: > > > > > Over years Ive collected tgz's of my directories. I would like to diff > > and uniq them > > > Now I guess it would be quite simple to write a script that does a > > walk or find through a pair of directory trees, makes a SHA1 of each > > file and then sorts out the files whose SHA1s are the same/different. > > What is more difficult for me to do is to write a visual/gui tool to > > help me do this. > > > I would guess that someone in the python world must have already done > > it [The alternative is to use some of the tools that come with version > > control systems like git. But if I knew more about that option I would > > not be stuck with tgzs in the first place ;-)] > > > So if there is such software known please let me know. > > > PS Also with the spam flood that has hit the python list I dont know > > if this mail is being read at all or Ive fallen off the list! > > I don't want to give you advice; there is profit in diversity, so > telling you what I use could negatively unify the diverse group. > > In another language I know, and I pause to defer to the old and wise > on that, Visual Basic (known to make money), certain counterparts like > Visual Basic for Applications allow construction of scripts in the > owner's other suites. That is, you can write Basic snippets in Excel, > Access, and so on. That's one benefit that private ownership leaves, > but not everyone is sold on my country's currency/localcy. Perhaps > it's in the future of version control systems. Of course, > standardization of sufficiency to succeed comes from currency too: > success isn't success if it isn't current, per se. > > Do you have any interest in contributing your mind or hands to > developing a solid gui framework? Join a team. If this is an answer to my question I dont understand it! -- http://mail.python.org/mailman/listinfo/python-list
Re: diffing and uniqing directories
On Apr 27, 11:29 pm, "telus news" <[EMAIL PROTECTED]> wrote: > Just so happens that I am partially finished a gui file backup app. I have > many backup CDs and I wanted to consolidate them. You know, all image files > in one dir, all install files in another dir, etc. My app scans the input > dir tree and displays all file extensions that it finds. You can then remove > any extensions that you don't want backed-up, and you can toggle to exclude > the listed extensions. It also calculates min/max file sizes that you can > adjust. I guess what I am looking for is a merge app more than a backup app. > > Then the next page allows you to adjust the sub-dir depth with a slider, > which displays the total number of files and total amount of memory they > will take, for each sub-dir depth. You can also choose to enable versioning, > whether or not to put all files into one dir or create a dir for each file > type (extension), whether or not to actually backup the files, to write all > input pathnames and/or output pathnames to a file. Of course, it won't > backup a dir tree as a copy, it can only flatten a dir tree, That wont do for me. > so if you > backup a development source dir, all files will get put into the same dir > and that wouldn't be good. > > I've also used py2exe to make it a drag-n-drop install. What do you think? Im working (mostly) on linux -- http://mail.python.org/mailman/listinfo/python-list
Re: eval() == evil? --- How to use it safely?
On Aug 29, 4:42 am, castironpi <[EMAIL PROTECTED]> wrote: > May I suggest PyYAML? I second that. Yaml is very pythonic (being indentation based) and pyyaml is sweet. Only make sure you use safe_load not load and you will have only default construction for standard python objects -- lists, dictionaries and 'atomic' things so no arbitrary code can be executed. Someone else suggested json which is about the same as yml if there are no objects. And by using safe_load you are not using objects. -- http://mail.python.org/mailman/listinfo/python-list
Re: reifying indent and dedent into braces
On Oct 13, 12:45 pm, Steven D'Aprano wrote: > > Have you looked at the tokenize module? > > http://docs.python.org/library/tokenize.html Thanks Steven -- that was what I was looking for. -- http://mail.python.org/mailman/listinfo/python-list
Re: How to run python script in emacs
On Sep 26, 8:54 pm, devilkin wrote: > I'm just starting learning python, and coding in emacs. I usually > split emacs window into two, coding in one, and run script in the > other, which is not very convenient. anyone can help me with it? is > there any tricks like emacs short cut? > > also please recommand some emacs plug-ins for python programming, i'm > also beginner in emacs.currently i'm only using python.el. python.el comes with emacs python-mode.el comes from python https://launchpad.net/python-mode/ Because of some emacs politics the first ships with emacs although most uses prefer the second. Note 1. The key bindings are different Note 2. Does not work with python3. See my post http://groups.google.com/group/comp.lang.python/browse_thread/thread/d65139d6d1822ad4?pli=1 > Are any plugins supply code folding and autocomplete? See rope http://rope.sourceforge.net/ropemacs.html if you want but its an installation headache (requires pymacs bleeding edge version etc) I suggest you just get used to python-mode first (C-c ! and C-c C-c) and then explore these questions a bit later. > > BTW, I'm not a english native speaker, any grammer mistakes, please > correct them. :) grammer is spelt grammar :-) -- http://mail.python.org/mailman/listinfo/python-list
Re: Can I run a python program from within emacs?
On Nov 1, 7:20 pm, Robinson wrote: > I have also just started with both Aquamacs and Python so I ask for > your patience as well. > When I evaluate the buffer (C-c C-C) I don't see any response or > output from my python program. Should another buffer open > automatically? Should a terminal window open? > thanks for your patience. > Rugbeia Floreat Ubique > > > On Mar 20, 3:09 pm, jmDesktop wrote: > > > Hi, I'm trying to learn Python. I using Aquamac an emac > > > implementation with mac os x. I have a program. If I go to the > > > command prompt and type pythong myprog.py, it works. Can the > > program > > > be run from within the editor or is that not how development is > > done? There are two python modes -- python.el and python-mode.el Default with emacs is python.el, what comes from/with python is python- mode.el (needs a download and a couple of lines of setup see http://www.emacswiki.org/emacs/PythonMode). I recommend python-mode. The key-bindings are different --C-c ! to start interpreter followed by C-c C-c to exec a file. -- http://mail.python.org/mailman/listinfo/python-list
Re: About one class/function per module
On Nov 2, 3:11 am, Peng Yu wrote: > I recently asked how to support one class/function per module under > the title 'How to import only one module in a package when the package > __init__.py has already imports the modules?' I summarize my key > points below. In particular, I have to two questions: > 1. What disadvantages there are to enforce one class/function per file? > 2. How to better support one class/function per file in python? Others have told you to discard your biases. I would tell you to suspend them for a while (including our biases against your biases) and try to use emacs+ecb > > -- > I prefer organized my code one class/function per file (i.e per module > in python). I know the majority of programmers don't use this > approach. Therefore, I'm wondering what its disadvantage is. > > The advantages of one-function/class-per-file that I am aware of are > the following items (maybe incomplete). > 1. It is easy to see what functions and classes there are just by > browsing the source directory, without the need of opening the file by > an editor. Primary intention of ecb > 2. Testing code for a function/class can be organized along with the > module for the function/class, which also makes it easier to keep > track of the testing code for any function/class. > 3. It is easy to move a function/class from one package to another > by just moving files around. If an editing task is found hard it just means youve never used emacs! > 4. It is easy change variable names, etc., for a function/class by > replacement in a file without worrying accidentally change variable > names in other functions. > I have used the above approach on a C++ project. And I use vim + ctags > to navigate from a reference of a class/funciton to its definition. So > far it works fine. Should be possible to code this up in about 10 lines of emacs Simple workaround is to select the function/class and run search- replace on the selection -- http://mail.python.org/mailman/listinfo/python-list
Re: Web development with Python 3.1
On Oct 30, 6:23 pm, Dotan Cohen wrote: > The point is that I want to use only _Python_ features, not > Django/Mako/whatever features. Pure python has a builtin templating system -- its called % See http://simonwillison.net/2003/Jul/28/simpleTemplates/ -- http://mail.python.org/mailman/listinfo/python-list
Re: IDE+hg
On Nov 24, 8:13 pm, Richard Riley wrote: > Gerhard Häring writes: > > Rhodri James wrote: > >> On Mon, 23 Nov 2009 19:20:27 -, NiklasRTZ wrote: > > >>> Dear experts, > >>> Since no py IDE I found has easy hg access. IDEs PIDA and Eric claim > >>> Mercurial support not found i.e. buttons to clone, commit and push to > >>> repositories to define dev env dvcs, editor and deployment all in 1. > > >> I don't really understand this urge to cram everything into a single > >> program, since that inevitably leads to compromises that will > >> compromise > > Huh? Cram what? Nothing is crammed into anything. The IDE/Editor is > merely programmed to hook into the external tools > > >> just how much of Mercurial's useful and interesting functionality you > >> can get at. Still, if you really must, Emacs (and presumably vim) seems > >> to be capable of working with most source control systems. > > > I prefer the commandline tools, too. > > > FWIW, Eclipse supports Mercurial through > >http://www.vectrace.com/mercurialeclipse/ > > > -- Gerhard > > Why would you prefer the command line tools in a shell when the same > tools can be used in a way which makes navigating the output so much > easier? It strikes me as a kind of intransigence. it's a common > misconception that IDEs use their own tools all the time. They > don't. They integrate the very same tools. e.g Why the hell would I drop > to a command line to diff a file with a back version in GIT when I can > do the same in the buffer in emacs with a single hot key? Why would I > pipe the output of compile into a file then open that file when a single > hot key can fire off the SAME compiler and then list the errors in an > emacs buffer and another hot key can take me directly to the source > lines in question? Living in the past has its mements, but really. > > e.g I have pylint working live in python buffers. Big time > saver. Similar with C. I sometimes think that the amount of time I spend tweaking emacs to save my time is more than the time I spend on anything else :-) But more seriously: I tried to use emacs with git recently -- it was a sorry experience. The git.el that comes with git is broken (on windows) vc was too old for git like systems dvc is a joke (its supposedly generic for all Distributed Version Systems -- but everything is couched in terms of tla. TLA! For heavens sake! magit would not run on windows and to use egg http://github.com/bogolisk/egg I must read magit docs. Finally I decided to stay with what Ive used for the last 25 years -- the shell -- http://mail.python.org/mailman/listinfo/python-list
Re: What was your strategy?
Jorge Biquez writes: > I was wondering if you can share what was the strategy you followed to > master Python (Yes I know I have to work hard study and practice a lot). One of the basic mistakes that folks (kids?) studying a language do is to study *only* the language. I guess the mistake happens more in the Java, VB type languages than in python but the mistake is pervasive nevertheless. (Its particularly dangerous with C++ which you can study without mastering for a lifetime) Python is obviously simpler/cleaner etc but still the mistake persists of studying past the point of diminishing returns. Specifically, an intelligent person who has a background of other languages can get the minimal,basic hang in a a day (not so intelligent and inexperienced may be a week or two). After that you need to study OTHER things. Here is such a list 1. "python" 2. IDE (emacs+python-mode in my case, but whatever you use, learn to use it) - debugger - introspection - ipython looks promising 3. CS - algorithms - data structures - 'theory:' FSM, complexity, computability limits, O notation etc 4. Operating Systems How python fits into the OS you are using 5. Paradigms - scripting - functional - oo 6. 'Advanced' Stuff - TDD - Profiling - C interfacing ... The difficult part is studying this stuff independent of python and then making the bridge. eg. 75% of (typical) data-structure books deal with things like 'linked-lists' -- useless in python-- but the remaining 25% you need. -- http://mail.python.org/mailman/listinfo/python-list
Re: TDD in python
On Nov 28, 7:52 pm, Stefan Behnel wrote: > Rustom Mody, 28.11.2010 11:58: > > > Does anyone know of something like this for python? > > >http://www.vimeo.com/13240481 > > The page seems to require a recent version of the Flash player. Could you > describe what exactly you are looking for? > > Stefan Well most modern languages have TDD frameworks. However TDD is learnt by doing and not from books (like swimming/ cycling). This screencast gives a detailed demo of *doing it* in eclipse/C++ I was hoping for something similar for python -- http://mail.python.org/mailman/listinfo/python-list
Re: TDD in python
On Nov 29, 4:59 pm, André wrote: > On Nov 29, 7:31 am, rustom wrote: > > > > > On Nov 28, 7:52 pm, Stefan Behnel wrote: > > > > Rustom Mody, 28.11.2010 11:58: > > > > > Does anyone know of something like this for python? > > > > >http://www.vimeo.com/13240481 > > > > The page seems to require a recent version of the Flash player. Could you > > > describe what exactly you are looking for? > > > > Stefan > > > Well most modern languages have TDD frameworks. > > However TDD is learnt by doing and not from books (like swimming/ > > cycling). > > This screencast gives a detailed demo of *doing it* in eclipse/C++ > > I was hoping for something similar for python > > Go to showmedo.com and do a search for "python tdd"; you'll find many > such screencasts. > > André Looking around I found this: http://bytes.com/topic/python/answers/43330-unittest-vs-py-test where Raymond Hettinger no less says quite unequivocally that he prefers test.py to builtin unittest because it is not so heavy-weight Is this the general consensus nowadays among pythonistas? [Note I tend to agree but Ive no experience so asking] -- http://mail.python.org/mailman/listinfo/python-list
Re: Good books in computer science?
On Jun 14, 10:38 am, koranthala wrote: > Software Tools - Seems to be a classic - not sure whether I will buy. In that vein but more modern -- Art of Unix Programming by Eric Raymond (available online) Some of my old favorites: Intro to functional programming by Bird and Wadler TAOCP slightly more modernized more heady and less programmer oriented -- Concrete Mathematics by Knuth and... Science of Programming by David Gries; again more modernized to Logical Approach to Discrete Mathematics Bentley's Wriiting Efficient Programs and Programming pearls Dijkstra's writings -- http://www.cs.utexas.edu/~EWD/transcriptions/EWD10xx/EWD1036.html -- are not kind to software engineers [His defn of SE -- How to program if you cannot]. Seemingly irrelevant -- Good programmers are very good with their editors -- someone mentioned yegge. Read him for inspiration on emacs. Of course you can use something else but its important to get good at it. -- http://mail.python.org/mailman/listinfo/python-list
Re: Good books in computer science?
On Jun 14, 6:04 pm, Steven D'Aprano wrote: > I think there are about 100 million VB code-monkeys who prove that theory > wrong. > > Seriously, and without denigrating any specific language, you can program by > (almost) mindlessly following a fixed number of recipes and patterns. This > will get the job done, but it won't make you a good programmer. When Dijkstra was asked what next programming language to learn he would typically recommend Latin :-) > Really? So you don't think that the best way to get good at something > is to practice? I think I'm paraphrasing Richard Feynman here, but the > only way to truly understand something is to do it. > Obviously a bit of guided learning is a major boon, but you can't be practice. For every one Horowitz there are a thousand wannbes thumping on the piano trying to become Horowitz. The traction that practice gives is maximal only in the beginning. -- http://mail.python.org/mailman/listinfo/python-list
Re: Good books in computer science?
This thread has thrown up some interesting suggestions but they all seem to fall into one of two categories: - the high-ground: Dijkstra, Knuth etc - the low-ground: write (any-which-how) a lot of code And both these 'grounds' seem to cause more argument and less suggestions for good books. Let me therefore try to find a middle-ground and make a suggestion that I used to make to my students when I taught them programming: Read the Python Manual -- specifically the library. It contains a fairly good conspectus of modern day IT/CS. Some examples of what I mean: Want to study TDD? Read unittest and doctest and then go on to reading (and practising) Kent Beck etc Want to get into unix system programming? Nothing like playing around with os.path and stat before burining your hands with C. Networking protocols? smtplib, urllib, ftplib etc Low level networking? socket, select etc Algorithms? Good to get your feet on the ground with timeit -- http://mail.python.org/mailman/listinfo/python-list
Re: "Strong typing vs. strong testing"
On Sep 29, 5:32 am, Chris Rebert wrote: > On Tue, Sep 28, 2010 at 2:55 AM, Malcolm McLean > > > > wrote: > > On Sep 27, 9:29 pm, [email protected] (Pascal J. Bourguignon) > > wrote: > >> On the other hand, with the dynamic typing mindset, you might even wrap > >> your values (of whatever numerical type) in a symbolic expression > >> mentionning the unit and perhaps other meta data, so that when the other > >> module receives it, it may notice (dynamically) that two values are not > >> of the same unit, but if compatible, it could (dynamically) convert into > >> the expected unit. Mission saved! > > > I'd like to design a language like this. If you add a quantity in > > inches to a quantity in centimetres you get a quantity in (say) > > metres. If you multiply them together you get an area, if you divide > > them you get a dimeionless scalar. If you divide a quantity in metres > > by a quantity in seconds you get a velocity, if you try to subtract > > them you get an error. > > Sounds just like > Frink:http://futureboy.us/frinkdocs/http://en.wikipedia.org/wiki/Frink A currently developed language with units is curl: see http://developers.curl.com/userdocs/docs/en/dguide/quantities-basic.html -- http://mail.python.org/mailman/listinfo/python-list
Re: "Strong typing vs. strong testing"
Some points that seem to be missed (or Ive missed them?) 1. A dichotomy is being made between 'static' languages like C and 'dynamic' languages like python/lisp. This dichotomy was valid 30 years ago, not today. In Haskell for example - static checking is stronger than in C/C++ -- its very hard if not impossible to core dump haskell except through memory exhaustion - dynamic-ness is almost that of python/lisp -- on can write significant haskell programs without type-declaring a single variable/ function Much more mainstream, C# is almost as 'managed' as dynamic languages and has efficiency comparable to C. 2. The dichotomy above misses a more pervasive dichotomy -- hardware vs software -- as real today as 30 years ago. To see this let us lift the discussion from that of *languages* C vs Python/Lisp to philosophies: -- C-philosophy: the purpose of type-checking is to maximize (runtime) efficiency -- Lisp-philosophy: the purpose of type-checking is zero-errors (aka seg-faults) via continuous checks at all levels. If one is honest (and not polemical :-) ) it would admitted that both sides are needed in different contexts. Now Dijkstra pointed (40 years ago) in Discipline of Programming that this unfortunate dilemma arises due to lack of hardware support. I am unable to reproduce the elegance and succinctness of his language but the argument is as follows: Let us say that for a typical profile of a computer we have for every one instruction of the pathological one typified by the maximum function, a trillion 'normal' instructions. This is what he calls a very-skew test -- an if-then-else that checks this would go the if-way way one trillion times for one else-way. It is natural for a programmer to feel the pinch of these trillion checks and (be inclined to) throw them away. If however the check was put into hardware there would be no such dilemma. If every arithmetic operation was always checked for overflow *by hardware* even languages committed to efficiency like C could trap on errors with no extra cost. Likewise Lisp/python-like languages could easily be made more efficient. The diff arises from the fact that software costs per use whereas hardware costs per installation -- a transistor, unlike an if, does not cost any more if its used once or a trillion times. In short the problem is not C vs Lisp/Python but architectures like Intel wherein: 1. an overflow bit harmlessly set by a compare operation is indistinguishable from one set by a signed arithmetic operation -- almost certainly a problem 2. An into instruction (interrupt on overflow) must be inserted into the software stream rather than raised as a hardware interrupt. -- http://mail.python.org/mailman/listinfo/python-list
Re: "Strong typing vs. strong testing"
On Oct 1, 7:17 pm, Rui Maciel wrote: > a) no language is inherently more or less efficient than any other language. > The efficiency > aspect is only related to how those languages are implemented (i.e., the > investments made in > optimizing the compilers/interpreters) I used to believe the same. But if you see Richard Bird's paper: More haste less speed http://www.comlab.ox.ac.uk/people/richard.bird/online/BirdJonesDeMoor1997More.pdf maybe you would rethink this position? -- http://mail.python.org/mailman/listinfo/python-list
Re: Compare source code
Sigh! How flame-wars tend to lose the original question: On Oct 31, 5:02 pm, jf wrote: > Hi, > > I've a project with tabs and spaces mixed (yes I know it's bad). Do python aficionados want to suggest that mixing spaces and tabs is a 'good thing'? -- http://mail.python.org/mailman/listinfo/python-list
Re: Man pages and info pages
On Nov 3, 3:11 pm, Daniel da Silva wrote: > Guys, this really has nothing to do with python. ?? python docs have nothing to do with python?? python docs by default on linux are read with info and many seem to find info unpleasant to use. Myself an old emacs user and cant say info helps me as much as google. However comparing info and man is also a bit strange. The printed python docs come to several thousand pages. Do we want them to be 1 manpage? a hundred? a thousand? -- http://mail.python.org/mailman/listinfo/python-list
Re: Compare source code
On Nov 5, 8:25 am, Terry Reedy wrote: > On 11/4/2010 10:47 PM, Rustom Mody wrote: > > > As far as I am concerned python would not be python if its > > indentation=structure went. However the original question -- mixing > > tabs and spaces is bad -- has got lost in the flames. Do the most > > die-hard python fanboys deny this? > > Of course not. Not mixing tabs and spaces has been the recommendation > for perhaps a decade. > > > And if not is it asking too much (say in python3) that mixing tabs and > > spaces > > > be flagged as an error or at least warning? > > Making all mixture an error was considered but rejected as causing too > much gratuitous breakage. One reason: you cut code from some source with > the 'other' style and paste into code with 'your' style. Should you be > *forced* (rather than merely advised) to convert before running the > result even once. Guido decided that there was enough breakage from > important things like unicode text and all new-style classes. That means that obvious and easily repairable-with-trivial-tools breakage is being traded for more insidious breakage > > On the other hand, someone said that ambiguous mixtures now are prohibited. > Not sure I understand the issues here. -- http://mail.python.org/mailman/listinfo/python-list
Re: Why "flat is better than nested"?
On Oct 26, 12:11 am, kj wrote: > In Steve Holden > writes: > > > > >On 10/25/2010 10:47 AM, rantingrick wrote: > >> On Oct 25, 5:07 am, kj wrote: > >>> In "The Zen of Python", one of the "maxims" is "flat is better than > >>> nested"? Why? Can anyone give me a concrete example that illustrates > >>> this point? > > >> Simple. This commandment (endowed by the anointed one, GvR) is > >> directed directly at lisp and those filthy lispers. If you don't know > >> what lisp is then Google it. Then try to program with it for one hour. > >> Very soon after your head will explode from the nested bracket plague > >> and then you shall be enlightened! > > >And everyone taking the Zen too seriously should remember that it was > >written by Tim Peters one night during the commercial breaks between > >rounds of wrestling on television. So while it can give useful guidance, > >it's nether prescriptive nor a bible ... > > Well, it's pretty *enshrined*, wouldn't you say? After all, it is > part of the standard distribution, has an easy-to-remember invocation, > etc. *Someone* must have taken it seriously enough to go through > all this bother. If it is as trivial as you suggest (and for all > I know you're absolutely right), then let's knock it off its pedestal > once and for all, and remove it from the standard distribution. > > ~kj If you take zen seriously you dont get it If you dont take zen seriously you dont get it That -- seriously -- is zen -- http://mail.python.org/mailman/listinfo/python-list
Re: Why "flat is better than nested"?
On Nov 6, 2:52 pm, Peter Otten <[email protected]> wrote: > rustom wrote: > > If you take zen seriously you dont get it > > If you dont take zen seriously you dont get it > > You forgot: > > If you explain zen you don't get it I guess different communities have different settings for 'explanation- toleration' (as also 'seriousness') eg. Classical zen: If you the Buddha on the road kill him! Now :s/the Buddha/Jesus Christ/ and it suddenly seems more offensive -- not because the Buddha and Jesus Christ are all that different but because the respective communities have different seriousness defaults. And as for another teacher whose sphere of influence was a few hundred km from Jesus' I am going to be even more careful because the seriousness-defaults are set lower still... -- http://mail.python.org/mailman/listinfo/python-list
Re: Compare source code
On Nov 6, 5:21 pm, [email protected] (Mark Wooding) wrote: > Rustom Mody writes: > > As for tools' brokeness regarding spaces/tabs/indentation heres a > > thread on the emacs list wherein emacs dev Stefan Monnier admits to > > the fact that emacs' handling in this regard is not perfect. > > >http://groups.google.com/group/gnu.emacs.help/browse_thread/thread/1b... > > You've misunderstood. That discussion is about configuring Emacs to not > do automatic indentation when the `tab' key is pressed or when > language-specific punctuation is entered. It has very little to do with > tab characters in files. The OP there clearly says he needs help in dealing consistently with 'tabbed' files. Mixing up these 2 issues (actually 3) is the 'Eternal Holy War' that Jamie Zawinski talks about here http://www.jwz.org/doc/tabs-vs-spaces.html Note: I am in no way supporting the demand that python should suddenly get 'braced' beacuse: a. this would do too much violence to the essential -- 'executable- pseudo-code' -- spirit of the language b. Anyway for me personally python and haskell are two of my favorites and one their common features is this: indentation == program structure I am only pointing to the fact that one of the widely used and super- powerful editors is less than perfect in this regard -- http://mail.python.org/mailman/listinfo/python-list
Re: python test frameworks
On Nov 7, 7:09 pm, Kev Dwyer wrote: > On Sun, 07 Nov 2010 10:56:46 +0530, Rustom Mody wrote: > > There are a large number of test frameworks in/for python. Apart from > > what comes builtin with python there seems to be nose, staf, qmtest etc > > etc. > > > Is there any central place where these are listed with short > > descriptions? 'Test framework' means widely different things in > > different contexts. Any explanations/tutorials around? > > > [Disclaimer: I was educated a couple of decades before the TDD rage] > > Hello, > > You could start withhttp://pycheesecake.org/wiki/PythonTestingToolsTaxonomy > > Kev Thanks -- that looks like a comprehensive resource. But it does not have staf http://staf.sourceforge.net/current/STAFPython.htm. Is that merely an item missing or a category? -- http://mail.python.org/mailman/listinfo/python-list
Illegal suggestions on python list
On Thu, Jul 4, 2013 at 9:16 PM, Steven D'Aprano < [email protected]> wrote: > On Thu, 04 Jul 2013 07:02:26 -0700, rusi wrote: > > > On Thursday, July 4, 2013 7:03:19 PM UTC+5:30, Steve Simmons wrote: > >> Boy oh boy! You really are a slow learner Nicos. You have just offered > >> to commit a crime and to include dozens of others in that crime ON A > >> PUBLIC FORUM. Please think before you post. > > > > For the record Steve, let me say, I find Robert Kern's objection barely > > sufficient. > > > > And yours less than that. > > > > Note that you are not objecting to the crime > > Which crime is that? Presumably you mean an actual criminal felony, not a > mere civil offence. Under which jurisdiction? > > > > but to the public > > expression of it. Just look at your objection from the angle of a police > > officer, and you will see that it can certainly be construed as > > abetment/collusion > > If piracy is a crime, and not just a civil offence, then surely so is > libel. You have just accused Steve Simmons of collusion in a felony, > based on absolutely no evidence at all. That's as clear a case of libel > as I've ever seen. Although I'm not sure that the damages should be > terribly high -- there's little evidence that anyone treats your > ridiculously exaggerated claims about other people's supposed crimes as > anything but hot air. > > But, putting damages aside, according to what passes for the reasoning > that you have demonstrated here, your committing libel would make you > equally a "petty criminal" as Nikos. > > > Speaking of petty, this whole witch-hunt is getting ridiculous. Don't you > have something more productive to do? Accusing people of colluding in > crimes because they fail to be sufficiently zealous in "objecting to the > crime" is nuts. > > > -- > Steven > -- > http://mail.python.org/mailman/listinfo/python-list > You've got your OO class hierarchy mixed up and then imposing that on me. See http://www.nolo.com/legal-encyclopedia/crimes-felonies-misdemeanors-infractions-classification-33814.html I did not say or suggest felony. Maybe misdemeanor or infarction. Dunno which. IANAL... -- http://mail.python.org/mailman/listinfo/python-list
Re: Important features for editors
On Sat, Jul 6, 2013 at 4:36 AM, Cameron Simpson wrote: > While I started with vi just slightly before encountering emacs > (mid-to-late 1980s, both), my main trouble with choosing emacs was > the heavy use of control keys. Vi's modal nature means that in > "edit" mode, all the keystrokes are available as edit controls. > Emacs' modeless nature means that all the edit controls must be > control-this and meta/escape-that. > > For this reason, I often expand EMACS as Escape Meta Alt Control Shift. > > Yes... The fact that rms has crippling RSI should indicate that emacs' ergonomics is not right. > I'm a vi user. Once I mastered "hit ESC by reflex when you pause > typing an insert" I was never confused above which mode I was in. > > And now my fingers know vi. > > Yes... vi: (n) A program that has two modes, one in which it beeps and the other in which it corrupts your file :-) > Cheers, > -- > Cameron Simpson > > A novice of the temple once approached the Chief Priest with a question. > > "Master, does Emacs have the Buddha nature?" the novice asked. > > The Chief Priest had been in the temple for many years and could be > relied > upon to know these things. He thought for several minutes before > replying. > > "I don't see why not. It's got bloody well everything else." > > With that, the Chief Priest went to lunch. The novice suddenly achieved > enlightenment, several years later. > > Commentary: > > His Master is kind, > Answering his FAQ quickly, > With thought and sarcasm. > > Heard somewhere: Emacs is my operating system and linux is its device driver. No I dont belong to that camp -- Actually I am quite dissatisfied with emacs nowadays... Keep trying eclipse and getting repulsed by the gorilla. Philosophy being this: What functional programming is to program-semantics, fast-branching (as in git) is to program-source[1]. To complete the trinity, one needs semi-automated refactoring. The first I can do in my sleep; the second still noob-status, the third yet to start! [1] Not necessarily source-code See http://blog.vctr.me/posts/why-you-should-learn-git.html -- http://mail.python.org/mailman/listinfo/python-list
semi-programmer-ish envs/apps using python
Some systems use python as a glue to make environments which are used by professionals that are not primarily programmers. Some egs: Scientific prog with Scipy+matplotlib Data analysis with pandas Visual arts with processing (Is pyprocessing stable enough?) Linguistics with nltk Is there such a list somewhere? -- http://mail.python.org/mailman/listinfo/python-list
Re: Important features for editors
On Sat, Jul 6, 2013 at 12:22 PM, Eric S. Johansson wrote: > ** > On Fri, 05 Jul 2013 23:13:24 -0400, Rustom Mody > wrote: > > Yes... > The fact that rms has crippling RSI should indicate that emacs' ergonomics > is not right. > > > > As someone crippled by Emacs ( actual cause not known), I should also > point out that RMS, instead of doing the responsible thing and using speech > recognition software, burns the hands of other human beings by using them > as biological speech recognition units. > > Hope youve seen this http://www.cs.princeton.edu/~arora/RSI.html -- http://mail.python.org/mailman/listinfo/python-list
Re: Keyboard Layout: Dvorak vs Colemak: is it Worthwhile to Improve the Dvorak Layout?
On Jun 13, 6:19 pm, Steven D'Aprano wrote: > Even if we accept that Dvorak is an optimization, it's a micro- > optimization. +1 Dvorak -- like qwerty and any other keyboard layout -- assumes the computer is a typewriter. This means in effect at least two constraints, necessary for the typewriter but not for the computer: a. The typist can type only 1 key at a time b. One (key)stroke generates exactly 1 letter Exceptions to are Shift (Ctrl) etc but clearly in running use they are the exception not the rule. > Where speed really is vital, such as for court stenographers, special > mechanical > shorthand machines such as stenotypes are used, costing thousands of dollars > but allowing > the typist to reach speeds of over 300 wpm. Yes, instruments like stenotypes speed up typing by unassuming Likewise pianists can be said (and seen) to do more at the piano than typists at a computer because chords are part of the 'allowed language'. Assumption likewise is unnecessarily restrictive on a computer. Think of all the 'abbrev/snippet/shortform/template' systems like yasnippet, textmate-snippets, emacs/vi abbrevs etc. For ordinary English there are things like keyscript http://www.freewebs.com/cassyjanek For example the most common words (estimated to be around 40% of English) are shortformed as: b = but c = with d = had e = this f = of g = that h = the j = which n = and ...etc etc upto z = was then common phrases able to = cb had been = dn do not = dx did not = ex does not = dsx etc Clearly, for programmers this is unlikely to be much use -- programming languages are not English. But but it is certainly an open question whether if the repeating patterns in programming languages are captured into some system, the resulting benefit would be a mere micro-optimization or something more significant. I have seen some good programmers swear by emacs-yasnippets, textmate-snippets etc. -- http://mail.python.org/mailman/listinfo/python-list
Re: regex question
MRAB wrote: > findall returns a list of tuples (what the groups captured) if there is more than 1 group, > or a list of strings (what the group captured) if there is 1 group, or a list of > strings (what the regex matched) if there are no groups. Thanks. It would be good to put this in the manual dont you think? Also, the manual says in the 'match' section "Note If you want to locate a match anywhere in *string*, use search()instead." to guard against users using match when they should be using search. Likewise it would be helpful if the manual also said (in the match,search sections) "If more than one match/search is required use findall" -- http://mail.python.org/mailman/listinfo/python-list
Re: Function "modes" vs. separate functions (was: PyWart: os.path needs immediate attention!)
Ben Finney said: > But this is all getting rather generic and abstract. What specific > real-world examples do you have in mind? regex match vs regex search? -- http://mail.python.org/mailman/listinfo/python-list
Re: Deeply nested dictionaries - should I look into a database or am I just doing it wrong?
I use pyyaml for such. http://yaml.org/ The builtin json support http://docs.python.org/library/json.html is a bit weaker but has the advantage of no extra install -- http://mail.python.org/mailman/listinfo/python-list
Re: Non Programming in python
On Wed, May 11, 2011 at 5:57 PM, Calvin Spealman wrote: > If this is the "non-programming side of python" then maybe some of us have > a lacking definition of what "programming" is. My mechanic stilll has to > check the tire pressure and I need to update the version number in PyPI. > O well you dont like the term 'non-programming'? As I said neither do I... On May 10, 2011 12:46 PM, "rusi" wrote: > > Sorry for a silly subject change: A better one will be welcome -- cant > think of a name myself. > > Maybe another way of describing this list may be 1. Programming from 'inside' or 'under' python and 2. The rest of it which is outside/surrounding the python interpreter Because 1 is mostly called 'programming' and 2 has no name, 2 gets neglected more than it should. Or take any python book and browse the contents. What will you find? Python data structures, Python control structures, OOP in python, advanced function topics, scopes, modules, exceptions etc -- almost all the 'inside' stuff well organized, with the outside stuff strewn around in hard-to-find corners of the index (if at all). Does that reflect the reality of python's actual learning curve? -- http://mail.python.org/mailman/listinfo/python-list
Re: A question on modification of a list via a function invocation
On Monday, September 4, 2017 at 7:50:22 AM UTC+5:30, Chris Angelico wrote: > On Mon, Sep 4, 2017 at 12:05 PM, Steve D'Aprano wrote: > > On Mon, 4 Sep 2017 04:15 am, Stephan Houben wrote: > > > >> Needless to say, according to the definition in Plotkin's paper, Python > >> is "call-by-value". > > > > According to Plotkin's definition, when you pass a value like a 100MB > > string: > > > > "This is a long string of text..." # continues on for millions more > > characters > > > > does the interpreter make a copy of the 100MB string? > > > > If not, then it isn't pass (call) by value. > > This is another proof that you can't divide everything into "pass by > value" vs "pass by reference", unless you mess around with "passing a > reference by value" or other shenanigans. In C, a string is not an > entity; it's simply an array of characters. Arrays are never passed by > value; yet everything in C is passed by value. So you pass a > pointer... by value. > > What would you define LISP's semantics as? Pass by value? Pass by > reference? Pass by name? Pass by immutability? Pass the salt? “Pass the logic" “Oops…” “You slob! You’ve messed my consistency-carpet." Earlier Ben Bacarisse wrote: > The core of the idea is actually what the value-set of Python programs is -- Yes! That!! Parameter-passing models and nomenclature is really a red-herring Its the “== is id” mess that is at the base of the mess: Simply put: pythonistas have no coherent/consistent sense of what python values are. And the endless parameter-passing-nomenclature arguments are just the fallout of that. Maybe that’s what Ben means by?? > the passing by value just drops out of that. -- https://mail.python.org/mailman/listinfo/python-list
Re: meaning of [ ]
On Sunday, September 3, 2017 at 5:10:13 PM UTC+5:30, Rick Johnson wrote:
> Andrej Viktorovich wrote:
> > I suppose p becomes array of strings but what [] means in this statement?
>
> Generally, it's an inline form of writing a loop that returns a list. There
> are other types as well.
Tsk tsk the confusioning continues
Rewrite
[p for p in sys.path]
as
[p | p ∈ sys.path]
Is that clearer?
And then as
{p | p ∈ sys.path}
And refresh the idea of set-builder notation
http://www.mathwords.com/s/set_builder_notation.htm
Note the the clunky ascii-fication of (most) programming languages (including
python)
is a minor distraction
The bigger and more real issue is that sets and lists are similar and different
Sets have no order, lists are ordered
As Peter pointed out this is a no-op
ie
[p for p in sys.path]
could be written as
list(sys.path)
[Not sure why he didnt say just sys.path]
Anyway this is a good example to distinguish
[p for p in sys.path]
from
{p for p in sys.path}
Both work in python
But the second is probably not correct because path-searching is order dependent
--
https://mail.python.org/mailman/listinfo/python-list
Re: A question on modification of a list via a function invocation
On Monday, September 4, 2017 at 1:46:55 PM UTC+5:30, Gregory Ewing wrote: > Stefan Ram wrote: > > JavaScript and Python do not have references as values > > Yes, they do. The difference is that they don't have any > way of *not* having references as values, so there's less > need to use the word explicitly in that way -- most of > the time it's just understood. Well then why these long threads that get nowhere 😎? > Nevertheless, terms such > as "object reference" and "reference to an object" do > get used in relation to Python when clarity is needed. Its because reference (or pointer or …) is central to python's semantics that we need to use them to talk/explain/understand. Its because pointers have been de-first-classed (from C say, as a starting point) that the disagreements arise: - One bunch feel that since they've been de-first-classed they've been removed And could/should not be mentioned - The others feel that since the removal is ½-assed we need to talk of them anyway. All thats gone is the '*' which has become implicit from C's explicit -- https://mail.python.org/mailman/listinfo/python-list
Re: A question on modification of a list via a function invocation
On Monday, September 4, 2017 at 3:35:54 PM UTC+5:30, Antoon Pardon wrote: > Op 04-09-17 om 00:44 schreef Dennis Lee Bieber: > > And is a limited theoretical study, heavy in mathematics and light in > > implementation. > > > > Programming Languages: Design and Implementation (Terrence W Pratt, > > 1975, Prentice-Hall) has a whole section (6-9 Subprograms with Parameters: > > Parameter Transmission Techniques)... > > > > """ > > Basic parameter Transmission Techniques > > > > Transmission by Value: ... the actual parameter is evaluated at the point > > of call. The /values/ of the actual parameter is then transmitted to the > > subprogram and becomes the initial value associated with the corresponding > > formal parameter. ... > > > > Transmission by Reference (Location or Simple Name): In transmission by > > reference a pointer is transmitted, usually a pointer to a data location > > containing the value. ... Any assignment to Y in SUB will change the value > > of X back in the calling program. > > IMO that depends on the semantics of the assignment statement. In an > environment > where an assignment copies the value into the object the variable points to, > this > is correct. However if assignment provides a new object that is now bound to > the > variable, it is incorrect. > > The diagram below tries to illustrate the two different assignment semantics: > > BEFORE > +-+ +-+ > | | | | > | 5 | | 7 | > | | | | > +-+ +-+ > > ^ ^ > | | > > > > x = y > AFTER > > C style| Python style >| > +-+ +-+ | +-+ > | | | | | | | > | 7 | | 7 | | | 7 | > | | | | |---> | | > +-+ +-+ | / +-+ > / > ^ ^ / ^ > | | /| > That's fine as far as it goes But then you have people (Steven above) who feel that python passing has no exceptions (in parameter passing) Does a poor job AFAIAC of explaining the difference between foo and bar in foll >>> def foo(x): x += 2 >>> def bar(x): x.append(2) >>> a=10 >>> b=[10] >>> foo(a) >>> a 10 >>> bar(b) >>> b [10, 2] >>> -- https://mail.python.org/mailman/listinfo/python-list
Re: meaning of [ ]
On Monday, September 4, 2017 at 6:36:11 PM UTC+5:30, Ben Bacarisse wrote:
> Rustom Mody writes:
>
> > On Sunday, September 3, 2017 at 5:10:13 PM UTC+5:30, Rick Johnson wrote:
> >> Andrej Viktorovich wrote:
> >> > I suppose p becomes array of strings but what [] means in this statement?
> >>
> >> Generally, it's an inline form of writing a loop that returns a
> >> list. There are other types as well.
> >
> > Tsk tsk the confusioning continues
> >
> > Rewrite
> > [p for p in sys.path]
> > as
> > [p | p ∈ sys.path]
> >
> > Is that clearer?
> >
> > And then as
> >
> > {p | p ∈ sys.path}
> > And refresh the idea of set-builder notation
> > http://www.mathwords.com/s/set_builder_notation.htm
>
> But [p for p in sys.path] is a list and "set-builder" notation is used
> for sets. Order is crucial for sys.path. You say exactly that below so
> I don't see how referring to sets helps anyone understand lists.
Clearly if the question was of *sets* vs *lists* the distinction is at least as
crucial, maybe even more so than the similarity.
The OP-question here however is one about comprehensions and it appears without
the questioner realizing that — as Peter's answer showed
See the very first line of this:
https://en.wikipedia.org/wiki/List_comprehension
“List comprehension follows the form of the mathematical set-builder notation
(set comprehension)”
ie its both historically and structurally linked
IOW emphasising the incidental sequential nature of the computation
at the cost of the fundamental structure-preserving nature of the concept
>
>
> > As Peter pointed out this is a no-op
> > ie
> > [p for p in sys.path]
> >
> > could be written as
> > list(sys.path)
>
> Both make a copy -- that's not a no-op. It may be a very-little-op but
> not nothing.
Its important…
- whether the machine stack grows up or down
- whether the bytes are ordered little-endian or big-endian
- whether IO is polled or interrupt driven
- whether IO ports are memory-mapped or in separate IO space
And much else
Yet for most people doing most things today in most languages,
these questions are irrelevated
The question of copying is likewise, from a certain point of view, irrelevant.
Of course the further context of the OP may have a mutation on the list
And if he does end up changing sys.path, and not intending it, that would be
a source of nasty bugs for sure
But why assume all that when he does not (yet) know what it is he is writing
More importantly thinks its a *command* when its actually an *expression*
etc? (IMHO an unfortunate consequence of the confusing overloading of the 'for'
keyword)
>
> > [Not sure why he didnt say just sys.path]
>
> Because he wanted code equivalent to [p for p in sys.path].
>
> > Anyway this is a good example to distinguish
> >
> > [p for p in sys.path]
> > from
> > {p for p in sys.path}
> >
> > Both work in python
> > But the second is probably not correct because path-searching is order
> > dependent
>
> Right. So i'm puzzled why you suggest that [p for p in sys.path] should
> be understood by reading about set-builder notation.
Since "-builder" and "-comprehension" (in this context) are synonymous??
[ https://en.wikipedia.org/wiki/Set-builder_notation ]
And I am ready to make a small wager
- that the OP knows of these
- with math-hat on
- And is simply confused by the clunky ASCII syntax
--
https://mail.python.org/mailman/listinfo/python-list
Re: A question on modification of a list via a function invocation
On Monday, September 4, 2017 at 5:58:18 PM UTC+5:30, ROGER GRAYDON CHRISTMAN wrote: > >Does a poor job AFAIAC of explaining the difference between foo and bar in > foll def foo(x): x += 2 > def bar(x): x.append(2) > a=10 > b=[10] > foo(a) > a > >10 > bar(b) > b > >[10, 2] > > Or with just one function: >>> def baz(x,y): > x += y > >>> a = 10 > >>> b = [10] > >>> baz(a,a) > >>> a > 10 > >>> baz(b,b) > >>> b[10, 10] Ha Ha! Lovely [I was about to ask Chris if he is being serious about relating this to the presence of '=' ] However if you desugar the += into __iadd__ then someone may argue the presence of the = is an optical illusion -- https://mail.python.org/mailman/listinfo/python-list
Re: meaning of [ ]
On Monday, September 4, 2017 at 7:57:23 PM UTC+5:30, Rustom Mody wrote:
> On Monday, September 4, 2017 at 6:36:11 PM UTC+5:30, Ben Bacarisse wrote:
> > But [p for p in sys.path] is a list and "set-builder" notation is used
> > for sets. Order is crucial for sys.path. You say exactly that below so
> > I don't see how referring to sets helps anyone understand lists.
>
> Clearly if the question was of *sets* vs *lists* the distinction is at least
> as
> crucial, maybe even more so than the similarity.
> The OP-question here however is one about comprehensions and it appears
> without
> the questioner realizing that — as Peter's answer showed
>
> See the very first line of this:
> https://en.wikipedia.org/wiki/List_comprehension
> “List comprehension follows the form of the mathematical set-builder notation
> (set comprehension)”
>
> ie its both historically and structurally linked
> IOW emphasising the incidental sequential nature of the computation
> at the cost of the fundamental structure-preserving nature of the concept
Incomplete; I meant to say:
ie its both historically and structurally linked.
IOW emphasising the incidental sequential nature of the computation
at the cost of the fundamental structure-preserving nature of the concept
seems to be some ()*&^$W# behavior on the part of people instructing python
The essential meaning of comprehensions is the following diagrams
not the for-loop implementation
If l is
[x₁, x₂,… xₙ ]
[f(x) for x in l]
means this picture:
[x₁, x₂,…xₙ ]
↓ ↓… ↓
[f(x₁), f(x₂),… f(xₙ)]
Likewise
If s is
{x₁, x₂,… xₙ}
{f(x) for x in s}
means this picture:
{x₁, x₂, … xₙ}
↓ ↓ … ↓
{f(x₁), f(x₂),… f(xₙ)}
--
https://mail.python.org/mailman/listinfo/python-list
Re: A question on modification of a list via a function invocation
On Monday, September 4, 2017 at 7:50:39 PM UTC+5:30, Steve D'Aprano wrote: > On Mon, 4 Sep 2017 01:11 pm, Rustom Mody wrote: > > Simply put: pythonistas have no coherent/consistent sense of what python > > values are. And the endless parameter-passing-nomenclature arguments are > > just > > the fallout of that. > > This is not a dispute unique to the Python community. Similar arguments take > place in the Java and Ruby communities, and I daresay many others. Well good to know we agree on this [I would add lisp to this list since its the progenitor of this model] And it is a primary factor for the desirability of transcending the imperative paradigm -- https://mail.python.org/mailman/listinfo/python-list
Re: A question on modification of a list via a function invocation
On Monday, September 4, 2017 at 8:37:45 PM UTC+5:30, Steve D'Aprano wrote: > On Tue, 5 Sep 2017 12:34 am, Rustom Mody wrote: > > > On Monday, September 4, 2017 at 5:58:18 PM UTC+5:30, ROGER GRAYDON CHRISTMAN > > wrote: > >> Or with just one function: >>> def baz(x,y): > >> x += y > >> >>> a = 10 > >> >>> b = [10] > >> >>> baz(a,a) > >> >>> a > >> 10 > >> >>> baz(b,b) > >> >>> b[10, 10] > > > > Ha Ha! Lovely > > > > [I was about to ask Chris if he is being serious about relating this to the > > presence of '=' ] > > > > However if you desugar the += into __iadd__ then someone may argue > > the presence of the = is an optical illusion > > I'm afraid I can't quite follow what people think this example actually > demonstrates. Anton gave a picture explaining why/how references are needed and to be understood I pointed out that while that picture is fine (and necessary) as part of the explanation, it does not properly address the central question of this thread, viz How to understand parameter passing in python. With this example: >>> def foo(x): x += 2 >>> def bar(x): x.append(2) >>> a=10 >>> b=[10] >>> foo(a) >>> a 10 >>> bar(b) >>> b [10, 2] >>> Roger Christman compressed my foo and bar into one baz def baz(x,y): x += y Which leaks or doesnt leak x-modifications depending on its type -- https://mail.python.org/mailman/listinfo/python-list
Re: A question on modification of a list via a function invocation
On Monday, September 4, 2017 at 9:13:43 PM UTC+5:30, Steve D'Aprano wrote: > On Tue, 5 Sep 2017 01:17 am, Rustom Mody wrote: > > > Anton gave a picture explaining why/how references are needed and to be > > understood > > Antoon gave a picture demonstrating one model of Python's semantics. > > It's a nice model that has a lot going for it, in particular that it matches > the > most obvious implementation. But it doesn't describe *Python* semantics, it > describes an overlap between Python the language and the implementation of the > Python interpreter. > > In particular, consider the picture of a name binding to a value: > > > +-+ > | | > | 5 | > | | > +-+ > ^ > | > > > > This picture has three entities, but only two of them exist in Python: > > - the object 5; > > - the name "x" (names are not values in Python at runtime, but they > are entities which exist in Python source code at compile time). > > The third entity is the reference linking the name to the object (the arrow). > This isn't a runtime value in Python, nor is it a compile time entity that > exists in source code. It is pure implementation, and as such, exists outside > of the Python domain. A common fallacy: https://en.wikipedia.org/wiki/Begging_the_question Python does not have references/pointers/whatever ∴ Python does not have references (or whatever you want to (not) call it) -- https://mail.python.org/mailman/listinfo/python-list
Re: meaning of [ ]
On Monday, September 4, 2017 at 10:42:47 PM UTC+5:30, Rick Johnson wrote:
> On Monday, September 4, 2017 at 9:27:23 AM UTC-5, Rustom Mody wrote:
> > On Monday, September 4, 2017 at 6:36:11 PM UTC+5:30, Ben Bacarisse wrote:
> > > Rustom Mody writes:
> > >
> > > > On Sunday, September 3, 2017 at 5:10:13 PM UTC+5:30, Rick Johnson wrote:
> > > >> Andrej Viktorovich wrote:
> > > >> > I suppose p becomes array of strings but what [] means in this
> > > >> > statement?
> > > >>
> > > >> Generally, it's an inline form of writing a loop that returns a
> > > >> list. There are other types as well.
> > > >
> > > > Tsk tsk the confusioning continues
> > > >
> > > > Rewrite
> > > > [p for p in sys.path]
> > > > as
> > > > [p | p ∈ sys.path]
> > > >
> > > > Is that clearer?
> > > >
> > > > And then as
> > > >
> > > > {p | p ∈ sys.path}
> > > > And refresh the idea of set-builder notation
> > > > http://www.mathwords.com/s/set_builder_notation.htm
> > >
> > > But [p for p in sys.path] is a list and "set-builder" notation is used
> > > for sets. Order is crucial for sys.path. You say exactly that below so
> > > I don't see how referring to sets helps anyone understand lists.
> >
> > Clearly if the question was of *sets* vs *lists* the
> > distinction is at least as crucial, maybe even more so than
> > the similarity.
>
> What made you assume the OP question had anything to do with
> sets versus lists? I didn't get that impression. Not to say
> that i could not be wrong, but i see no reason to believe i
> am.
I assume you are addressing this to Ben Bacarisse.
If to me then I am saying mostly what you are (in above para!)
>
> > The OP-question here however is one about comprehensions
> > and it appears without the questioner realizing that — as
> > Peter's answer showed
>
> My understanding of the impetus of the OP's question is a
> simple matter of attempting to intuit the structure of a
> list comprehension in the realms of Python code. Not a
> question as to the supposed "impurity" of python list
> comprehension form compared with set notation form. But
> again, i could be wrong.
My understanding is that the OP saw a 'for' inside a '[]' and wondered
"WTF is this?"
>
> > See the very first line of this:
> > https://en.wikipedia.org/wiki/List_comprehension
> > “List comprehension follows the form of the mathematical
> > set-builder notation (set comprehension)”
>
> I'm not sure if we should consider Wikipedia an "official"
> definition of the Python language, but if it were up to me,
> i would have chosen my words more carefully, as in: "List
> comprehension follows _loosely_ the form of the mathematical
> set-builder notation (set comprehension)”. My understanding
> that list comprehensions were borrowed from other languages.
Wikipedia is probably not the best definer for math either
In any case here its a question of how and what is the link between
a math concept/notation and its form/semantics in python
>
> > ie its both historically and structurally linked IOW
> > emphasising the incidental sequential nature of the
> > computation at the cost of the fundamental structure-
> > preserving nature of the concept
> > >
> > >
> > > > As Peter pointed out this is a no-op
> > > > ie
> > > > [p for p in sys.path]
> > > >
> > > > could be written as
> > > > list(sys.path)
> > >
> > > Both make a copy -- that's not a no-op. It may be a very-little-op but
> > > not nothing.
> >
> >
> > Its important…
> > - whether the machine stack grows up or down
> > - whether the bytes are ordered little-endian or big-endian
> > - whether IO is polled or interrupt driven
> > - whether IO ports are memory-mapped or in separate IO space
> > And much else
> >
> > Yet for most people doing most things today in most languages,
> > these questions are irrelevated
>
> Of course. Just as pointers and memory management are
> irrelevant...
careful! In an ideal world they should be irrelevant
Some knotty problems in python cannot be prized apart without talking of these
>
> > The question of copying is likewise, from a certain point
> > of view, irrelevant.
> >
> > Of course the further context of the OP m
Please improve these comprehensions (was meaning of [ ])
Since these discussions are uselessly abstract and meta
Here is some code I (tried) to write in class the other day
The basic problem is of generating combinations
Using the pascal-identity nCr + nC(r-1) = (n+1)Cr
This can be written (Haskell)
c :: Int -> Int -> Int
c n 0 = 1
c 0 (r+1) = 0
c (n+1) (r+1) = c n r + c n (r+1)
But I dont want NUMBER of combinations I want to generate combinations from
a given set
So change the spec to
c :: [a] -> Int -> [[a]]
ie n stops being a number but is now a set (here list) length n
c n 0 = [[]]
c [] (r+1) = []
c (x:xs) (r+1) = [x:l | l <- c xs r] ++ c xs (r+1)
Runs
? c [1,2,3,4] 2
[[1, 2], [1, 3], [1, 4], [2, 3], [2, 4], [3, 4]] :: [[Int]]
All binomials
? [c [1,2,3,4] r | r <- [0..4]]
[
[[]],
[[1], [2], [3], [4]],
[[1, 2], [1, 3], [1, 4], [2, 3], [2, 4], [3, 4]],
[[1, 2, 3], [1, 2, 4], [1, 3, 4], [2, 3, 4]],
[[1, 2, 3, 4]]
] :: [[[Int]]]
Now thats neat as far as it goes but combinations are fundamentally sets
not lists
So I thought python would do a better job
I tried translating it to python and sets but it turned out more annoying than
helpful
Can someone improve it??
The straightforward translation of the above
Which is ok so far
def c(n,r):
if r == 0:
return [[]]
elif len(n) == 0:
return []
else:
return [[n[0]] + l for l in c(n[1:],r-1)] + c(n[1:],r)
Now to go from returning list of lists to set of sets:
st = frozenset
nullset = st([])
def singleton(x): return st([x])
def splitset(s):
i = iter(s)
e = next(i)
new = st(i)
return e,new
def cs(n,r):
""" Set version of c"""
if r == 0 :
return singleton(nullset)
elif len(n) == 0 :
return nullset
else:
x,xs = splitset(n)
return st([(singleton(x) | l) for l in cs(xs,r-1)]) | cs(xs,r)
def ss0n(fs):
""" Shows a simple-set (ie set-0, contains no subsets) nicely"""
r = "{"
for x in fs:
r += repr(x) + ", "
return r + "}"
def ss1n(fs0):
""" Shows a set-of-sets (ie set-1, contents are sets) nicely"""
r = "{"
for x in fs0:
r += ss0n(x) + ", "
return r + "}"
>>> cs({1,2,3,4}, 2)
frozenset([frozenset([2, 4]), frozenset([3, 4]), frozenset([2, 3]),
frozenset([1, 3]), frozenset([1, 2]), frozenset([1, 4])])
>>> ss1n(cs({1,2,3,4}, 2))
'{{2, 4, }, {3, 4, }, {2, 3, }, {1, 3, }, {1, 2, }, {1, 4, }, }'
>>> ss1n(cs({1,2,3,4}, 2))
'{{2, 4, }, {3, 4, }, {2, 3, }, {1, 3, }, {1, 2, }, {1, 4, }, }'
So how could this be done better?
Here for reference is an abstract math ideal I would like to approximate
c : {t} → Int → {{t}} ## t is an arbitrary unspecified type
c n 0 = {{}}
c {} (r+1) = {}
c ({x} ∪ xs) (r+1) = {{x} ∪ l | l ∈ c xs r} ∪ c xs (r+1)
exactly parallel to the pascal identity
c n 0 = 1
c 0 (r+1) = 0
c (n+1) (r+1) = c n r + c n (r+1)
--
https://mail.python.org/mailman/listinfo/python-list
Re: Please improve these comprehensions (was meaning of [ ])
On Tuesday, September 5, 2017 at 1:44:24 AM UTC+5:30, Ben Bacarisse wrote:
> Rustom Mody writes:
>
> > Here is some code I (tried) to write in class the other day
> >
> > The basic problem is of generating combinations
>
> > Now thats neat as far as it goes but combinations are fundamentally sets
> > not lists
> >
> > So I thought python would do a better job
> > I tried translating it to python and sets but it turned out more annoying
> > than
> > helpful
> > Can someone improve it??
> >
> > The straightforward translation of the above
> > Which is ok so far
> >
> >
> > def c(n,r):
> > if r == 0:
> > return [[]]
> > elif len(n) == 0:
> > return []
> > else:
> > return [[n[0]] + l for l in c(n[1:],r-1)] + c(n[1:],r)
> >
> >
> > Now to go from returning list of lists to set of sets:
>
> def cs(n, r):
> if r == 0:
> return [set()]
> elif len(n) == 0:
> return []
> else:
> return [set([n[0]]) | l for l in cs(n[1:], r-1)] + cs(n[1:], r)
>
> ?
>
> It's not so neat if you also want n to be a set rather than a list
> because the set equivalents of n[0] and n[1:] are a but more complex but
> it's not that bad:
>
> def css(n,r):
> if r == 0:
> return [set()]
> elif len(n) == 0:
> return []
> else:
> rest = n.copy()
> e = rest.pop()
> return [set([e]) | l for l in css(rest, r-1)] + css(rest, r)
Trying out your code Ben…
>>> css({1,2,3,4}, 2)
[set([1, 2]), set([1, 3]), set([1, 4]), set([2, 3]), set([2, 4]), set([3, 4])]
>>> type(css({1,2,3,4}, 2))
Whereas with the cs I earlier gave:
>>> cs(frozenset([1,2,3,4]), 2)
frozenset([frozenset([2, 4]), frozenset([3, 4]), frozenset([2, 3]),
frozenset([1, 3]), frozenset([1, 2]), frozenset([1, 4])])
>>> type(cs(frozenset([1,2,3,4]), 2))
So in case I did not make it clear enough earlier, there are three collection
types in the spec.
A small amount of meta-combinatorics on the combinatorics!
Lets say
{1,2} : ℘ Int ## powerset
[1,2] : ℒ Int ## list type constructor
There are many others eg
⟆1,2⟅ : ℬ Int ## Bag type constructor
Not to mention iterators
Lets just stay with set and list for simplicity
So the combinations enumerator has the general type (schema)
[For ℛ being one of the above collection type constructors]
c : ℛ t → Int → ℛ ℛ t
However each of these ℛ's could be different
c : ℛ₁ t → Int → ℛ₂ ℛ₃ t
This gives 8 possibilities (assuming 2 constructors)
Your function had type
css : ℘ t → Int → ℒ ℘ t
whereas I wanted
cs : ℘ t → Int → ℘ ℘ t
And this has not yet touched on the difference between set and frozenset!
Why do we need frozenset at all?
Because the set type wont close in python!
## List of lists... ok
>>> [[1,2],[3,4]]
[[1, 2], [3, 4]]
## List of sets slightly clunky but still ok
>>> [{1,2},{3,4}]
[set([1, 2]), set([3, 4])]
## Set of sets??… Sorry!!
>>> {{1,2},{3,4}}
Traceback (most recent call last):
File "", line 1, in
TypeError: unhashable type: 'set'
--
https://mail.python.org/mailman/listinfo/python-list
Re: A question on modification of a list via a function invocation
On Tuesday, September 5, 2017 at 6:42:07 PM UTC+5:30, Gregory Ewing wrote: > Steve D'Aprano wrote: > > The third entity is the reference linking the name to the object (the > > arrow). > > This isn't a runtime value in Python, nor is it a compile time entity that > > exists in source code. It is pure implementation, and as such, exists > > outside > > of the Python domain. > > The fact that there is a connection between the name and the > object is very much part of Python's abstract semantics. > > There are different ways to implement that connection, but > *any* implementation of Python has to include *some* > representation of it. > > There are also different words that can be used to describe > it. You can say that names are bound to objects, or that > names refer to objects, or that names hold references to > objects. These are all equally good ways of talking about > the exact same abstract concept. > > To me this argument about whether Python has references > or not is like an American person saying that cars have > hoods, and a British person saying he's wrong, hoods > are an implementation detail and cars actually have > bonnets instead. Also called playing humpty-dumpty I believe there is a germ of value behind all this empty polemics There are 3 equivalence relations: 1. == — mathematical, too coarse to understand nuances of python semantics 2. is — machine representation, too fine to be useful 3. graph (or topological) equality which experienced pythonistas have internalized in understanding when two data structures are same or different [Roughly Anton's diagrams that are beyond my drawing capability!] And yet pythonistas need that to understand python data structures >>> a = [1,2] >>> b = [a,a] >>> c = [[1,2],[1,2]] >>> b == c True >>> b is c False >>> p = [1,2] >>> q = [p,p] >>> r = [[1,2],[1,2]] >>> q == r True >>> q is r False >>> b == q True >>> b == r True >>> b is q False >>> b is r False Now the pythonista understands that b and c may be math-= but have different structure Whereas b is graph-equal to q And c is graph-equal to r However there is no available operation to show/see that distinction The trouble is that graph-isomorphism is NP-complete so the crucial operation cannot be reasonably implemented Let the endless threads continue 😈 -- https://mail.python.org/mailman/listinfo/python-list
Re: Please improve these comprehensions (was meaning of [ ])
On Tuesday, September 5, 2017 at 6:59:11 PM UTC+5:30, Ben Bacarisse wrote:
> Rustom Mody writes:
>
> > On Tuesday, September 5, 2017 at 1:44:24 AM UTC+5:30, Ben Bacarisse wrote:
> >> Rustom Mody writes:
> >>
> >> > Here is some code I (tried) to write in class the other day
> >> >
> >> > The basic problem is of generating combinations
> >>
> >> > Now thats neat as far as it goes but combinations are fundamentally sets
> >> > not lists
> >> >
> >> > So I thought python would do a better job
> >> > I tried translating it to python and sets but it turned out more
> >> > annoying than
> >> > helpful
> >> > Can someone improve it??
> >> >
> >> > The straightforward translation of the above
> >> > Which is ok so far
> >> >
> >> >
> >> > def c(n,r):
> >> > if r == 0:
> >> > return [[]]
> >> > elif len(n) == 0:
> >> > return []
> >> > else:
> >> > return [[n[0]] + l for l in c(n[1:],r-1)] + c(n[1:],r)
> >> >
> >> >
> >> > Now to go from returning list of lists to set of sets:
> >>
> >> def cs(n, r):
> >> if r == 0:
> >> return [set()]
> >> elif len(n) == 0:
> >> return []
> >> else:
> >> return [set([n[0]]) | l for l in cs(n[1:], r-1)] + cs(n[1:], r)
> >>
> >> ?
> >>
> >> It's not so neat if you also want n to be a set rather than a list
> >> because the set equivalents of n[0] and n[1:] are a but more complex but
> >> it's not that bad:
> >>
> >> def css(n,r):
> >> if r == 0:
> >> return [set()]
> >> elif len(n) == 0:
> >> return []
> >> else:
> >> rest = n.copy()
> >> e = rest.pop()
> >> return [set([e]) | l for l in css(rest, r-1)] + css(rest, r)
> >
> > Trying out your code Ben…
> >
> >>>> css({1,2,3,4}, 2)
> > [set([1, 2]), set([1, 3]), set([1, 4]), set([2, 3]), set([2, 4]), set([3,
> > 4])]
> >
> >>>> type(css({1,2,3,4}, 2))
> >
> >
> > Whereas with the cs I earlier gave:
> >>>> cs(frozenset([1,2,3,4]), 2)
> > frozenset([frozenset([2, 4]), frozenset([3, 4]), frozenset([2, 3]),
> > frozenset([1, 3]), frozenset([1, 2]), frozenset([1, 4])])
>
> If you want a (frozen) sets of sets I'd just the code to
>
> def css(n, r):
> if r == 0:
> return frozenset({frozenset()})
> elif len(n) == 0:
> return frozenset()
> else:
> rest = set(n)
> e = rest.pop()
> return frozenset([frozenset([e])
> | l for l in list(css(rest, r-1))]) | css(rest, r)
>
> >>> css(frozenset({1,2,3,4}), 2)
> frozenset({frozenset({2, 4}), frozenset({3, 4}), frozenset({2, 3}),
> frozenset({1, 3}), frozenset({1, 2}), frozenset({1, 4})})
>
> The switch from lists (using +) and frozen sets using | is the most
> obvious change, but if the top-level argument might itself be a
> frozenset then the copy must be changed to a set constructor so that pop
> will work.
Yes…
Pop et al wont work with frozen sets
Containment wont work with sets — what mathematicians call 'not closed'
All of which amounts to this that python sets are not really pleasant for
math-work
[Just for context: A teacher may have more important things to teach than python
If the niggles get overbearing the vehicle may not be worth it
]
Besides I find the name pop ridiculous
Stacks imply a stronger order usage-discipline than lists
Sets are unordered compared to lists
To use a name traditionally reserved for a stack op on sets is quite nonsensical
--
https://mail.python.org/mailman/listinfo/python-list
Re: A question on modification of a list via a function invocation
On Tuesday, September 5, 2017 at 7:12:48 PM UTC+5:30, Rustom Mody wrote: > On Tuesday, September 5, 2017 at 6:42:07 PM UTC+5:30, Gregory Ewing wrote: > > Steve D'Aprano wrote: > > > The third entity is the reference linking the name to the object (the > > > arrow). > > > This isn't a runtime value in Python, nor is it a compile time entity that > > > exists in source code. It is pure implementation, and as such, exists > > > outside > > > of the Python domain. > > > > The fact that there is a connection between the name and the > > object is very much part of Python's abstract semantics. > > > > There are different ways to implement that connection, but > > *any* implementation of Python has to include *some* > > representation of it. > > > > There are also different words that can be used to describe > > it. You can say that names are bound to objects, or that > > names refer to objects, or that names hold references to > > objects. These are all equally good ways of talking about > > the exact same abstract concept. > > > > To me this argument about whether Python has references > > or not is like an American person saying that cars have > > hoods, and a British person saying he's wrong, hoods > > are an implementation detail and cars actually have > > bonnets instead. > > Also called playing humpty-dumpty > > I believe there is a germ of value behind all this empty polemics > There are 3 equivalence relations: > 1. == — mathematical, too coarse to understand nuances of python semantics > 2. is — machine representation, too fine to be useful > 3. graph (or topological) equality which experienced pythonistas have > internalized > in understanding when two data structures are same or different > [Roughly Anton's diagrams that are beyond my drawing capability!] > > > And yet pythonistas need that to understand python data structures > > >>> a = [1,2] > >>> b = [a,a] > >>> c = [[1,2],[1,2]] > >>> b == c > True > >>> b is c > False > >>> p = [1,2] > >>> q = [p,p] > >>> r = [[1,2],[1,2]] > >>> q == r > True > >>> q is r > False > >>> b == q > True > >>> b == r > True > >>> b is q > False > >>> b is r > False To make it more clear Suppose ≡ is graph-equal. The pythonista understands that b ≢ c ## ≡ is finer than == Whereas b ≡ r ie ≡ is coarser than is Its another matter that the name 'is' makes these discussions much harder in python than in equivalent languages like java, lisp, javascript etc by making the mostly unnecessary and irrelevant "is machine-rep same" sound the same(!) as "is conceptually same" -- https://mail.python.org/mailman/listinfo/python-list
Re: Please improve these comprehensions (was meaning of [ ])
On Tuesday, September 5, 2017 at 7:32:52 PM UTC+5:30, Chris Angelico wrote: > On Tue, Sep 5, 2017 at 11:49 PM, Rustom Mody wrote: > > Pop et al wont work with frozen sets > > Containment wont work with sets — what mathematicians call 'not closed' > > All of which amounts to this that python sets are not really pleasant for > > math-work > > Funnily enough, Python has never boasted that it's great for > mathematicians. True that > Time and time again I see posts here that try to > explain Python from the POV of pure mathematics, and they always seem > to end up getting convoluted and awkward. Unrelated that. Look at all the fundamental operations here https://docs.python.org/3.6/library/operator.html What percentage of these are unrelated to math? And how do you write even the simplest assignment statement without a (mathematical) expression on the rhs? And a look at history: What *were* Turing, Church, von Neumann, even Knuth by training? Mathematicians or CS-ists? And what *are* the contributions of Turing, Church, von Neumann, Knuth to CS? -- https://mail.python.org/mailman/listinfo/python-list
Re: Python console's workspace path
On Tuesday, September 5, 2017 at 7:58:23 PM UTC+5:30, Andrej Viktorovich wrote:
> Hello,
>
> I run Python 3.6 console under windows 10. Where is default console directory?
>
> I run script:
> >>> tf = open ("aaa.txt", "w")
> >>> tf.write(" %s" % 123)
> >>> tf.close()
>
> Where file aaa.txt will be created? Can I change default work space location?
> How?
>>> from os import getcwd
>>> getcwd()
You'll see where/what python takes as cwd (current working directory)
There are other things on windows like rt-click the python executable icon
on your desktop and adjust the "open in..." to whatever you want
But I dont know too much about this to say 😊
--
https://mail.python.org/mailman/listinfo/python-list
Re: Run python module from console
On Tuesday, September 5, 2017 at 8:45:00 PM UTC+5:30, Andrej Viktorovich wrote: > Hello, > > I suppose I can run python module by passing module as param for executable: > > python.exe myscr.py > > But how to run script when I'm inside of console and have python prompt: > > >>> >> import myscr # Note no .py extension -- https://mail.python.org/mailman/listinfo/python-list
Re: Run python module from console
On Tuesday, September 5, 2017 at 8:45:00 PM UTC+5:30, Andrej Viktorovich wrote: > Hello, > > I suppose I can run python module by passing module as param for executable: > > python.exe myscr.py > > But how to run script when I'm inside of console and have python prompt: > > >>> By and large not straightforwardly possible At python prompt you call *functions* At OS prompt you call apps/programs/scripts including python *scripts* They are different with different calling conventions However if you look up on the __name__ == '__main__' trick you can find ways of getting both function call and script call behavior https://stackoverflow.com/questions/419163/what-does-if-name-main-do -- https://mail.python.org/mailman/listinfo/python-list
Re: A question on modification of a list via a function invocation
On Tuesday, September 5, 2017 at 10:45:45 PM UTC+5:30, Ned Batchelder wrote: > On 9/5/17 1:02 PM, Steve D'Aprano wrote: > > On Tue, 5 Sep 2017 11:37 pm, Gregory Ewing wrote: > > > >> Dennis Lee Bieber wrote: > >>> Pascal, probably Modula-2, Visual BASIC are closer to the C++ reference > >>> semantics, in that the definition of a function declares how the > >>> argument(s) are passed. > >> Well, sort of. In Pascal and Modula, and also VB I think, > >> parameters are the only things that can be declared as having > >> reference semantics, whereas references in C++ are first-class > >> things that can be stored in any variable. > > No, they aren't first-class. > > Did you mis-read Gregory's claim? He said, "references *in C++* are > first-class things". You seem to be talking below about Python things. I think its mostly true of C++ And Steven did say: (I don't know enough about C++ to distinguish between the last two opinions, but I'm strongly leaning towards "not values at all".) So he seems to be talking of C++ (as analogous to python??) But I dont see that any of it is relevant Whether references are - first-class (Algol-68, pointers-in-C) or are simply - second class (C++) - invisible (python, lisp, ruby, javascript) has little to do with what we are talking The question is whether we need the *idea* of references (modulo humpty-dumpty-fication) to talk *about* the language; ie it needs to be there in the human/informal ontology, even if the docs play word-games and try to avoid trigger-words in honour of PC. In my view its almost the defining quality of imperative languages that the semantics of the language is not properly/fully comprehensive without (something like) references. [Replace "imperative language" with "assignment and mutation" if you like] -- https://mail.python.org/mailman/listinfo/python-list
Re: A question on modification of a list via a function invocation
On Wednesday, September 6, 2017 at 3:34:41 AM UTC+5:30, Marko Rauhamaa wrote: > Chris Angelico : > > > That shows that the Java '==' operator is like the Python 'is' > > operator, and checks for object identity. You haven't manipulated > > pointers at all. In contrast, here's a C program that actually > > MANIPULATES pointers: > > > > [...] > > > > You can't do this with Python, since pointer arithmetic fundamentally > > doesn't exist. You can in C. Can you in Java? > > You can't do it in Pascal, either, but Pascal definitely has pointers. > > Pointer arithmetics is not an essential part of C. One could argue that > it was a mistake to include it in the language. This is subjective of course… but still I wonder where you are coming from… You of course know that writing Unix was the genesis and raison d'être for C right? And what is an OS but a thin layer of abstraction on top of bare ISP? ie is not a Linux-OS just an x86 hw + some new ‘instructions’ called system-calls? Which is to say IMHO being able to punch holes into the hi-level-language abstraction seems to be a sine qua non for being suitable as a language for writing OSes. Do you think its reasonable/feasible to do that without easy access to all the machine resources eg memory, IO, interrupts etc accessible in the OS-writing language? [BTW I think Microsoft has done a better job than classic C of repeating this with C# — C# is almost as high-level as python, lisp etc and as low (or lower) than C; ie it is effectively two languages, called ‘safe’ and ‘unsafe’ parts ] -- https://mail.python.org/mailman/listinfo/python-list
Re: Please improve these comprehensions (was meaning of [ ])
On Wednesday, September 6, 2017 at 6:27:24 AM UTC+5:30, Steve D'Aprano wrote: > On Wed, 6 Sep 2017 12:19 am, Rustom Mody wrote: > > > And how do you write even the simplest assignment statement without a > > (mathematical) expression on the rhs? > > name = other_name > > is not a mathematical expression. Its giving something a new name. > > name = obj.attribute > > is not a mathematical expression. (That's not a dot product.) > Ok you win (that) [And I see your stocks of straw are overflowing. Wholesale prices?] > > > > What were Turing, Church, von Neumann, even Knuth by training? > > Mathematicians > > or CS-ists? > > > > And what are the contributions of Turing, Church, von Neumann, Knuth to CS? > > Who cares? We're talking about Python, not Computer Science. He who forgets history is doomed to repeat it. Start with your own statement: “Lisp is a functional language” And see the history a little bit more http://blog.languager.org/2015/04/cs-history-1.html 1960 : McCarthy got the idea of functional programming from an earlier invention of a certain Backus called 'The Formula Translator' which would later shorten to ForTran 1980s: The functional programming community was decrying lisp: "Success of lisp set back the development of functional programming by 10 years" And most significant: “McCarthy did not consider Lisp to be a functional language” Of course nothing to be surprised here: You know more java than old java-heads And more lisp than John McCarthy 😉 -- https://mail.python.org/mailman/listinfo/python-list
Re: Please improve these comprehensions (was meaning of [ ])
On Wednesday, September 6, 2017 at 6:58:29 AM UTC+5:30, Rustom Mody wrote: > On Wednesday, September 6, 2017 at 6:27:24 AM UTC+5:30, Steve D'Aprano wrote: > > On Wed, 6 Sep 2017 12:19 am, Rustom Mody wrote: > > > What were Turing, Church, von Neumann, even Knuth by training? > > > Mathematicians > > > or CS-ists? > > > > > > And what are the contributions of Turing, Church, von Neumann, Knuth to > > > CS? > > > > Who cares? We're talking about Python, not Computer Science. > Of course nothing to be surprised here: You know more java than old java-heads > And more lisp than John McCarthy 😉 Also noteworthy here: You know more about list comprehensions than their inventor — Greg Ewing [No I normally would not call Greg their inventor but in this case following through your logic that python exists in a historical, contextual vacuum] -- https://mail.python.org/mailman/listinfo/python-list
Re: A question on modification of a list via a function invocation
On Wednesday, September 6, 2017 at 9:22:15 AM UTC+5:30, Chris Angelico wrote: > On Wed, Sep 6, 2017 at 1:42 PM, Stefan Ram wrote: > > Steve D'Aprano writes: > >>So in what sense are references part of the Python language? > > > > It would be possible to describe Python using a concept > > called "reference", it's just that the The Python Language > > Reference, Release 3.6.0 (PRL) does /not/ do this. > > And programming language experts usually use the terms that > > the language specification uses with the meaning that the > > language specification is giving them. And this is why I say > > that JavaScript and Python do not have references. > > (Except "attribute references".) > > > >>Inside the interpreter, you (probably?) could print out the value of the > >>pointer, or manipulate it in some fashion. > > > > Well, this /is/ from the PRL: > > > > »An object's identity never changes once it has been created; > > you may think of it as the object's address in memory.«. > > ¯¯ > > - The Python Language Reference, Release 3.6.0; > > 3.1 Objects, values and types > > > > It's not called "reference", it's called "identity". But it > > might agree with your idea of a pointer of an implementation. > > And you /can/ print it. > > > print( id( 'abc' )) > > 4163144 > > Printing out an address is only half the point (pun intended) of a > pointer - and the useless half. Given a pointer, you need to be able > to dereference it. How can you, given the id of a Python object, > access the object itself? The nearest I've ever seen is a function > that searches every object it can find, looking for one with the same > id. Well ⅓ the point of pointers may be printing them out — which even in a language with 1st class pointers like C is rarely done/needed Another ⅓ is dereferencing, pointer-arithmetic etc... the various manifestations of 1st-class pointers And the third ⅓ is to provide explanations to people asking authentic questions [like the OP of this thread] Sure you can say with Steven that this can be 'explained' by saying an object can be in two places at one time. Others would then say 'Humpty-dumpty!' since you have removed the most basic intuition of objects and you are in effect saying that a python object means what you ordain it means without further ado/explanation Since you believe a reference-less dictionary can be a model for such explanations, why not provide that? -- https://mail.python.org/mailman/listinfo/python-list
Re: A question on modification of a list via a function invocation
On Wednesday, September 6, 2017 at 9:55:10 AM UTC+5:30, Chris Angelico wrote: > On Wed, Sep 6, 2017 at 2:17 PM, Rustom Mody wrote: > > Well ⅓ the point of pointers may be printing them out — which even in a > > language > > with 1st class pointers like C is rarely done/needed > > But still the useless part. You don't actually *achieve* anything by > printing out the pointer. > > > Another ⅓ is dereferencing, pointer-arithmetic etc... the various > > manifestations > > of 1st-class pointers > > This is the part that matters. > > > And the third ⅓ is to provide explanations to people asking authentic > > questions > > [like the OP of this thread] > > Only questions that actually relate to one of the previous parts. [dangling pointer ?¿?¿ ] > > > Sure you can say with Steven that this can be 'explained' by saying an > > object > > can be in two places at one time. > > Others would then say 'Humpty-dumpty!' since you have removed the most basic > > intuition of objects and you are in effect saying that a python object > > means what you ordain it means without further ado/explanation > > > > Since you believe a reference-less dictionary can be a model for such > > explanations, > > why not provide that? > > A piece of paper works just fine. However, it's hard to use that > method of explanation in an email. I am ready to bet that if ASCII is insufficient then you are drawing pictures You can call them whatever you like - pointers, references - data structure diagrams - graphs vertices, edges - I think I'll call them Antoon-art in honor of Antoon Pardon who has the patience to draw them I believe it was Marko Rauhamaa who have another half dozen metaphors: - doggies and pussies er.. sorry leashes Whatever you use, you will have to reify in your explanation the idea of pointer/graph-edge/etc even and especially because, the language disallows such a reification -- https://mail.python.org/mailman/listinfo/python-list
Re: A question on modification of a list via a function invocation
On Wednesday, September 6, 2017 at 12:51:25 PM UTC+5:30, Gregory Ewing wrote: > Rustom Mody wrote: > > 2. is — machine representation, too fine to be useful > > Disagree - "is" in Python has an abstract definition that > doesn't depend on machine representation. > > -- > Greg There is this (AFAIAC sophistry) in the docs describing the data model https://docs.python.org/3/reference/datamodel.html | Every object has an identity, a type and a value. An object’s identity never | changes once it has been created; you may think of it as the object’s address | in memory. The ‘is’ operator compares the identity of two objects; the id() | function returns an integer representing its identity. | CPython implementation detail: For CPython, id(x) is the memory address where | x is stored. Can you explain what "id" and "is" without talking of memory? In fact we have got so used to the term 'memory' that it actually seems strange when someone like Dijkstra grumbles at the anthropomorphism and asks why its not called 'store'. -- https://mail.python.org/mailman/listinfo/python-list
Re: Please improve these comprehensions (was meaning of [ ])
On Wednesday, September 6, 2017 at 4:29:56 PM UTC+5:30, Gregory Ewing wrote: > Seems to me you're making life difficult for yourself (and > very inefficient) by insisting on doing the whole computation > with sets. If you want a set as a result, it's easy enough > to construct one from the list at the end. Sure with programmer hat firmly on that is the sensible view. But there are equally legitimate other hats to consider: Learning combinatorics for example. And from that point of view Python (or Haskell or whatever) should be mostly irrelevant. Whereas what should be relevant is what SICP calls ‘procedural epistemology’: https://mitpress.mit.edu/sicp/front/node3.html | Underlying our approach to this subject is our conviction that "computer | science" is not a science and that its significance has little to do with | computers. The computer revolution is a revolution in the way we think and in | the way we express what we think. The essence of this change is the emergence | of what might best be called procedural epistemology the study of the | structure of knowledge from an imperative point of view, as opposed to the | more declarative point of view taken by classical mathematical subjects. | Mathematics provides a framework for dealing precisely with notions of "what | is." Computation provides a framework for dealing precisely with notions of | "how to." Coming to the details in this case, the important difference between permutations and combinations is not the numbers nPr and nCr but that a permutation is a list and a combination is a set. So this definition of permutations is fine (almost): def perms(l): if not l: return [[]] x, xs = l[0], l[1:] return [p[:i] + [x] + p[i:] for p in perms(xs) for i in range(0,len(l))] >>> perms([1,2,3]) [[1, 2, 3], [2, 1, 3], [2, 3, 1], [1, 3, 2], [3, 1, 2], [3, 2, 1]] Because the abstract idea of a permutation is a list (sequence) And the implementation here is faithful to that [The outer being a list is a mild annoyance... We can let it pass] However in this: def c(n,r): if r == 0: return [[]] elif len(n) == 0: return [] else: return [[n[0]] + l for l in c(n[1:],r-1)] + c(n[1:],r) the [n[0]] + l is misguidingly overspecific, ie it suggests an order which has no relevance or connection to the problem. Note that *as a programmer* this may be fine From the pov of studying math, its wrong Now if you want to agree with Chris in saying that python is unsuitable for doing math, that's fine. [I am tending to agree myself] I posted it because I genuinely thought I had missed some obvious way of splitting a set into an (arbitrary) element and a rest without jumping through hoops. Evidently not -- https://mail.python.org/mailman/listinfo/python-list
Re: A question on modification of a list via a function invocation
On Wednesday, September 6, 2017 at 5:08:20 PM UTC+5:30, Steve D'Aprano wrote: > On Wed, 6 Sep 2017 07:13 pm, Rustom Mody wrote: > > > > Can you explain what "id" and "is" without talking of memory? > > Yes. > > id() returns an abstract ID number which is guaranteed to be an integer, and > guaranteed to be distinct for all objects which exist at the same time. When > an > object ceases to exist, its ID number may be re-used. > > `is` compares the two operands for identity. If the two operands are the same > object, `is` returns True, if they are distinct objects, `is` returns False. >>> a = (1,2) >>> b = (1,2) >>> a is b False >>> x = 1 >>> y = 1 >>> x is y True a seems to be as 'same' to b as x is to y Python seems to think otherwise Evidently your ‘same’ is not the same as mine?? > > > In fact we have got so used to the term 'memory' that it actually seems > > strange when someone like Dijkstra grumbles at the anthropomorphism and asks > > why its not called 'store'. > > And if it were called "store" (grocery store? shoe store? clothes store?) > Dijkstra would have grumbled at the metaphor and asked why it wasn't > called "memory". Memory is an old (middle-English) word. Until say 1945 it could be used in sentences like the following “I have memories of walking in the woods with my dad” “Where are the eggs?” “Oops! Totally slipped my memory… Sorry" “The Dalai Lama has memories of his past lives” Are you using ‘memory’ in this kind of way? -- https://mail.python.org/mailman/listinfo/python-list
Re: A question on modification of a list via a function invocation
On Wednesday, September 6, 2017 at 4:03:40 PM UTC+5:30, ROGER GRAYDON CHRISTMAN
wrote:
> On 5 Sep 2017 14:28:44, (Dennis Lee Bier) wrote:
> > On 5 Sep 2017 17:57:18 GMT,
> >> But what does "a C++ reference" refer to?
> >>
>
> > Per Stroustrup (The C++ Programming Language 4th Ed, page 189)
>
> > """
> > * ...> * A reference always refers to the object to which it was
> > initialized.
> > * ...
>
> > A reference is an alternative name for an object, an alias. ...
> > """
>
> > {Hmmm, and I see that the syntax can be used outside of parameter
> > declaration -- which is the only place I'd seen it previously... either
> > this is a change from earlier standards, or my classes just didn't feel the
> > need to expose a non-parameter reference -- since, based upon the above
> > book, you can not declare a bare reference "variable"; it MUST be
> > initialized with a real object.}
>
> I think I can say something about this, having been a teacherof the classes
> you refer to. I intentionally avoided reference variables.
> IMO, the 'good' use for declaring a new reference variable (i.e. not
> parameter)would be when (1) the object to which you refer to is
> time-consuming to access(2) you plan to refer to this object more then once,
> and don't want to repeatthat time-consuming process, and (3) you really want
> a reference, and not a copy.
> The first two years of programming courses really do not have a purposethat
> meets all three, so can "didn't feel the need" is probably applicable.
> I intentionally avoided them because reference variables simply compoundthe
> problem of aliasing, so unless you really limit your reference variableto a
> very tight sandbox, you could be causing more headache than you save.
> I do admit to occasionally defining a method that returned a reference,such
> as one that overloads the [] operator. But even so, I would generallybe
> reluctant to giving an outside client a direct access to my
> database'sinternal structures. (Thank you Python for separating __getitem__
> and __setitem__)
> Python doesn't eliminate aliasing, of course, since most assignment
> operationscreate aliases. But at least it's nice to know that aliasing
> immutable valuesis harmless. Hence my unit on building recursive data
> structures entirelyout of tuples.
The realization that immutability is a significant virtue is now beginning
to percolate mainstream programming
Ive seen it in recent C# books as a definite recommendation… Something like
- Use value types
- Use getters but no setters
And you have a good design
Python makes this hard by giving less status to immutable types than mutable
ones
- set comprehensions exist not frozenset comprehensions
- Likewise tuples and lists
--
https://mail.python.org/mailman/listinfo/python-list
Re: A question on modification of a list via a function invocation
On Wednesday, September 6, 2017 at 5:48:48 PM UTC+5:30, Chris Angelico wrote: > On Wed, Sep 6, 2017 at 10:11 PM, Rustom Mody wrote: > > On Wednesday, September 6, 2017 at 5:08:20 PM UTC+5:30, Steve D'Aprano > > wrote: > >> On Wed, 6 Sep 2017 07:13 pm, Rustom Mody wrote: > >> > >> > >> > Can you explain what "id" and "is" without talking of memory? > >> > >> Yes. > >> > >> id() returns an abstract ID number which is guaranteed to be an integer, > >> and > >> guaranteed to be distinct for all objects which exist at the same time. > >> When an > >> object ceases to exist, its ID number may be re-used. > >> > >> `is` compares the two operands for identity. If the two operands are the > >> same > >> object, `is` returns True, if they are distinct objects, `is` returns > >> False. > > > >>>> a = (1,2) > >>>> b = (1,2) > >>>> a is b > > False > >>>> x = 1 > >>>> y = 1 > >>>> x is y > > True > > > > a seems to be as 'same' to b as x is to y > > Python seems to think otherwise > > > > Evidently your ‘same’ is not the same as mine?? > > *facepalm* > > I got nothing to say to you. Have you been on this list all this time > and still don't understand that Python sometimes optimizes immutables? Losing 'memory' of context Chris? Let me erm… remind: I said 'is' refers to "same in machine representation" Greg disagreed: « "is" in Python has an abstract definition that doesn't depend on machine representation.» I said: In that case please restate the definition of 'is' from the manual which invokes the notion of 'memory' without bringing in memory. Steven gave his explanation by dropping 'memory' and gave a definition Which I showed does not match expected common sense Sure you can bring in the notion (now!) of optimization if you like But you cant have it both ways - 'is' is a fundamental conceptual notion of sameness - 'is' is a machine/implementation specific notion of sameness which changes depending on machine/implementation specific decisions Of course you can have a third hand… Its usually called sophistry The trouble with sophistrizing is that you get caught in your own net: You (and Steven) claim that references (and aliases such as pointers) can be expunged from the language semantics. If you do that the term 'memory' remains standalone without any semantics. And when you make a bogus expulsion of that as well, extant behavior becomes unexplainable… Except with a… (which I share) *facepalm* -- https://mail.python.org/mailman/listinfo/python-list
Re: Please improve these comprehensions (was meaning of [ ])
On Wednesday, September 6, 2017 at 5:59:17 PM UTC+5:30, nopsidy wrote:
> https://www.youtube.com/watch?v=pNe1wWeaHOU&list=PLYI8318YYdkCsZ7dsYV01n6TZhXA6Wf9i&index=1
> Thank you,
> -Alex Goretoy
> http://launchpad.net/~a1g
You (Alex) are top-posting. I am not fussy. But others here can be
In any case thanks for quoting Stefan's post which I would not see otherwise
>
>
> On Wed, Sep 6, 2017 at 7:22 PM, Stefan Ram wrote:
> > Rustom Mody writes:
> >>Because the abstract idea of a permutation is a list (sequence)
> >
> > Traditional mathematical books (which are not influenced by
> > computer programming terminology) often use "n-tuple"
> > (or "sequence") instead of "list" IIRC.
> >
> > It is important to note that - according to me - a Python
> > data structure with the same /name/ as a mathematical concept
> > does not always have to be the best way to implement that
> > mathematical concept. E.g., sometimes a Python list might be
> > the best way to implement a mathematical tuple, or a Python
> > tuple may be the best way to implement a mathematical set.
I came to the conclusion and said more or less what you are saying Stefan…
when programmer hat is on. viz that the simplest solution (all lists) is
probably the way to go.
I've taught this (with the simple list-solution) many times over decade(s)
Then this time I thought: "Hey! Python now has sets. And even set-
comprehensions! Maybe the solution could be more sparkling clean if I switch
from lists to sets?"
However every effort of mine was clumsy and unsatisfactory.
So thought of asking if I am missing something… Evidently not
- the set data type does not nest — {1,2} possible {{1,2},{3,4}} not
- the frozenset datatype is (pragmatically) incomplete — no clean way to
separate an element from a (frozen)set
So all in all too many hoops to jump through
[Greg talked of efficiency — not my primary concern (here)]
PS As said I do not see your posts (Stefan) unless someone quotes them
--
https://mail.python.org/mailman/listinfo/python-list
Re: Why do we nned both - __init__() and __new__()
On Thursday, September 7, 2017 at 4:27:48 PM UTC+5:30, Andrej Viktorovich wrote:
> Hello
>
> For my understanding both - __init__() and __new__() works like constructors.
> And __new__() looks is closer to constructor. __init__() is more for variable
> initialization. Why I can't just initialize in __init__() ?
>
> class ExampleClass(object):
> def __new__(cls,value):
> print("creating new instance with val %s" % (value,) )
> instance = super(ExampleClass,cls).__new__(cls)
> return instance
> def __init__(self, value):
> print("Initialising instance... with val %s" % (value,))
> self.payload = value
>
> exampleInstance = ExampleClass(42)
> print(exampleInstance.payload)
If you are not sure, forget about __new__
__init__ is the one you need mostly
[Ive never used new (in Python); C++ is a different case altogether]
See
https://mail.python.org/pipermail/tutor/2008-April/061424.html
and further thread
--
https://mail.python.org/mailman/listinfo/python-list
Re: A question on modification of a list via a function invocation
On 06/09/17 14:02, Stefan Ram wrote: > Chris Angelico writes: >> The 'is' operator tests if two things are the same thing. > >»Roughly speaking, to say of two things that they are >identical is nonsense, and to say of one thing that it >is identical with itself is to say nothing at all.« > > Ludwig Wittgenstein, Tractatus Logico-Philosophicus (5.5303) Someone who is philosophically literate in technical forum: a rare treat! Nice!! Wittgenstein is a favorite of mine and I often reserve one lecture for his: “Limits of my language are the limits of my world” Then amplified by Roman Jacobson’s “Languages differ not in what we can say but what we must say” And finally with Whorf's evidence that words can set buildings on fire https://web.stanford.edu/dept/SUL/library/extra4/sloan/mousesite/Secondary/Whorfframe2.html [Today it would be send countries to war] However Wittgenstein's quote above on identity is too terse to properly grasp the real difficulty https://plato.stanford.edu/entries/identity/ shows at some (verbose!) length that identity is and can only be a hopelessly circular definition. A problem which has little to do with python, programming languages, or CS in general; it is a fundamental universal problem -- https://mail.python.org/mailman/listinfo/python-list
Re: A question on modification of a list via a function invocation
On Thursday, September 7, 2017 at 6:52:04 PM UTC+5:30, Gregory Ewing wrote: > Rustom Mody wrote: > > > I said: In that case please restate the definition of 'is' from the manual > > which > > invokes the notion of 'memory' without bringing in memory. > > I don't know whether it's in the manual, but at least for > mutable objects, there is a way to define the notion of > "same object" that doesn't require talking about "memory": > > Two names refer to the same object if and only if mutations > made through one are visible through the other. Seems a sensible comment! [Aside from the fact that 'visible' is likely ill or circularly defined — my other comment to Stefan. But lets just ignore that for now and assume that 'visible' has no grey/dispute areas] > > Python has definite rules concerning when mutable objects > will be the same or not, and every correct implementation > must conform to them. In that sense it's a fundamental > concept that doesn't depend on implementation. I'd like to know what these rules are > > There is more leeway when it comes to immutable objects; > implementations are free to cache and re-use them, so > well-written code avoids depending on the result of > "is" for immutable objects. Which sounds like saying that 'isness' of immutables is ill/un-defined Not that I object if this is said My objection is to the claim that the isness of python's is and the isness of 'conceptually-same' are the same. I believe that your definition of same and the one I earlier gave are similar (same?? Not sure) Repeating here for ease: (with some clarifications) We say equivalence relation R is coarser than S is xSy ⇒ xRy So x is y ⇒ x == y but not (necessarily) vice versa However there are not 2 but 3 equivalence relations: 1. == — mathematical, too coarse to understand nuances of python semantics 2. is — machine representation, too fine to be useful 3. graph (or topological) equality which experienced pythonistas have internalized in understanding when two data structures are same or different [Roughly Anton's diagrams that are beyond my drawing capability!] And yet pythonistas need 3 to understand python data structures ie 3 captures pythonistas intuition of same better than 1 or 2 >>> a = [1,2] >>> b = [a,a] >>> c = [[1,2],[1,2]] >>> b == c True >>> b is c False >>> p = [1,2] >>> q = [p,p] >>> r = [[1,2],[1,2]] >>> q == r True >>> q is r False >>> b == q True >>> b == r True >>> b is q False >>> b is r False Now the pythonista understands that b and c may be math-= but have different structure Whereas b is graph-equal to q And c is graph-equal to r However there is no available operation to show/see that distinction The trouble is that graph-isomorphism is NP-complete so the crucial operation cannot be reasonably implemented To make it more clear ≡ is graph-equal, ie 2. The pythonista understands that b ≢ c ## ≡ is finer than == Whereas b ≡ r ie ≡ is coarser than is And b and r are python-equivalent without any memory relation in the sense that no sequence of valid operations applied to b and to r will tell them apart — sometimes called 'trace-equivalence' -- https://mail.python.org/mailman/listinfo/python-list
Re: A question on modification of a list via a function invocation
On Friday, September 8, 2017 at 7:39:38 AM UTC+5:30, Steve D'Aprano wrote: > On Fri, 8 Sep 2017 04:24 am, Rustom Mody wrote: > > > On Thursday, September 7, 2017 at 6:52:04 PM UTC+5:30, Gregory Ewing wrote: > >> Rustom Mody wrote: > >> > >> > I said: In that case please restate the definition of 'is' from the > >> > manual > >> > which invokes the notion of 'memory' without bringing in memory. > >> > >> I don't know whether it's in the manual, but at least for > >> mutable objects, there is a way to define the notion of > >> "same object" that doesn't require talking about "memory": > >> > >> Two names refer to the same object if and only if mutations > >> made through one are visible through the other. > > > > Seems a sensible comment! > > > Except that it is wrong, or at least over-generalised. It is trivially easy to > show false positives: > > py> class K: # defines an object > ... def __init__(self, x): > ... self.x = x > ... def append(self, value): > ... self.x.append(value) > ... > py> a = [] > py> b = K(a) > py> a is b # these are not the same object (they're different types) > False > py> b.append(99) # but modifying b modifies a > py> a > [99] > > > Rustom, I've already given you the definitive answer to your question about > how > to define `is` without talking about memory. You haven't replied or > acknowledged it, so here is it again: > > `is` compares the two operands for identity. Preamble… so far so good > If the two operands are the same > object, `is` returns True, if they are distinct objects, `is` returns False. restated a is b iff a is b A more than usually egregious demo of the circularity of defining isness/sameness Models are needed Math is one possible model Machines are another Paper and pen — which Chris keeps referring to — is another Remove all models and you have frank hopeless circularity > > > This does require that we agree on "same object", which as you point out is > (in > its full generality) a difficult thing to define. More than difficult, impossible in the fully abstract philosophical case When concretized to specific models not necessarily the fundamental circularity then pushed out to the model 1 + 2 = 3 Are these '3's on your and my screen same? Same font? Same time? E.g. in the past I've raised > the paradox of My Grandfather's Axe. Dont see the relevance (here) > > But the intuitive, common-sense notion of "same object" is, I think, > sufficient > here. If you want to argue that it is *not* sufficient, I think it's up to you > to demonstrate a problem with the definition. > Its not that you cant raise philosophical problems if you want But when concretized to (basic) math, there are no disputes so the argument becomes obtuseness to no point In the case of python data model every single interminable thread like this one, obviously started by a noob asking something genuinely and indicating a real confusion disproves your claim to obvious intuition and common sense Just to reiterate: Someone asked a question Its not clear what (s)he understood from what we have going on and on about for 100s of posts > Can you show an actual false positive (two distinct objects for which `is` > returns True) or false negative (the same object given as both operands for > `is` nevertheless returns False)? In the absence of any actual bugs in the > definition, I maintain that it is sufficient. You are not paying attention — the example above I gave in which python arbitrarily hi-handedly, inconsistently manifests different behavior between integer 1 and tuple (1,2) I am now dropping off this thread [more important things to do] with this observation: There are these strange wondrous things in the world called 'mothers' They take bawling shiing peeing pieces of fleshy exasperation called 'babies' And convert them into intelligent human beings Dunno how they do it… More easily: if I, knowing English, read a German-English dictionary its ok, a well-founded action — learning unknown-German via known-English But reading a 'normal' English-English dictionary like Webster, Oxford etc is borderline infinite recursion… And occasionally fails — ambiguities, grey areas Still it mostly works… with enough good faith However bootstrapping the whole process from absolute zero — the mothers' task — is frankly beyond my ken Bare (pure-philosophical, model-less) identity/sameness is analogous So… what you think is obvious and trivially intuitive — the bald fact of semantics and comprehension — is to me quite miraculous -- https://mail.python.org/mailman/listinfo/python-list
Re: The Incredible Growth of Python (stackoverflow.blog)
On Sunday, September 10, 2017 at 7:12:10 AM UTC+5:30, Gregory Ewing wrote: > Pavol Lisy wrote: > > Interesting reading: > > https://stackoverflow.blog/2017/09/06/incredible-growth-python/?cb=1 > > So, Python's rate of expansion is accelerating, like > the universe. Does that mean there's some kind of dark > energy fuelling its growth? Something to do with the small Hamming-distance between "God" and "Guido" ? -- https://mail.python.org/mailman/listinfo/python-list
Re: The Incredible Growth of Python (stackoverflow.blog)
On Sunday, September 10, 2017 at 3:15:32 PM UTC+5:30, Skip Montanaro wrote: > > * asyncio with its a-dialect > > What is a/the "a-dialect"? > > S I'd guess its the async/await (semi)keyworded python Compre with the (IMHO) better suggestion for codef/cocall https://lists.gt.net/python/dev/1197316?do=post_view_threaded -- https://mail.python.org/mailman/listinfo/python-list
Re: Python in Perspective
On Monday, September 11, 2017 at 3:08:51 AM UTC+5:30, [email protected] wrote: > On Sunday, September 10, 2017 at 11:21:26 AM UTC+1, Leam Hall wrote: > > y'all, > > > > My god-kids and their proginators lost most everything because of > > Harvey. I spent much of yesterday worrying about a friend who had gone > > quiet as he evacuated his family ahead of Irma. > > > > Please keep Python in perspective. Whether we use 1.5 or 4rc1 is a lot > > less critical than using Python to work together well and solving big > > problems as friends. > > > > In years gone by I spent time on the soapbox but never came away cleaner > > or with stronger friendships. I just ranted and spent years wondering > > why nothing actually changed. Please don't make my mistake; come up with > > your own. > > > > Together. As friends. > > > > Leam > > What do you have to say about the people who die every year in the monsoon, > as they are dying right now, as opposed to the occasional hurricane that hits > the richest nation in the world? Will Trump the Chump cure all the worlds > ills, or is he too busy looking after his highly paid mates in the oil and > gas industries, who are actively paying for the education system in some US > states to the detriment of facts, as in there is no man made global warming? Dont know whether to laugh or to weep http://time.com/4935117/hurricane-irma-guns-florida/ -- https://mail.python.org/mailman/listinfo/python-list
Re: The Incredible Growth of Python (stackoverflow.blog)
On Monday, September 11, 2017 at 12:51:59 PM UTC+5:30, Gregory Ewing wrote: > Chris Angelico wrote: > > Async functions in > > JS are an alternative to callback hell; most people consider async > > functions in Python to be an alternative to synchronous functions. > > What do you base that on? Seems to me async is an alternative > to callback-based frameworks such as Twisted. > > Calling async functions an alternative to sync functions > doesn't make sense, because if sync functions will do what > you want, there's no need to use async ones. The choice usually is: sync-functions-in-threads with lock-race-hell vs callback-hell -- https://mail.python.org/mailman/listinfo/python-list
Re: The Incredible Growth of Python (stackoverflow.blog)
On Monday, September 11, 2017 at 1:28:24 PM UTC+5:30, Marko Rauhamaa wrote: > Gregory Ewing: > > > Chris Angelico wrote: > >> Async functions in > >> JS are an alternative to callback hell; most people consider async > >> functions in Python to be an alternative to synchronous functions. > > > > What do you base that on? Seems to me async is an alternative > > to callback-based frameworks such as Twisted. > > > > Calling async functions an alternative to sync functions > > doesn't make sense, because if sync functions will do what > > you want, there's no need to use async ones. > > Asyncio makes it possible to write a single-threaded program in > multithreading style. > > The multithreading style means entwining the state of a finite state > machine in the form of the source code. While a callback-based program > will use one or more variables (object attributes) to store the state -- > or leave it implicit -- an asyncio program marks each state with the > "await" keyword. > > The multithreading style is convenient in cases where each state is > blocked on a single possible event. Trouble is, most state machines I > run into (and that's my bread and butter), each state is blocked on > several or even numerous alternative events. Do you have some reading material suggestions for grokking the a-world? -- https://mail.python.org/mailman/listinfo/python-list
Re: String to Dictionary conversion in python
On Saturday, September 16, 2017 at 2:04:39 AM UTC+5:30, [email protected] wrote: > On Thursday, September 14, 2017 at 11:33:56 PM UTC-7, Ian wrote: > > On Fri, Sep 15, 2017 at 12:01 AM, wrote: > > > Hi, > > > > > > Can anyone help me in the below issue. > > > > > > I need to convert string to dictionary > > > > > > string = " 'msisdn': '7382432382', 'action': 'select', 'sessionId': > > > '123', 'recipient': '7382432382', 'language': 'english'" > > > > > > Can anyone help me with the code > > > > It looks like this might do what you need: > > > > py> import ast > > py> string = " 'msisdn': '7382432382', 'action': 'select', > > 'sessionId': '123', 'recipient': '7382432382', 'language': 'english'" > > py> ast.literal_eval('{%s}' % string) > > {'sessionId': '123', 'recipient': '7382432382', 'msisdn': > > '7382432382', 'action': 'select', 'language': 'english'} > > Very clever! Yeah… I used to think thus But literal_eval has excessive crud in its error messages: >>> from ast import literal_eval >>> literal_eval("{'x':1}") {'x': 1} Ok… >>> literal_eval("{x:1}") Traceback (most recent call last): File "", line 1, in File "/usr/lib/python2.7/ast.py", line 80, in literal_eval return _convert(node_or_string) File "/usr/lib/python2.7/ast.py", line 63, in _convert in zip(node.keys, node.values)) File "/usr/lib/python2.7/ast.py", line 62, in return dict((_convert(k), _convert(v)) for k, v File "/usr/lib/python2.7/ast.py", line 79, in _convert raise ValueError('malformed string') ValueError: malformed string >>> literal_eval("'x':1") Traceback (most recent call last): File "", line 1, in File "/usr/lib/python2.7/ast.py", line 49, in literal_eval node_or_string = parse(node_or_string, mode='eval') File "/usr/lib/python2.7/ast.py", line 37, in parse return compile(source, filename, mode, PyCF_ONLY_AST) File "", line 1 'x':1 ^ SyntaxError: invalid syntax > And definitely not an answer that would be acceptable for a homework > assignment. 😇 -- https://mail.python.org/mailman/listinfo/python-list
Re: [Tutor] beginning to code
On Monday, September 18, 2017 at 5:23:49 PM UTC+5:30, Rick Johnson wrote:
> On Sunday, September 17, 2017 at 8:51:38 PM UTC-5, INADA Naoki wrote:
> > >
> > > >
> > > > I would agree that testing any of those for '== True' or
> > > > the like is pointless redundancy,
> > >
> > > But what's wrong with syntactical redundancy when it brings
> > > _clarity_ to the source code? And why can't Python be smart?
> > > Consider the collowing code:
> > >
> > > if bool(someObject) == True:
> > > # Do something
> > >
> > > Yes, from a "byte-code perspective", this source code is
> > > superfluous, but, from a source code perspective, this code
> > > is perfectly balanced between explicit and implicit.
> >
> > I can't agree with you. It's too redundant. It doesn't
> > provide any information about what coder think.
>
> It's not about what the "coder thinks", many times what the
> coder thinks is wrong, it's about writing code that is
> intuitive to as wide an audience as possible.
>
> > While PEP 8 recommends `if x:`, I accept `if x > 0` or `if
> > len(x) > 0` when I review code in my company.
>
> So when `x` is an iterable, as in:
>
> if len(x) > 0:
> # blah
>
> You're okay with the explicit test. Or when `x` is a
> numeric, as in:
>
> if x > 0:
> # blah
>
> You're okay with the explicit test. So, from a standpoint of
> consistency, you /should/ be okay with this:
>
> if bool(x) == True:
> # blah
>
> But you're not! :-).
I have a feeling Rick that you are mixing up two unrelated things:
- the bool(x) part
- the ... == True part
The operation
x == True
for true(!)/proper booleans x is a no-op
because True == True is True
and False == True is False
And there are no other (proper) booleans
However because anything else can be bool-ish even though not boolean
you need the bool(x) to effect the mapping:
{None, 0, "" {}, []} → False
Everything_else → True
This mapping is neither obvious nor trivial
And one could argue that leaving python to implicitly make [] (say) into False
should be documented
So if you drop the hangup with the red-herring ...==True
you have a point in asking for the bool(...)
--
https://mail.python.org/mailman/listinfo/python-list
Re: [Tutor] beginning to code
On Monday, September 18, 2017 at 6:25:09 PM UTC+5:30, Rustom Mody wrote:
> On Monday, September 18, 2017 at 5:23:49 PM UTC+5:30, Rick Johnson wrote:
> > On Sunday, September 17, 2017 at 8:51:38 PM UTC-5, INADA Naoki wrote:
> > > >
> > > > >
> > > > > I would agree that testing any of those for '== True' or
> > > > > the like is pointless redundancy,
> > > >
> > > > But what's wrong with syntactical redundancy when it brings
> > > > _clarity_ to the source code? And why can't Python be smart?
> > > > Consider the collowing code:
> > > >
> > > > if bool(someObject) == True:
> > > > # Do something
> > > >
> > > > Yes, from a "byte-code perspective", this source code is
> > > > superfluous, but, from a source code perspective, this code
> > > > is perfectly balanced between explicit and implicit.
> > >
> > > I can't agree with you. It's too redundant. It doesn't
> > > provide any information about what coder think.
> >
> > It's not about what the "coder thinks", many times what the
> > coder thinks is wrong, it's about writing code that is
> > intuitive to as wide an audience as possible.
> >
> > > While PEP 8 recommends `if x:`, I accept `if x > 0` or `if
> > > len(x) > 0` when I review code in my company.
> >
> > So when `x` is an iterable, as in:
> >
> > if len(x) > 0:
> > # blah
> >
> > You're okay with the explicit test. Or when `x` is a
> > numeric, as in:
> >
> > if x > 0:
> > # blah
> >
> > You're okay with the explicit test. So, from a standpoint of
> > consistency, you /should/ be okay with this:
> >
> > if bool(x) == True:
> > # blah
> >
> > But you're not! :-).
>
> I have a feeling Rick that you are mixing up two unrelated things:
> - the bool(x) part
> - the ... == True part
>
> The operation
> x == True
> for true(!)/proper booleans x is a no-op
> because True == True is True
> and False == True is False
> And there are no other (proper) booleans
>
> However because anything else can be bool-ish even though not boolean
> you need the bool(x) to effect the mapping:
>
> {None, 0, "" {}, []} → False
> Everything_else → True
>
> This mapping is neither obvious nor trivial
Sufficiently non-obvious that I missed the key element:
{None, 0, "" {}, [], False} → False
--
https://mail.python.org/mailman/listinfo/python-list
Re: [Tutor] beginning to code
On Tuesday, September 19, 2017 at 4:41:01 PM UTC+5:30, Antoon Pardon wrote:
> Op 19-09-17 om 11:22 schreef Steven D'Aprano:
> > Except for bools, where people freak out and are convinced the world will
> > end if you just ask an object "are you true or false?".
> >
> > Perhaps just a *tiny* exaggeration *wink*
>
> On the other hand, python is very eager to convert objects to a bool. For
> strings and iterators you are expected to write a dunder method. If you
> think it makes no sense to see specific instances as true or false, you
> have to explicitly write a __bool__ that raises an exception. I think
> it would have been a better choice that a TypeError would have been
> raised if __bool__ wasn't defined.
How exceptional is python's choice to NOT raise exceptions can be seen by
examples:
>>> [] + 2
Traceback (most recent call last):
File "", line 1, in
TypeError: can only concatenate list (not "int") to list
>>> [] < 0
Traceback (most recent call last):
File "", line 1, in
TypeError: unorderable types: list() < int()
>>> 1[2]
Traceback (most recent call last):
File "", line 1, in
TypeError: 'int' object is not subscriptable
>>> 2 < []
Traceback (most recent call last):
File "", line 1, in
TypeError: unorderable types: int() < list()
>>> len(2)
Traceback (most recent call last):
File "", line 1, in
TypeError: object of type 'int' has no len()
>>> [x for x in 1]
Traceback (most recent call last):
File "", line 1, in
TypeError: 'int' object is not iterable
>>> -[]
Traceback (most recent call last):
File "", line 1, in
TypeError: bad operand type for unary -: 'list'
>>> [] or []
[]
# Ah well... Same category as...
>>> ("empty" if [] else "nonempty")
'nonempty'
>>>
--
https://mail.python.org/mailman/listinfo/python-list
grapheme cluster library
Is there a recommended library for manipulating grapheme clusters? In particular, in devanagari क् + ि = कि in (pseudo)unicode names KA-letter + I-sign = KI-composite-letter I would like to be able to handle KI as a letter rather than two code-points. Can of course write an automaton to group but guessing that its already available some place… -- https://mail.python.org/mailman/listinfo/python-list
Re: grapheme cluster library
On Saturday, October 21, 2017 at 11:51:57 AM UTC+5:30, Chris Angelico wrote: > On Sat, Oct 21, 2017 at 3:25 PM, Stefan Ram wrote: > > Rustom Mody writes: > >>Is there a recommended library for manipulating grapheme clusters? > > > > The Python Library has a module "unicodedata", with functions like: > > > > |unicodedata.normalize( form, unistr ) > > | > > |Returns the normal form »form« for the Unicode string »unistr«. > > |Valid values for »form« are »NFC«, »NFKC«, »NFD«, and »NFKD«. > > > > . I don't know whether the transformation you are looking for > > is one of those. > > No, that's at a lower level than grapheme clusters. > > Rustom, have you looked on PyPI? There are a couple of hits, including > one simply called "grapheme". There is this one line solution using regex (or 2 char solution!) Not perfect but a good start >>> from regex import findall >>> veda="""ॐ पूर्णमदः पूर्णमिदं पूर्णात्पुर्णमुदच्यते पूर्णस्य पूर्णमादाय पूर्णमेवावशिष्यते ॥ ॐ शान्तिः शान्तिः शान्तिः ॥""" >>> findall(r'\X', veda) ['ॐ', ' ', 'पू', 'र्', 'ण', 'म', 'दः', ' ', 'पू', 'र्', 'ण', 'मि', 'दं', ' ', 'पू', 'र्', 'णा', 'त्', 'पु', 'र्', 'ण', 'मु', 'द', 'च्', 'य', 'ते', '\n', 'पू', 'र्', 'ण', 'स्', 'य', ' ', 'पू', 'र्', 'ण', 'मा', 'दा', 'य', ' ', 'पू', 'र्', 'ण', 'मे', 'वा', 'व', 'शि', 'ष्', 'य', 'ते', ' ', '॥', '\n', 'ॐ', ' ', 'शा', 'न्', 'तिः', ' ', 'शा', 'न्', 'तिः', ' ', 'शा', 'न्', 'तिः', ' ', '॥'] >>> Compare >>> [x for x in veda] ['ॐ', ' ', 'प', 'ू', 'र', '्', 'ण', 'म', 'द', 'ः', ' ', 'प', 'ू', 'र', '्', 'ण', 'म', 'ि', 'द', 'ं', ' ', 'प', 'ू', 'र', '्', 'ण', 'ा', 'त', '्', 'प', 'ु', 'र', '्', 'ण', 'म', 'ु', 'द', 'च', '्', 'य', 'त', 'े', '\n', 'प', 'ू', 'र', '्', 'ण', 'स', '्', 'य', ' ', 'प', 'ू', 'र', '्', 'ण', 'म', 'ा', 'द', 'ा', 'य', ' ', 'प', 'ू', 'र', '्', 'ण', 'म', 'े', 'व', 'ा', 'व', 'श', 'ि', 'ष', '्', 'य', 'त', 'े', ' ', '॥', '\n', 'ॐ', ' ', 'श', 'ा', 'न', '्', 'त', 'ि', 'ः', ' ', 'श', 'ा', 'न', '्', 'त', 'ि', 'ः', ' ', 'श', 'ा', 'न', '्', 'त', 'ि', 'ः', ' ', '॥'] What is not working are the vowel-less consonant-joins: ie ... 'र्', 'ण' ... [3,4 element of the findall] should be one 'र्ण' But its good enough for me for now I think PS Stefan I dont see your responses unless someone quotes them. Thanks anyway for the inputs -- https://mail.python.org/mailman/listinfo/python-list
Re: grapheme cluster library
On Saturday, October 21, 2017 at 9:22:24 PM UTC+5:30, MRAB wrote:
> On 2017-10-21 05:11, Rustom Mody wrote:
> > Is there a recommended library for manipulating grapheme clusters?
> >
> > In particular, in devanagari
> > क् + ि = कि
> > in (pseudo)unicode names
> > KA-letter + I-sign = KI-composite-letter
> >
> > I would like to be able to handle KI as a letter rather than two
> > code-points.
> > Can of course write an automaton to group but guessing that its already
> > available some place…
> >
> You can use the regex module to split a string into graphemes:
>
> regex.findall(r'\X', string)
Thanks MRAB
Yes as I said I discovered r'\X'
Ultimately my code was (effectively) one line!
print("".join(map[x] for x in findall(r'\X', l)))
with map being a few 100 elements of a dictionary such as
map = {
...
'ॐ': "OM",
...
}
$ cat purnam-deva
ॐ पूर्णमदः पूर्णमिदं पूर्णात्पुर्णमुदच्यते
पूर्णस्य पूर्णमादाय पूर्णमेवावशिष्यते ॥
$ ./devanagari2roman.py purnam-deva
OM pUraNamadaH pUraNamidaM pUraNAtpuraNamudachyate
pUraNasya pUraNamAdAya pUraNamavAvashiShyate ..
OM shAntiH shAntiH shAntiH ..
Basically, an inversion of the itrans input method
https://en.wikipedia.org/wiki/ITRANS
--
https://mail.python.org/mailman/listinfo/python-list
