Reason for not allowing import twice but allowing reload()
On Monday, February 29, 2016 at 6:53:09 PM UTC+5:30, alien...@gmail.com wrote:
> Hello Rustom,
>
> F5 in Idle restarts the Python interpreter (that's what my impression is).
> Whatever you have done earlier at Idle prompt (in Idle session) before F5 is
> gone after F5.
>
> Try simple experiment at prompt.
>
> >>> myvar="hello"
> >>> myvar
> 'hello'
>
> myvar is gone after F5.
>
> As for need of import in Idle session, I use it to
> - import sys
> - sys.append.path('D:\\Where\\Ever\\My\\Modules\\Lie')
> - import mymodule
Why does one use (something like) idle?
To experiment.
So what's your experiment-focus?
If it is mymodule then mymodule should be open in idle file window and idle
will take care of paths
If its someothermodule.py that has an import of mymodule.py then
someothermodule should be handling the paths issue.
In neither case I see a reason to do it at idle prompt
[At least that's my understanding, hope an idle expert will weigh in on this]
In linux this question does not typically arise as one starts idle from the
shell in the same directory as the python files one wants to play with
In windows... not sure of idiom...
Maybe right-click the idle icon and change its 'start-in' to the path where
your python files are situated?
My general impression (best-practices not semantics) is that changing sys.path
is allowed but hackish.
1. Modify sys.path
2. Using PYTHONPATH env variable
3. Use relative imports
4. Use packages
?. .pth files
is roughly decreasing in hackishness though unfortunately increasing in
sophistication
http://stackoverflow.com/questions/19917492/how-to-use-pythonpath
http://stackoverflow.com/questions/18521503/pydev-how-to-avoid-adding-sub-directories-to-python-path-in-order-to-fix-unres
--
https://mail.python.org/mailman/listinfo/python-list
Correct IDLE usage (was Reason for not allowing import twice but allowing reload())
On Monday, February 29, 2016 at 12:10:28 PM UTC+5:30, alien2utoo wrote: > Hello list, > > We can not import a module twice in a session of Python (subsequent attempts > to import same module don't result in any error though, but it is > not-effective). > > However after making change to module, we can reload() it (if not reload(), > we could possibly have reimport statement) to get the updates in module. > > I am a newbie in Python (learning via IDLE) and trying to understand > Hi and welcome! > - what is extra (special) that import does, that reload() doesn't? > - if both do the same internally and externally, why subsequent imports of > same module are ineffective? > - if subsequent imports of same module in a session are not effective, why > not simply flag those attempts as an error, rather than letting them go > effect-less. > > Kindly help me understand the reasons behind. I guess Ian and Chris have answered well enough in a general way. However I wonder at a more pragmatic level: Is import needed at all when trying out in Idle? [Maybe Idle experts can comment...] In more detail: 1. Start idle 2. Open new with Ctrl-n 3. Put the following into foo.py --- x = 3 def foo(y) : return x+y --- 4. Load it into python with F5 (or Run-> Run_Module) And have this interaction >>> RESTART >>> >>> x 3 >>> foo(2) 5 Note the restart 5. Switch back to foo.py and change the '+' to '*'; F5 >>> RESTART >>> >>> foo(2) 6 SO THE CHANGE IS EFFECTED 6. Yes there is a difference between importing and 'F5-ing'; To see that I add to bottom of foo.py if __name__ == '__main__': print "if" else: print "else" 7. Now with F5: >>> RESTART >>> if Whereas with import: >>> import foo else >>> So it does appear that 1. import not necessary with(in) idle 2. However import and f5 (ie is run as main) are different May some idle experts elaborate on this? Whats the idle idiom of import-ing? -- https://mail.python.org/mailman/listinfo/python-list
Re: Everything good about Python except GUI IDE?
On Monday, February 29, 2016 at 11:48:25 AM UTC+5:30, Marko Rauhamaa wrote: > Gordon Levi : > > > Nobody likes filling in forms but how do you suggest converting a form > > based app into something loveable. > > Straight HTML does forms just fine without CSS or JavaScript, yet few > can resist. Abjure JS/CSS is a virtue? Why? In any case with or without its still a form not plain (printf/scanf) text. So what exactly are we talking of? > > > What interface would make you love adding a new contact to your > > address book? > > In my case, the address book is a ~/.mailrc file, which I edit using > emacs. Even in the emacs world people find this painful enough that they use tools like bbdb and more modern ones like org-contacts -- https://mail.python.org/mailman/listinfo/python-list
Re: Lineendings (was Everything good about Python except GUI IDE?)
On Monday, February 29, 2016 at 8:05:33 AM UTC+5:30, Ben Finney wrote: > Rustom Mody writes: > > > On Monday, February 29, 2016 at 7:33:18 AM UTC+5:30, Chris Angelico wrote: > > > Never has for any of my projects. Examples please? Actual real > > > problems? I've been using git for years, on mixed platforms for a lot > > > of that, and not had a single problem. > > > > Pragmatically: As I said just search stackoverflow for git:crlf > > Don't ask Chris to *guess* which search results are representative of > what you're asserting. Please provide concrete examples that demonstrate > specifically what you're describing. I was answering Chris' specific "Never has for any of my projects" by saying there are dozens of questions about this (FAQ) on stackoverflow 1st one it gives: http://stackoverflow.com/questions/170961/whats-the-best-crlf-carriage-return-line-feed-handling-strategy-with-git Also some discussions by git devs: https://groups.google.com/forum/#!topic/msysgit/Gb5tlbfEyPk There are more acrimonious dev-exchanges that can be hunted down Nevertheless my basic point is somehow a bit different: A text file (content) is a list of lines A line is a list of char A char is... wont open that can of worms! If git says it stores EOL as LF and can convert to LF or CRLF on demand there itself is the leaked abstraction. Knowing that git uses LF internally should be as relevant as say machine endianness is to how python stores the tuple (1,2) -- https://mail.python.org/mailman/listinfo/python-list
Re: Lineendings (was Everything good about Python except GUI IDE?)
On Monday, February 29, 2016 at 7:33:18 AM UTC+5:30, Chris Angelico wrote: > On Mon, Feb 29, 2016 at 12:55 PM, Rustom Mody wrote: > > On Monday, February 29, 2016 at 7:20:19 AM UTC+5:30, Chris Angelico wrote: > >> On Mon, Feb 29, 2016 at 12:39 PM, Rustom Mody wrote: > >> > Unfortunately that's the outlook all major VCSes (not just git) have > >> > started > >> > with and its wrong. > >> > Speaking somewhat simplistically: > >> > On windows one should see CRLF > >> > On *nix LF > >> > And this SHOULD NOT be a diff! > >> > [Assuming the VCS is serious about collaboration] > >> > > >> > >> If you want this, simply run this on your Windows computer: > >> > >> git config --global core.autocrlf true > >> > >> Job done. The repo will record LF, but you'll get CRLF on the Windows > >> box. Alternatively, if you're happy with LF on Windows, but want > >> protection against accidentally checking in a CRLF: > >> > >> git config --global core.autocrlf input > >> > >> Either way, this means that line endings get folded to LF for consistency. > >> > >> ChrisA > > > > Just check stackoverflow for how often this FAILS to work > > Never has for any of my projects. Examples please? Actual real > problems? I've been using git for years, on mixed platforms for a lot > of that, and not had a single problem. Pragmatically: As I said just search stackoverflow for git:crlf Theoretically: Its a borked (leaky) abstraction -- https://mail.python.org/mailman/listinfo/python-list
Re: Lineendings (was Everything good about Python except GUI IDE?)
On Monday, February 29, 2016 at 7:20:19 AM UTC+5:30, Chris Angelico wrote: > On Mon, Feb 29, 2016 at 12:39 PM, Rustom Mody wrote: > > Unfortunately that's the outlook all major VCSes (not just git) have started > > with and its wrong. > > Speaking somewhat simplistically: > > On windows one should see CRLF > > On *nix LF > > And this SHOULD NOT be a diff! > > [Assuming the VCS is serious about collaboration] > > > > If you want this, simply run this on your Windows computer: > > git config --global core.autocrlf true > > Job done. The repo will record LF, but you'll get CRLF on the Windows > box. Alternatively, if you're happy with LF on Windows, but want > protection against accidentally checking in a CRLF: > > git config --global core.autocrlf input > > Either way, this means that line endings get folded to LF for consistency. > > ChrisA Just check stackoverflow for how often this FAILS to work -- https://mail.python.org/mailman/listinfo/python-list
Lineendings (was Everything good about Python except GUI IDE?)
On Monday, February 29, 2016 at 6:09:33 AM UTC+5:30, Steven D'Aprano wrote: > On Mon, 29 Feb 2016 01:26 am, Chris Warrick wrote: > > >> git is a *collaborative* tool and should work when the other party is > >> using notepad. > > > > What should git do if someone saves, say, Ruby code as a .py file? > > Should it rename it? Or should it figure out an equivalent snippet of > > Python? > > Don't be ridiculous. That's completely over the top. > > It isn't asking too much for version control systems to *not care* about > line ending changes. Who cares if the file changes from \n to \r \r\n? It > shouldn't matter, or at least, it shouldn't matter much. Unfortunately that's the outlook all major VCSes (not just git) have started with and its wrong. Speaking somewhat simplistically: On windows one should see CRLF On *nix LF And this SHOULD NOT be a diff! [Assuming the VCS is serious about collaboration] Analogy: I stick my flash drive into linux and get /media/rusi/Transcend On windows (I guess) its H:\Transcend The SAME files and filesystem should be thus different right? .gitattributes does make these (declarations) possible ... in a half-assed afterthought sort of way with safecrlf and autocrlf as earlier poor bug-ridden bugfixes -- https://mail.python.org/mailman/listinfo/python-list
Re: Everything good about Python except GUI IDE?
On Sunday, February 28, 2016 at 7:57:17 PM UTC+5:30, Chris Warrick wrote: > (Notepad does not understand LF line endings and replaces them with > boxes. I also don't think a Notepad user is likely to provide good > contributions, but that's another thing) You seem to have not worked in a web dev team wherein the frontend guys only know 3 tools - dreamweaver - photoshop - notepad -- https://mail.python.org/mailman/listinfo/python-list
Re: Everything good about Python except GUI IDE?
On Sunday, February 28, 2016 at 8:38:49 PM UTC+5:30, Marko Rauhamaa wrote: > Rustom Mody : > > > On Sunday, February 28, 2016 at 7:22:08 PM UTC+5:30, Marko Rauhamaa wrote: > >> Rustom Mody : > >> > >> > whereas in fact every significant GUI embeds text (possibly > >> > recursively) > >> > > >> > eg TI inside GUI -- think of text inside gimp GUI inside TI -- > >> > think of Word embedding other doc types including pictures Which > >> > can be recursive -- WOrd embeds a picture embeds text > >> > >> Sigh, still nobody has mentioned an exemplary GUI application. > >> > >> An anecdote: Some weeks back my son and I were struggling to get the > >> right kind of graph out of Excel. After four hours of Google, > >> Youtube, trial and error, we gave up, took out a pad of millimeter > >> paper and some colored pencils. The whole job took my son an hour and > >> the end result looked great. He snapped a picture and sent it to the > >> teacher by email. > > > > Point being?? > > I'm awaiting for an opposite anecdote, a GUI app you absolutely love and > recommend as a model for GUI developers. GUI app I absolutely love... um hard But what does it prove? Best I can see it proves I am an old (Unix) geezer brought up on text files :-) Still as an approximation... I edit audio with audacity And type music with musescore Both could be better (And Ive heard people swear by ardour... No experience myself) The alternative -- stay with lilypond workflow -- is too primitive In particular if musescore could input and output to lilypond or some such it would have been optimal ...for me; ie clickety clicking 100s of notes is painful compared to typing them in say emacs For a much more professional pianist friend: He connects a small 2 octave keyboard to his mac Plays out what he needs to enter And then cleans it up... in Sibelius > > We are talking about GUI tools to produce what? Crap? You (seem to) be saying that excel is crap. Do you know it well enough to make that judgement? Do you have equivalent functionality in some other tool? -- https://mail.python.org/mailman/listinfo/python-list
Re: Everything good about Python except GUI IDE?
On Sunday, February 28, 2016 at 7:30:57 PM UTC+5:30, Chris Warrick wrote: > On 28 February 2016 at 14:49, Rustom Mody wrote: > > On Sunday, February 28, 2016 at 6:54:40 PM UTC+5:30, Gordon Levi wrote: > >> Rustom Mody wrote: > >> >Glade generates XML (last I saw) > >> >XML is text... kinda... but not quite > >> >eg XML is sometimes/somewhere space sensitive, sometimes not > >> >This can generate messy diffs > >> > >> That is also true of Python code but does not preclude effective > >> source control. > > > > Yes as I said its not satisfactory but not impossible to manage > > > > Heck Current state of art VCSes cannot even manage mismatching EOL > > conventions > > cleanly. > > And as usual they make a virtue out of the lack: > > "git stores binary data not text" > > > > which means that opening a file created on windows on linux and saving it in > > WITHOUT a SINGLE CHANGE > > can give you a 10,000 line diff!! > > > 2. A good editor can read and write any newline style. It should also > not convert without asking the user. git is a *collaborative* tool and should work when the other party is using notepad. > 1. git can manage EOL changing if you want to enforce a newline style that > way. Only out-of-band You store autocrlf etc in your config not in the repo [And pray that the other (semi-literate) collaborator does likewise] > You clearly haven't ever done that. You specialize in crystal balls? Here's my report about CRLF issues in CPython https://mail.python.org/pipermail/python-dev/2015-June/140563.html Bug report: http://bugs.python.org/issue24507 -- https://mail.python.org/mailman/listinfo/python-list
Re: Everything good about Python except GUI IDE?
On Sunday, February 28, 2016 at 7:22:08 PM UTC+5:30, Marko Rauhamaa wrote: > Rustom Mody : > > > whereas in fact every significant GUI embeds text (possibly recursively) > > > > eg TI inside GUI -- think of text inside gimp > > GUI inside TI -- think of Word embedding other doc types including pictures > > Which can be recursive -- WOrd embeds a picture embeds text > > Sigh, still nobody has mentioned an exemplary GUI application. > > An anecdote: Some weeks back my son and I were struggling to get the > right kind of graph out of Excel. After four hours of Google, Youtube, > trial and error, we gave up, took out a pad of millimeter paper and some > colored pencils. The whole job took my son an hour and the end result > looked great. He snapped a picture and sent it to the teacher by email. Point being?? If I tried to speak Finnish I'd look a fool. Makes me a fool? Best I can see you dont know excel [Nor do I] Lets guess that you've spent 10 hours struggling with excel Now compare with how much with programming and 'classical' CS Would a couple of thousand hours be an overestimate? Is the inherent difficulty of excel to programming consistent with that ratio? > > A 2nd anecdote. I occasionally need to make technical presentations to > an audience. Do I use PowerPoint or Impress? No, I use emacs, M-x > picture-mode and raw HTML (without styles). I get to concentrate on > producing effective communication, and nobody has complained about the > lack of imagery or funny animation. Yeah so do I emacs → org mode → export html Works but not ideal -- https://mail.python.org/mailman/listinfo/python-list
Re: Everything good about Python except GUI IDE?
On Sunday, February 28, 2016 at 6:54:40 PM UTC+5:30, Gordon Levi wrote: > Rustom Mody wrote: > >Glade generates XML (last I saw) > >XML is text... kinda... but not quite > >eg XML is sometimes/somewhere space sensitive, sometimes not > >This can generate messy diffs > > That is also true of Python code but does not preclude effective > source control. Yes as I said its not satisfactory but not impossible to manage Heck Current state of art VCSes cannot even manage mismatching EOL conventions cleanly. And as usual they make a virtue out of the lack: "git stores binary data not text" which means that opening a file created on windows on linux and saving it in WITHOUT a SINGLE CHANGE can give you a 10,000 line diff!! -- https://mail.python.org/mailman/listinfo/python-list
Re: Everything good about Python except GUI IDE?
On Sunday, February 28, 2016 at 6:37:49 PM UTC+5:30, BartC wrote: > On 28/02/2016 12:54, Rustom Mody wrote: > > On Sunday, February 28, 2016 at 6:08:44 PM UTC+5:30, BartC wrote: > > >> You have to give someone some shopping to do. What's quicker, jotting > >> down a list of milk, bread, eggs and so on, or invoking some GUI program > >> where you have to first look for each category, then have to choose the > >> exact subcategory, size, quantity... > > > > Dunno what that has to do with GUI > > It seems to be to do with 'coding-up' > > > It's comparing a drag-and-drop approach with just writing a list or > script using text. And in a situation where there can be thousands of > possibilities. > > To extend it further, imagine having to write a document using a mouse > rather than a keyboard. And doing so by having to bring up the right > word each time and drag it into place. It would take forever. > > Going back to GUI for creating dialogs, it just doesn't work for me > (admittedly I've never tried it except for some tinkering decades ago). > The first dialog I create will be bound to have a conditional layout > which depends on parameters now known until runtime. Or when one element > has a dependency on another. Your argument assumes GUI = not Text Interface whereas in fact every significant GUI embeds text (possibly recursively) eg TI inside GUI -- think of text inside gimp GUI inside TI -- think of Word embedding other doc types including pictures Which can be recursive -- WOrd embeds a picture embeds text -- https://mail.python.org/mailman/listinfo/python-list
Re: Everything good about Python except GUI IDE?
On Sunday, February 28, 2016 at 6:38:40 PM UTC+5:30, Gordon Levi wrote: > Chris Angelico wrote: > > >On Sun, Feb 28, 2016 at 9:25 PM, Rustom Mody wrote: > >> Code is always the last resort for arbitrary complexity > >> Lets keep it the last resort. > >> > >> If the bottom-line is that python's GUI-builders are so deep into suxland > >> that they are best avoided in place of hand-written code, thats fine (by > >> me). > >> > >> Lets please not make a virtue of a lack > > > >Once someone figures out a way to usefully merge independent changes > >(you know, the way source control tools do every single day for code), > >maybe I'll consider that. Until then, the last resort is also my first > >response. > > Why can't whatever is generated by a GUI form designer be stored in > source control along with all the other project files? The only > restriction would be that everyone who wants to change the UI would > have to use the same form designer. Glade generates XML (last I saw) XML is text... kinda... but not quite eg XML is sometimes/somewhere space sensitive, sometimes not This can generate messy diffs Best I can see, these are not exactly trivial nor quite impossible to solve problems -- https://mail.python.org/mailman/listinfo/python-list
Re: Everything good about Python except GUI IDE?
On Sunday, February 28, 2016 at 6:08:44 PM UTC+5:30, BartC wrote: > On 28/02/2016 06:34, Steven D'Aprano wrote: > > > GUI elements are by definition graphical in nature, and like other graphical > > elements, manipulation by hand is superior to command-based manipulation. > > Graphical interfaces for manipulating graphics have won the UI war so > > effectively that some people have forgotten there ever was a war. Can you > > imagine using Photoshop without drag and drop? > > > > And yet programming those graphical interfaces is an exception. There, with > > very few exceptions, we still *require* a command interface. Not just a > > command interface, but an *off-line* command interface, where you batch up > > all your commands then run them at once, as if we were Neanderthals living > > in a cave. > > You've got that back to front. > > It's the GUI users who are the Neanderthals, having to effectively point > at things with sticks. Or have to physically move that rock themselves > (ie. drag a file to a wastebasket). Creature A: Plays with a toy -- usually called 'child' Creature B: Makes toys, possibly designs new ones... Can be child Are these same? Steven is talking of GUI *programmers* You are talking of GUI *users* > > More advanced uses have the power of language, with all its > sophistications (ie. commands lines and scripting). And they don't need > to move that rock, they can tell someone else to do it! But with far > more control: all rocks of a certain size and colour, and at sunrise > tomorrow. You seem to have a rather limited view of language. Math is a language Music is a language -- and sophisticated music analysis can slot music according to genre etc So also GUIs > > Some things are just more easily described with a script or formula or > algorithm which is then 'rendered' to produce the result. Not quite > right? Change one parameter to re-render to instantly produce a new > version, that would have taken minutes or hours to do manually. > > > An effective and modern GUI builder UI should be programmable without > > requiring programming. About thirty years ago Apple came up with the ideal > > mix of graphical and programmatic development for its Hypercard product. > > You built applications by dragging and dropping widgets on the screen, or > > by copying and pasting them from a library of pre-made widgets. > > You have to give someone some shopping to do. What's quicker, jotting > down a list of milk, bread, eggs and so on, or invoking some GUI program > where you have to first look for each category, then have to choose the > exact subcategory, size, quantity... Dunno what that has to do with GUI It seems to be to do with 'coding-up' The string "milk" codes up milk more efficiently than category navigation and manipulation That programmers are 50 years behind laypersons in terms of computer USAGE: http://blog.languager.org/2013/09/poorest-computer-users-are-programmers.html -- https://mail.python.org/mailman/listinfo/python-list
Re: Everything good about Python except GUI IDE?
On Sunday, February 28, 2016 at 2:15:10 PM UTC+5:30, Chris Angelico wrote: > On Sun, Feb 28, 2016 at 5:34 PM, Steven D'Aprano wrote: > > On Sat, 27 Feb 2016 11:07 pm, Chris Angelico wrote: > > > >>> Isn't there any good GUI IDE like Visual Basic? I hope there are some > >>> less well known GUI IDEs which I did not come across. Thanks. > >> > >> Sounds like the advantage lies with Python here... > >> > >> Don't make a UI by dragging and dropping that many widgets. > > > > > > And later, in another post: > > > >> the best way to build a cross-platform GUI is code, not drag-and-drop. > > > > > > I think that's out-and-out wrong, and harmful to the developer community. I > > think that we're stuck in the equivalent of the pre-WYSIWYG days of word > > processing: you can format documents as nicely as you like, but you have to > > use a separate mode to see it. > > > > Drag-and-drop GUI builders have the same advantages over code as Python has > > over languages with distinct compile/execute steps: rapid development, > > prototyping, exploration and discovery. Of course, any decent modern > > builder won't limit you to literally drag-and-drop, but will offer > > functionality like duplicating elements, aligning them, magnetic guides, > > etc. > > Alright, but how do you go about doing, with a drag-and-drop builder, > all those things we're used to with code - composing new named actions > out of primitives, observing the changes to a program through source > control, unit testing (maybe), and code review? The only way I know of > to build a "function" in a DnD builder is to create a composite widget > (eg "horizontal box containing label and entry field"), which is > extremely useful, but limited - it's like saying that the only way to > reuse code is single-inheritance. How would you create a higher-order > operation in a DnD builder? How would you write something that does > some sort of sweep over a set of widgets and does the same thing to > them? Alright... I can handcraft better assembly than gcc generates. Shall I ditch gcc for assembly? And I can work out more sophisticated memory mgmt and other algos with C than with python (vide Steven's recent thread on delimiter-reading), Shall we prefer C over python? Moore's law dictates that "penny-wise, pound-foolish" gets multiplied by an exponential curve and the 'really-wise' puts up with a low(er) level mess for a higher level good. Sure the well handcrafted gui code will be smaller, neater, faster, what-have-u than builder=generated code. So what? The only reasonable answer is the corollary to Moore's law: The (differential) cost of programmer-time increases exponentially > > All these sorts of things are possible... but we're getting right back > to code again. People have tried to create graphical code builders for > decades; they've never been sufficient. Code - textual commands to > manipulate a system - is still the most powerful and flexible way to > do things. > > By the way, you'll notice that I said "dragging and dropping **that > many** widgets" (emphasis added). GUI builders can be great for simple > jobs, and a really awesome one can work well for more complex jobs > too, but the asymptotic complexity of using drag and drop is worse > than that of code. Code is always the last resort for arbitrary complexity Lets keep it the last resort. If the bottom-line is that python's GUI-builders are so deep into suxland that they are best avoided in place of hand-written code, thats fine (by me). Lets please not make a virtue of a lack -- https://mail.python.org/mailman/listinfo/python-list
Re: Everything good about Python except GUI IDE?
On Sunday, February 28, 2016 at 12:04:52 PM UTC+5:30, Steven D'Aprano wrote: > On Sat, 27 Feb 2016 11:07 pm, Chris Angelico wrote: > > >> Isn't there any good GUI IDE like Visual Basic? I hope there are some > >> less well known GUI IDEs which I did not come across. Thanks. > > > > Sounds like the advantage lies with Python here... > > > > Don't make a UI by dragging and dropping that many widgets. > > > And later, in another post: > > > the best way to build a cross-platform GUI is code, not drag-and-drop. > > > I think that's out-and-out wrong, and harmful to the developer community. I > think that we're stuck in the equivalent of the pre-WYSIWYG days of word > processing: you can format documents as nicely as you like, but you have to > use a separate mode to see it. > > Drag-and-drop GUI builders have the same advantages over code as Python has > over languages with distinct compile/execute steps: rapid development, > prototyping, exploration and discovery. Of course, any decent modern > builder won't limit you to literally drag-and-drop, but will offer > functionality like duplicating elements, aligning them, magnetic guides, > etc. > > GUI elements are by definition graphical in nature, and like other graphical > elements, manipulation by hand is superior to command-based manipulation. > Graphical interfaces for manipulating graphics have won the UI war so > effectively that some people have forgotten there ever was a war. Can you > imagine using Photoshop without drag and drop? > > And yet programming those graphical interfaces is an exception. There, with > very few exceptions, we still *require* a command interface. Not just a > command interface, but an *off-line* command interface, where you batch up > all your commands then run them at once, as if we were Neanderthals living > in a cave. > > An effective and modern GUI builder UI should be programmable without > requiring programming. About thirty years ago Apple came up with the ideal > mix of graphical and programmatic development for its Hypercard product. > You built applications by dragging and dropping widgets on the screen, or > by copying and pasting them from a library of pre-made widgets. > > (By 2016 standards the UI of Hypercard would seem a bit old fashioned and > primitive -- black and white, bitmapped graphics, no magnetic guides > or "replicate" command, etc -- but it was the mid 80s. A modern GUI builder > wouldn't have those limitations.) > > Hypercard let you create a place widgets by hand using the mouse, or by > running a one-line command in the "Message Box" (a simple command > interpreter), and for complex tasks, or by writing a script and executing > it. You didn't have to script the *entire* application, just as much or as > little as needed scripting. > > Python would be especially well-suited to this, being an interpreter. Why > should I have to batch up all the GUI elements and run them all at once to > see what my application looks like? Why can't I add elements interactively? > > I've made a number of attempts to get into GUI development in Python, and > every time I flounder at the lousy state of the art in GUI builder tools. > Yes, the widget set is fantastic. But putting the GUIs together is > primitive beyond words. > > Hypercard, bless Bill Atkinson, is long gone but not forgotten. But today it > lives on in the guise of LiveCode: > > http://livecode.com/ > > > If only I could get the Linux installer to actually, you know, *work*. > > > -- > Steven A sensible view And more helpful than pretending that neanderthal == civilized Chris: Is it easier to work out the best-lookkng colors with a color picker or with hacking through a million #rrggbb combos? -- https://mail.python.org/mailman/listinfo/python-list
Re: Error in Tree Structure
On Saturday, February 27, 2016 at 2:47:53 PM UTC+5:30, subhaba...@gmail.com
wrote:
> I was trying to implement the code,
>
> import nltk
> import nltk.tag, nltk.chunk, itertools
> def ieertree2conlltags(tree, tag=nltk.tag.pos_tag):
> words, ents = zip(*tree.pos())
> iobs = []
> prev = None
> for ent in ents:
> if ent == tree.node:
> iobs.append('O')
> prev = None
> elif prev == ent:
> iobs.append('I-%s' % ent)
> else:
> iobs.append('B-%s' % ent)
> prev = ent
> words, tags = zip(*tag(words))
> return itertools.izip(words, tags, iobs)
>
> def ieer_chunked_sents(tag=nltk.tag.pos_tag):
> for doc in ieer.parsed_docs():
> tagged = ieertree2conlltags(doc.text, tag)
> yield nltk.chunk.conlltags2tree(tagged)
>
>
> from chunkers import ieer_chunked_sents, ClassifierChunker
> from nltk.corpus import treebank_chunk
> ieer_chunks = list(ieer_chunked_sents())
> chunker = ClassifierChunker(ieer_chunks[:80])
> print chunker.parse(treebank_chunk.tagged_sents()[0])
> score = chunker.evaluate(ieer_chunks[80:])
> print score.accuracy()
>
> It is running fine.
> But as I am trying to rewrite the code as,
> chunker = ClassifierChunker(list1),
> where list1 is same value as,
> ieer_chunks[:80]
> only I am pasting the value as
> [Tree('S', [Tree('LOCATION', [(u'NAIROBI', 'NNP')]), (u',', ','),
> Tree('LOCATION', [(u'Kenya', 'NNP')]), (u'(', '('), Tree('ORGANIZATION',
> [(u'AP', 'NNP')]), (u')', ')'), (u'_', 'NNP'), Tree('CARDINAL',
> [(u'Thousands', 'NNP')]), (u'of', 'IN'), (u'laborers,', 'JJ'), (u'students',
> 'NNS'), (u'and', 'CC'), (u'opposition', 'NN'), (u'politicians', 'NNS'),
> (u'on', 'IN'), Tree('DATE', [(u'Saturday', 'NNP')]), (u'protested', 'VBD'),
> (u'tax', 'NN'), (u'hikes', 'NNS'), (u'imposed', 'VBN'), (u'by', 'IN'),
> (u'their', 'PRP$'), (u'cash-strapped', 'JJ'), (u'government,', 'NN'),
> (u'which', 'WDT'), (u'they', 'PRP'), (u'accused', 'VBD'), (u'of', 'IN'),
> (u'failing', 'VBG'), (u'to', 'TO'), (u'provide', 'VB'), (u'basic', 'JJ'),
> (u'services.', 'NN'),(u'(cm-kjd)', 'NN')])]
> the value of whole list directly I am getting syntax error.
Dunno how literally you intend this but there is a "" near the end
of the list. Intended?
--
https://mail.python.org/mailman/listinfo/python-list
Re: Everything good about Python except GUI IDE?
On Saturday, February 27, 2016 at 4:49:21 PM UTC+5:30, wrong.a...@gmail.com wrote: > I have some VB forms with more than a hundred objects. If I cannot drag and > drop text boxes, list boxes, labels, etc., it will be too much work to create > that with several lines of code for each object. > > Isn't there any good GUI IDE like Visual Basic? I hope there are some less > well known GUI IDEs which I did not come across. Thanks. Good... I do not know [Do not know much of the area] However there is glade, qtdesigner, wxglade for gtk, qt and wx. How full-featured/bug-free etc I cannot say. If you find that they just dont match up to what windows has on offer, I wont be surprised :-( -- https://mail.python.org/mailman/listinfo/python-list
Re: How the heck does async/await work in Python 3.5
On Saturday, February 20, 2016 at 10:55:02 AM UTC+5:30, Rustom Mody wrote: > On Saturday, February 20, 2016 at 8:07:03 AM UTC+5:30, Steven D'Aprano wrote: > > On Thu, 18 Feb 2016 09:08 am, Mark Lawrence wrote: > > > > > Seeing there is a lot of interest in asyncio recently I figured people > > > might be interested in this > > > http://www.snarky.ca/how-the-heck-does-async-await-work-in-python-3-5 > > > > > > Thanks for the link, but I'm now no wiser than I was before :-( > > > > Can somebody explain Brett's explanation? > > Does "C++" light a bulb? > > Less snarkily looks like a series of bolt-ons after bolt-ons > > IMHO Guido's (otherwise) uncannily sound intuitions have been wrong right from > 2001 when he overloaded def for generators. > And after that its been slippery-slope down: reusing generator-yield > (statement) > for coroutine-yield (expression) > Most recently choosing these async-await keywords instead of the more > symmetric > suggestions of Greg Ewing Forgot the probably most important: Not merging stackless into CPython -- https://mail.python.org/mailman/listinfo/python-list
Re: How the heck does async/await work in Python 3.5
On Saturday, February 20, 2016 at 8:07:03 AM UTC+5:30, Steven D'Aprano wrote: > On Thu, 18 Feb 2016 09:08 am, Mark Lawrence wrote: > > > Seeing there is a lot of interest in asyncio recently I figured people > > might be interested in this > > http://www.snarky.ca/how-the-heck-does-async-await-work-in-python-3-5 > > > Thanks for the link, but I'm now no wiser than I was before :-( > > Can somebody explain Brett's explanation? Does "C++" light a bulb? Less snarkily looks like a series of bolt-ons after bolt-ons IMHO Guido's (otherwise) uncannily sound intuitions have been wrong right from 2001 when he overloaded def for generators. And after that its been slippery-slope down: reusing generator-yield (statement) for coroutine-yield (expression) Most recently choosing these async-await keywords instead of the more symmetric suggestions of Greg Ewing PS. Will be off email/net for about a week -- https://mail.python.org/mailman/listinfo/python-list
Re: Python keyword args can be any string
On Thursday, February 18, 2016 at 11:12:45 AM UTC+5:30, Steven D'Aprano wrote:
> Today I learned that **kwargs style keyword arguments can be any string:
>
>
> py> def test(**kw):
> ... print(kw)
> ...
> py> kwargs = {'abc-def': 42, '': 23, '---': 999, '123': 17}
> py> test(**kwargs)
> {'': 23, '123': 17, '---': 999, 'abc-def': 42}
>
Hoo boy!
Namespaces are a honking great idea though sometimes the honk is too loud
>
> Bug or feature?
Dunno...
I dont like it
--
https://mail.python.org/mailman/listinfo/python-list
Re: Guido on python3 for beginners
On Friday, February 19, 2016 at 6:48:12 AM UTC+5:30, Steven D'Aprano wrote: > > > But apart from that, I think that "teaching" versus "doing" language is a > false dichotomy. Teaching languages should have a shallow learning curve > (easy to get started and learn the language, easy discoverability). > Production languages should have deep functionality and power. Those two > are not *necessarily* opposed[1]. Good languages should have both: a > shallow learning curve leading to deep functionality. > > [1] Except in the trivial sense that the more you have to learn, the longer > it will take. Consider as hypothesis L1: Needs 4 weeks to master L2: Needs 4 years to manage (if you want to make it less hypothetical think C++) Which would be more satisfying to a student? [Not a hypothetical question: Some people like to go mountaineering/bungee-jumping etc and breaks their necks. Likewise Ive seen students who were so C++-happy they failed other courses! I'd hazard you have forgotten what it feels like to be a student by some decades :-) -- https://mail.python.org/mailman/listinfo/python-list
Re: Guido on python3 for beginners
On Thursday, February 18, 2016 at 9:22:10 PM UTC+5:30, Random832 wrote: > On Thu, Feb 18, 2016, at 07:25, Rustom Mody wrote: > > My beef is somewhat different: viz that post 70s (Pascal) and 80s > > (scheme) > > programming pedagogy has deteriorated with general purpose languages > > replacing > > 'teaching-purpose language' for teaching. > > The flaw in this idea is right there in your post. Both languages you > named are strongly tied to a single paradigm (procedural for Pascal, and > functional for Scheme) which don't match the paradigm that real-world > work is done in. Factually incorrect. Scheme is as multi-paradigm as you can get -- SICP spends considerable time building OO systems, machine architectures etc Culturally is another matter -- scheme tends to draw FP aficionados as python seems to draw OO ones. The languages do not mandate this > Is there a new "teaching-purpose language"? No And that's the deterioration in the programming edu-world -- https://mail.python.org/mailman/listinfo/python-list
Re: Guido on python3 for beginners
On Thursday, February 18, 2016 at 12:17:26 PM UTC+5:30, Steven D'Aprano wrote: > On Wednesday 17 February 2016 19:51, Rustom Mody wrote: > > > I hope someone can help me find this link: There is some record that Guido > > has said that python3 is probably a bit harder on noobs than python2. > > > > Does anyone know/have that link? > > > I can't say that I've seen it. I know that Raymond Hettinger is not too fond > of adding new syntactic features that add little in the way of power but > make the language harder to learn, but I don't recall anyone saying that it > is harder for newbies to get started with Python 3 than Python 2. > > There are more features in Python 3, so in that trivial sense of "more to > learn", I suppose that it is objectively correct that it is harder to learn > than Python 2. But I don't think the learning curve is any steeper. If > anything, the learning curve is ever-so-slightly less steep. > > Thanks Steven! So its Raymond Hettinger... Good enough So now I find your earlier post: https://mail.python.org/pipermail/python-list/2015-March/688387.html Obviously google was not obliging when I searched for Guido :-) BTW I have no tongs in this 2 vs 3 fire -- I'll leave that to Rick jmf and other noble gentry. My beef is somewhat different: viz that post 70s (Pascal) and 80s (scheme) programming pedagogy has deteriorated with general purpose languages replacing 'teaching-purpose language' for teaching. Which is about as intelligent as calling Martha[1] and Rose[2] both pianists [1] https://www.youtube.com/watch?v=YLZLp6AcAi4 [2] https://www.youtube.com/watch?v=_bjKDJD-CLc -- https://mail.python.org/mailman/listinfo/python-list
Guido on python3 for beginners
On Tuesday, February 16, 2016 at 10:54:43 AM UTC+5:30, John Ladasky wrote: > On Monday, February 15, 2016 at 6:02:24 PM UTC-8, Rick Johnson wrote: > > I don't need Python3. And i reckon that by the time i do, > > something more interesting will come along, or, i'll create > > something more interesting myself. i've been drafting, and > > dreaming, of a new language spec for over a year now.. And > > the best thing about starting a new language, you can do > > anything you want... no dependencies! > > If you have all the skills that you claim, you're a far better programmer > than I. So -- exactly why are you complaining to people who are developing > and/or using Py3? Go off and impress everyone. Become your own BDFL. I hardly want to enter a 'who-can-fart-loudest' contest with Rick... I hope someone can help me find this link: There is some record that Guido has said that python3 is probably a bit harder on noobs than python2. Does anyone know/have that link? -- https://mail.python.org/mailman/listinfo/python-list
Re: [STORY-TIME] THE BDFL AND HIS PYTHON PETTING ZOO
On Sunday, February 7, 2016 at 8:04:42 AM UTC+1, Paul Rubin wrote: > Steven D'Aprano writes: > > According to TIOBE, Python's popularity continues to grow: > > http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html > > I wonder how much of that growth is Python 3 and how much is Python 2. > > I'm amazed there's still so much C being done. I meet good programmers > all the time these days, who have never touched C code. > > The crash of Objective-C is amusing ;-). > > It's surprising that R places at all, given the amount of math that its > users need to know. > > I wonder what it means that Perl is booming. Hmm. Nice points: Programming language popularity is generally voodoo. I am only surprised at your surprise at R. Data (science) is after all the hot subject A programmer moving into that field typically starts with python A statistician typically starts R [My voodoo of course :-) ] -- https://mail.python.org/mailman/listinfo/python-list
Re: psss...I want to move from Perl to Python
On Sunday, January 31, 2016 at 11:15:50 PM UTC+5:30, Paul Rubin wrote: > Rustom Mody writes: > > I would guess it needs more recoding than explicit compilation! > > Maybe something like http://www.colm.net/open-source/ragel/ > > Unfortunately no python binding so far :-( > > Neat, that looks kind of like lex/flex but with more backends. Its much more than that. It freely allows mixing of the re and dfa paradigms. Of course its a classic commonplace in CS that these two are isomorphic. However structurally they are very different Of course lex has a state management component as well -- I guess you can think of ragel to lex in this respect as hll to assembly. Also I believe its more efficient than lex -- https://mail.python.org/mailman/listinfo/python-list
Re: psss...I want to move from Perl to Python
On Monday, February 1, 2016 at 8:45:38 AM UTC+5:30, Chris Angelico wrote: > There are a lot of people here who post good content but phrase things > poorly. And everyone has a bad day. (Terry Reedy, I'm hoping this was > just a bad day - there were several rather caustic posts from you. > Sorry to single you out, but I can't think of anyone else recently > who's done that.) So long as there's something useful being said, the > community would be worse off for their removal. Good -- we're agreed on that much > > That said, though, I would GREATLY prefer Rick to post less > provocatively. But I'm not calling for his banning any more than I'd > call for Terry's, or my own, for that matter (I've posted plenty of > off-topic or otherwise useless posts). Yes: Just to be clear I am not asking for Rick to be banned though he needs to be told more often than others to stop assholing. Likewise jmf: Old-timers out here know anyway to ignore his unicode-complaints. And newcomers --eg this thread -- need to be told anyway. So why ban? -- https://mail.python.org/mailman/listinfo/python-list
Re: psss...I want to move from Perl to Python
On Monday, February 1, 2016 at 5:22:22 AM UTC+5:30, Terry Reedy wrote: > On 1/31/2016 5:34 PM, Fillmore wrote: > > On 01/30/2016 05:26 AM, wxjmfauth wrote: > > > >>> Python 2 vs python 3 is anything but "solved". > >> Python 3.5.1 is still suffering from the same buggy > >> behaviour as in Python 3.0 . > > > > Can you elaborate? > > Please do not propagate jmf's repeated trolls to python-list On Saturday, January 30, 2016 at 3:57:28 PM UTC+5:30, wxjmf wrote: > Python 3.5.1 is still suffering from the same buggy > behaviour as in Python 3.0 . is banned whereas this is not: On Saturday, January 30, 2016 at 3:01:09 AM UTC+5:30, Rick Johnson wrote: > On Friday, January 29, 2016 at 6:21:21 AM UTC-6, Ulli Horlacher wrote: > > I nearly gave up with Python at the very beginning before > > I realised that OO-programming is optional in Python! :-) > > Most tutorials I found so far makes OO mandatory. > > Just more evidence that old dogs are incapable of learning > new tricks. Either learn how to wield Neuroplasticity to > your advantage, or go curl up into a ball and wait for death > to come. People who are unwilling to "expanding their > intellectual horizons" make me sick!!! Not to mention endless screeds like this one: On Saturday, January 30, 2016 at 4:00:12 AM UTC+5:30, Rick Johnson wrote: > On Friday, January 29, 2016 at 2:49:24 PM UTC-6, sohca...@gmail.com wrote: > > > I'm convinced that anyone who actually prefers Perl's > > syntax over Python is suffering from Stockholm Syndrome. > > > > [...] > > > > Readability counts. I'd say readability is one of the > > most important features of a language, as you will read > > your code far more than you write it. Perl is not > > readable. I don't care how powerful your language is if > > you can't read it. > > EXACTLY! > > Which is the same reason why natural language is bound by > many structural rules. For instance: we utilize "syntactical > structures" like sentences and paragraphs to create > "comprehensible groupings", and we *NEVER* want to > arbitrarily, or randomly, use more than one space between > words, or more than one line between paragraphs. > > STRUCTURE IS IMPORTANT! > > And the only thing more important than a "self-imposed > structure" is a steadfast adherence to the "collective style > guides" of written communication. When we *ALL* utilize a > familiar structure, we will *ALL* spend less time > *CONSCIOUSLY INTERPRETING* superficial structural details, > and more time *ABSORBING* the actual meaning of the content. > > ABSORPTION IS THE GOAL, NOT ABERRATION! > > The goal of written communication is no different than any > other technology. We should strive to abstract away as much > as possible to the sub-conscience processes of our mind as > we can, so that we can target our mental focus purely on the > comprehension of content, *NOT* comprehension of structure! > When faced with an unfamiliar "syntactical structure", our > high level focus becomes "mired in the minutiae of the > superficial". > > EVEN WHEN NECESSARY, THE SUPERFICIAL IS NOT IMPORTANT! > > The goal of communication should never be (either > intentional or not) to distract or impress our readers with > our capacity to create "self-aggrandizing ornateness of > structure", which will undoubtedly obfuscate the intended > message, no, but to *STRICTLY* follow the collective > standards and practices of "acceptable syntactical > structuring" that will *facilitate* a smooth transition > between: ideas that are codified into symbolic languages, > and the translation of those linguistic symbols into concepts > in the mind of the reader. > > ABSTRACTIONS ARE VITAL TO OUR COMPREHENSION OF COMPLEX > COMMUNICATION MEDIUMS! > > For communication to function (at it's most basic level) > these abstractions must exist simultaneously in our codified > symbolic languages *AND* in our mental processes that > interpret them. But whilst our mental abstractions are > mostly unconscious, they can become disturbed when > dissonance is injected into symbolic languages in the form > of "poor syntactical structure". Break either link in the > chain, and a "smooth transition of ideas" becomes untenable. Can someone explain the policy? -- https://mail.python.org/mailman/listinfo/python-list
Re: psss...I want to move from Perl to Python
True... $ python Python 2.7.10 (default, Oct 14 2015, 16:09:02) [GCC 5.2.1 20151010] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import re >>> re._MAXCACHE 100 But 100 is still large enough that for most normal users/uses re-compilation is pointless. -- https://mail.python.org/mailman/listinfo/python-list
Re: psss...I want to move from Perl to Python
On Sunday, January 31, 2016 at 9:18:31 AM UTC+5:30, Cameron Simpson wrote: > On 30Jan2016 19:22, rusi wrote: > >Python 3.4.3+ (default, Oct 14 2015, 16:03:50) > >[GCC 5.2.1 20151010] on linux > >Type "help", "copyright", "credits" or "license" for more information. > python.el: native completion setup loaded > > import re > re._MAXCACHE > >512 > > > >Have you ever seen a program that uses 512 re's? > >I havent :-) > > I have. I've got one right here. It happens to be in perl, but it has been in > need of a recode in Python for a long time. It has about 3000 regexps. > > Of course they will be explicitly compiled in the recode. > I would guess it needs more recoding than explicit compilation! Maybe something like http://www.colm.net/open-source/ragel/ Unfortunately no python binding so far :-( -- https://mail.python.org/mailman/listinfo/python-list
Re: psss...I want to move from Perl to Python
On Sunday, January 31, 2016 at 7:27:06 AM UTC+5:30, Steven D'Aprano wrote: > On Sunday 31 January 2016 09:18, Gregory Ewing wrote: > > > Rustom Mody wrote: > >> 1. One can use string-re's instead of compiled re's > > > > And I gather that string REs are compiled on first use and > > cached, so you don't lose much by using them most of the > > time. > > Correct. The re module keeps a cache of the last N regexes used, for some > value of N (possibly 10?) so for casual use there's no real point to pre- > compiling other than fussiness. > > But if you have an application that makes heavy-duty use of regexes, e.g. > some sort of parser with dozens of distinct regexes, you might not want to > rely on the cache. > > > > -- > Steve Python 3.4.3+ (default, Oct 14 2015, 16:03:50) [GCC 5.2.1 20151010] on linux Type "help", "copyright", "credits" or "license" for more information. >>> python.el: native completion setup loaded >>> >>> import re >>> re._MAXCACHE 512 >>> Have you ever seen a program that uses 512 re's? I havent :-) -- https://mail.python.org/mailman/listinfo/python-list
Re: psss...I want to move from Perl to Python
On Saturday, January 30, 2016 at 3:01:09 AM UTC+5:30, Rick Johnson wrote: > On Friday, January 29, 2016 at 6:21:21 AM UTC-6, Ulli Horlacher wrote: > > I nearly gave up with Python at the very beginning before > > I realised that OO-programming is optional in Python! :-) > > Most tutorials I found so far makes OO mandatory. > > Just more evidence that old dogs are incapable of learning > new tricks. Either learn how to wield Neuroplasticity to > your advantage, or go curl up into a ball and wait for death > to come. Regarding neuroplasticity especially in programming you may find this useful: http://blog.languager.org/2016/01/primacy.html > People who are unwilling to "expanding their intellectual horizons" make me > sick!!! Yes! And as functional programming becomes more mainstream, OO-fanboys may need some urgent graft of plastic, see: http://blog.languager.org/2015/06/functional-programming-moving-target.html -- https://mail.python.org/mailman/listinfo/python-list
Re: psss...I want to move from Perl to Python
On Saturday, January 30, 2016 at 3:01:09 AM UTC+5:30, Rick Johnson wrote: > On Friday, January 29, 2016 at 6:21:21 AM UTC-6, Ulli Horlacher wrote: > > I nearly gave up with Python at the very beginning before > > I realised that OO-programming is optional in Python! :-) > > Most tutorials I found so far makes OO mandatory. > > Just more evidence that old dogs are incapable of learning > new tricks. Either learn how to wield Neuroplasticity to > your advantage, or go curl up into a ball and wait for death > to come. People who are unwilling to "expanding their > intellectual horizons" make me sick!!! JFTR: [Ranting] Rick is someone who I sometimes agree with were it not for the ranting style. In this case I think its more important to rebut the contents of the rant than the emotion-BS, especially given that one of the questions of the OP was re 're'. Somebody said above that the re in python needs to be 'compiled' unlike perl. Also if you see the docs they are mostly match/search orientated. Both these are unnecessary OO-gook 1. One can use string-re's instead of compiled re's 2. One can use findall instead of search/match 3. One can do from re import findall findall(...) rather than import re re.findall(...) 1. By using string-res one need not create opaque re OBJECTS 2. By using findall one need not fish around in opaque match objects 3. By using from ... import one can reduce OO dotodotodotomania In short python can be much less OO than is typically presented -- https://mail.python.org/mailman/listinfo/python-list
Re: how to get python version ?
On Thursday, January 28, 2016 at 10:51:17 AM UTC+5:30, namenob...@gmail.com wrote: > hi > > is there something analogous to sys.platform that lets you get the version of > python you're using? sorry if the question is too see-spot-run. thanks if you > can help > > peace > stm You want this?? https://docs.python.org/3.5/library/platform.html -- https://mail.python.org/mailman/listinfo/python-list
Re: Question about asyncio and blocking operations
On Monday, January 25, 2016 at 9:16:13 PM UTC+5:30, Ian wrote: > On Mon, Jan 25, 2016 at 8:32 AM, Ian Kelly wrote: > > > > On Jan 25, 2016 2:04 AM, "Frank Millman" wrote: > >> > >> "Ian Kelly" wrote in message > >>> > >>> This seems to be a common misapprehension about asyncio programming. > >>> While coroutines are the focus of the library, they're based on > >>> futures, and so by working at a slightly lower level you can also > >>> handle them as such. So while this would be the typical way to use > >>> run_in_executor: > >>> > >>> async def my_coroutine(stuff): > >>> value = await get_event_loop().run_in_executor(None, > >>> blocking_function, stuff) > >>> result = await do_something_else_with(value) > >>> return result > >>> > >>> This is also a perfectly valid way to use it: > >>> > >>> def normal_function(stuff): > >>> loop = get_event_loop() > >>> coro = loop.run_in_executor(None, blocking_function, stuff) > >>> task = loop.create_task(coro) > >>> task.add_done_callback(do_something_else) > >>> return task > >> > >> > >> I am struggling to get my head around this. > >> > >> 1. In the second function, AFAICT coro is already a future. Why is it > >> necessary to turn it into a task? In fact when I tried that in my testing, > >> I > >> got an assertion error - > >> > >> File: "C:\Python35\lib\asyncio\base_events.py", line 211, in create_task > >>task = tasks.Task(coro, loop=self) > >> File: "C:\Python35\lib\asyncio\tasks.py", line 70, in __init__ > >>assert coroutines.iscoroutine(coro), repr(coro) > >> AssertionError: > > > > I didn't test this; it was based on the documentation, which says that > > run_in_executor is a coroutine. Looking at the source, it's actually a > > function that returns a future, so this may be a documentation bug. > > And now I'm reminded of this note in the asyncio docs: > > """ > Note: In this documentation, some methods are documented as > coroutines, even if they are plain Python functions returning a > Future. This is intentional to have a freedom of tweaking the > implementation of these functions in the future. If such a function is > needed to be used in a callback-style code, wrap its result with > ensure_future(). > """ > > IMO such methods should simply be documented as awaitables, not > coroutines. I wonder if that's already settled, or if it's worth > starting a discussion around. Bah -- What a bloody mess! And thanks for pointing this out, Ian. Keep wondering whether my brain is atrophying, or its rocket science or... -- https://mail.python.org/mailman/listinfo/python-list
Re: How clean/elegant is Python's syntax?
On Friday, May 31, 2013 at 1:06:29 AM UTC+5:30, Steven D'Aprano wrote: > On Thu, 30 May 2013 10:12:22 -0700, rusi wrote: > > > On Thu, May 30, 2013 at 9:34 AM, Ma Xiaojun wrote: > > >> Wait a minute! Isn't the most nature way of doing/thinking "generating > >> 9x9 multiplication table" two nested loop? > > > > Thats like saying that the most natur(al) way of using a car is to > > attach a horse to it. > >[...] > > Likewise in the world of programming, 90% of programmers think > > imperative/OO programming is natural while functional programming is > > strange. Just wait 10 years and see if things are not drastically > > different! > > It won't be. Functional programming goes back to Lisp, which is nearly as > old as Fortran and older than Cobol. There have been many decades for > functional languages to become mainstream, but they've never quite done > it. There's no reason to think that the next decade will see a change to > this. Interesting point... With interesting (counter)examples: http://blog.languager.org/2016/01/how-long.html [With apologies for necroposting] -- https://mail.python.org/mailman/listinfo/python-list
Re: Refactoring in a large code base
On Friday, January 22, 2016 at 7:13:49 PM UTC+5:30, Marko Rauhamaa wrote: > Rustom Mody : > > > IOW anyone who thinks that *arbitrary* complexity can *always* be > > tamed either has a visa to utopia or needs to re-evaluate (or get) a > > CS degree > > Not all complexity can be tamed, but what you can't tame you shouldn't > release, either. And how do you propose to legislate that? If you leave it to the wetware (untamed!) boxes atop our shoulders will not two developers have wildly different complexity thresholds? And as soon as you suggest an objective (∴ algorithmic) solution to detecting complexity you have landed with the halting problem (or more precisely Rice theorem) tl;dr The HP is amazingly deceptive and you just got tripped by it -- https://mail.python.org/mailman/listinfo/python-list
Re: Refactoring in a large code base
On Friday, January 22, 2016 at 6:05:02 PM UTC+5:30, Chris Angelico wrote: > On Fri, Jan 22, 2016 at 11:04 PM, Rustom Mody wrote: > > 2. My students trying to work inside the lexer made a mess because the > > extant lexer is a mess. > > I.e. while python(3) *claims* to accept Unicode input, the actual lexer is > > an ASCII lexer special-cased for unicode rather than pre-lexing utf8 to > > unicode > > > > These are just specific examples that I am familiar with > > > Regarding lexers specifically, I have never seen any full-size > language parser that I've wanted to tinker with. They're always highly > optimized pieces of code, dealing with innumerable edge and corner > cases, and exploring them is always like dipping my toe into something > that's either ice-cold water or highly caustic acid, and I can't tell > which. > You just gave a graphic vivid description... of the same thing Marko is describing: ;-) viz. A full-size language parser is something that you - an experienced developer - make a point of avoiding. So then the question comes down to this: Is this the order of nature? Or is it man-made disorder? Jury's out on that one for lexers/parsers specifically. For arbitrary code in general, the problem that it may be arbitrarily and unboundedly complex/complicated is the oldest problem in computer science: the halting problem. IOW anyone who thinks that *arbitrary* complexity can *always* be tamed either has a visa to utopia or needs to re-evaluate (or get) a CS degree -- https://mail.python.org/mailman/listinfo/python-list
Re: Refactoring in a large code base
On Friday, January 22, 2016 at 4:49:19 PM UTC+5:30, Chris Angelico wrote: > On Fri, Jan 22, 2016 at 9:19 PM, Marko Rauhamaa wrote: > > The knowhow, vision and skill is apparently very rare. On the product > > management side, we have the famous case of Steve Jobs, who simply told > > the engineers to go back to the drawing boards when he didn't like the > > user experience. Most others would have simply surrendered to the > > mediocre designs and shipped the product. > > > > We need similar code sanity management. Developers are given much too > > much power to mess up the source code. That's why "legacy" is considered > > a four-letter word among developers. > > So what do you do with a huge program? Do you send it back to the > developers and say "Do this is less lines of code"? > > CPython is a large and complex program. How do you propose doing it "right"? Put thus 'generistically' this is a rhetorical question and makes Marko look like he's making a really foolish point Specifically, what little Ive seen under the CPython hood looked distinctly improvable. egs. 1. My suggestion to have the docs re. generator-function vs generator-objects cleaned up had no takers 2. My students trying to work inside the lexer made a mess because the extant lexer is a mess. I.e. while python(3) *claims* to accept Unicode input, the actual lexer is an ASCII lexer special-cased for unicode rather than pre-lexing utf8 to unicode These are just specific examples that I am familiar with Chris' general point still stands, viz take the large and complex program that is cpython and clean up these messinesses: You will still have a large and complex program -- https://mail.python.org/mailman/listinfo/python-list
Re: Refactoring in a large code base
On Friday, January 22, 2016 at 1:59:15 PM UTC+5:30, Marko Rauhamaa wrote: > Ben Finney : > > > The author points out there are times when a code base is large and > > complex enough that refactoring puts the programmer in a state of not > > knowing whether they're making progress, because until the whole > > refactoring is complete the errors just cascade and it's hard to tell > > which ones are relevant. > > I've been there. I think the root problem is to have a code base that's > so large and complex. Bizarre comment... Are you saying large and complex code-bases should non-exist? > > It *could* be avoided if the engineering director only cared. Some problems are trivially solvable... for those who have the knowhow Some problems are inherently hard but easily detectable as such... once again for those who have the knowhow And some are literally (and ironically trivially) unsolvable The CS-trinity: 'normal' problems, problems in NP, undecidable problems is a classic example of this. However applying that in real-world practice can be highly non-trivial, requiring from specialized knowledge to intelligence to genius. IOW "engineering director does not care" is likely true but also a gross oversimplification -- https://mail.python.org/mailman/listinfo/python-list
Re: importing: what does "from" do?
On Thursday, January 21, 2016 at 7:53:07 PM UTC+5:30, Charles T. Smith wrote: > What does "from (module) import (func)" do? > > Please don't tell me that I shouldn't ask because real programmers > know not to have circular dependencies ... > > I have no idea what was imported before. I just want to import hexdump(). > Unfortunately, this does not work: > > from utilities import hexdump > > ImportError: cannot import name hexdump > > Now, I shouldn't have a problem because the programmers before me didn't > understand either, and so just duplicated it everywhere, but I'd really > like to do it right. > > I would have thought that "from" would allow me to import just one > symbol. Now, for all the people just chomping at the bit to tell > me about circular dependencies, would you explain to me why I get this: > > (PDB)hexdump(msg) > *** NameError: name 'hexdump' is not defined > > > P.S. can I get a list of all the loaded symbols and/or modules? You may find this strategy useful: https://pchiusano.github.io/2015-04-23/unison-update7.html particularly the section "Limitations of refactoring via modifying text files in place, and what to do instead" Note it is not python based but the explanation should be useful anyway -- https://mail.python.org/mailman/listinfo/python-list
Re: When I need classes?
Guess you (Rodrigo) wanted to send this to the list? On Wed, Jan 13, 2016 at 8:22 PM, Rodrigo Bistolfi wrote: > Start by using just functions. As you move forward, you will find that > often you are passing the same data structure as first argument to some > functions. At that point, you are already using OOP, and you may want to > formalize that in a class. >HTH On Wednesday, January 13, 2016 at 12:01:29 PM UTC+5:30, Rustom Mody wrote: > On Wednesday, January 13, 2016 at 10:57:23 AM UTC+5:30, Steven D'Aprano wrote: > > On Wednesday 13 January 2016 14:36, Rustom Mody wrote: > > > > > 1. Python the LANGUAGE, is rather even-handed in paradigm choice: Choose > > > OO, imperative, functional or whatever style pleases/suits you > > > 2. Python LIBRARIES however need to make committing choices. Users of > > > those then need to align with these. > > > > I don't think that second one is necessarily correct. Look at the random > > module: it is based on an OOP design, with classes random.Random and > > random.SystemRandom doing the real work. But most people don't use them > > directly, they use the procedural interface random.random, random.choice, > > random.seed etc. > > > > Yes one can have more or less degrees of freedom. Are infinite degrees > possible? > I believe not. > > eg My example of re is strictly not correct: can use strings instead of re > objects > Can use findall instead of search/match and avoid groping around in opaque > match > objects > So you may conclude that the re module allows these degrees of freedom > But you cant bold res all the way into the syntax of the language (eg > perl/awk) > > Anyway these are side points > My main point is that when you sit on top of heavy-duty many-layered libraries > (worse frameworks... OP seems to be trying Kivy) then you have to align with > the opinionatedness of all the layers down to python. > > Of course that is modulo the leakiness of the abstractions. > eg mostly python programmers do not need to know the underlying C... > > Mostly... > And then someone asks about id/is/performance... -- https://mail.python.org/mailman/listinfo/python-list
Re: When I need classes?
On Wednesday, January 13, 2016 at 10:57:23 AM UTC+5:30, Steven D'Aprano wrote: > On Wednesday 13 January 2016 14:36, Rustom Mody wrote: > > > 1. Python the LANGUAGE, is rather even-handed in paradigm choice: Choose > > OO, imperative, functional or whatever style pleases/suits you > > 2. Python LIBRARIES however need to make committing choices. Users of > > those then need to align with these. > > I don't think that second one is necessarily correct. Look at the random > module: it is based on an OOP design, with classes random.Random and > random.SystemRandom doing the real work. But most people don't use them > directly, they use the procedural interface random.random, random.choice, > random.seed etc. > Yes one can have more or less degrees of freedom. Are infinite degrees possible? I believe not. eg My example of re is strictly not correct: can use strings instead of re objects Can use findall instead of search/match and avoid groping around in opaque match objects So you may conclude that the re module allows these degrees of freedom But you cant bold res all the way into the syntax of the language (eg perl/awk) Anyway these are side points My main point is that when you sit on top of heavy-duty many-layered libraries (worse frameworks... OP seems to be trying Kivy) then you have to align with the opinionatedness of all the layers down to python. Of course that is modulo the leakiness of the abstractions. eg mostly python programmers do not need to know the underlying C... Mostly... And then someone asks about id/is/performance... -- https://mail.python.org/mailman/listinfo/python-list
Re: When I need classes?
On Sunday, January 10, 2016 at 1:00:13 PM UTC+5:30, Arshpreet Singh wrote: > Hello Friends, I am quite new to OOP(object oriented Programming), I did some > projects with python which includes Data-Analysis, Flask Web Development and > some simple scripts. > > I have only one question which is bothering me most of the time, When I will > get the need to use Classes in Python? Or in other way is there any real-life > example where you can tell me this problem/solution is kind of impossible in > Python without Classes? I think the answers so far dont cover two complementary sides to this question: 1. Python the LANGUAGE, is rather even-handed in paradigm choice: Choose OO, imperative, functional or whatever style pleases/suits you 2. Python LIBRARIES however need to make committing choices. Users of those then need to align with these. egs 1. Majority of basic python is functional; eg stuff in os module 2. Some things need object creation and method call eg for re-s you need to know about and to use re objects, match objects etc 3. Then there are things that are naturally used by inheriting and extending eg Basehttpserver is typically used via inheritance To use these you need to know basic OO 4. Then there may be things whose natural usage needs multiple inheritance [cant think of examples] So as others have said, in principle you dont need to go beyond 1. Unfortunately when you are using non-trivial libraries you are a user both of python and the library and so the library-author's paradigm choices are a given for you -- https://mail.python.org/mailman/listinfo/python-list
Re: Python installation in windows
On Monday, January 11, 2016 at 6:32:14 PM UTC+5:30, navneet bhatele wrote: > I have been trying to install the "python-3.5.1-amd64-webinstall " many > times and the Set up failed is shown up with named 0*80070002 - file > doesn't exist in dialog box Which windows? XP and 3.5 are not compatible For XP use 3.4 -- https://mail.python.org/mailman/listinfo/python-list
Re: Which Python editor has this feature?
On Monday, January 11, 2016 at 7:30:10 AM UTC+5:30, jf...@ms4.hinet.net wrote: > It lets you jump between the current cursor position and the line the upper > level indentation start, something like the bracket matching in C editor. > Because of Python use indentation as its code block mark, It might be helpful > if we can jump between different level of it:-) > > > --Jach Fong Recent emacs' python mode has all these bunch of python-nav-* functions. You may have (as usual with emacs!) to choose which you like best, ie not all are not bound to keys. Click on a completion to select it. In this buffer, type RET to select the completion near point. Possible completions are: python-nav--beginning-of-defun python-nav--forward-defun python-nav--forward-sexppython-nav--lisp-forward-sexp python-nav--lisp-forward-sexp-safe python-nav--syntactically python-nav--up-list python-nav-backward-block python-nav-backward-defun python-nav-backward-sexp python-nav-backward-sexp-safe python-nav-backward-statement python-nav-backward-up-list python-nav-beginning-of-block python-nav-beginning-of-defun python-nav-beginning-of-statement python-nav-end-of-block python-nav-end-of-defun python-nav-end-of-statement python-nav-forward-block python-nav-forward-defunpython-nav-forward-sexp python-nav-forward-sexp-safepython-nav-forward-statement python-nav-if-name-main python-nav-up-list -- https://mail.python.org/mailman/listinfo/python-list
Re: Help on return type(?)
On Sunday, January 10, 2016 at 7:16:23 AM UTC+5:30, Robert wrote:
> Hi,
>
> I see below code snippet. The return line is not as the usual type.
>
>
>
> def make_cov(cov_type, n_comp, n_fea):
> mincv = 0.1
> rand = np.random.random
> return {
> 'spherical': (mincv + mincv * np.dot(rand((n_components, 1)),
> np.ones((1, n_features ** 2,
> 'tied': (make_spd_matrix(n_features)
> + mincv * np.eye(n_features)),
> 'diag': (mincv + mincv * rand((n_components, n_features))) ** 2,
> 'full': np.array([(make_spd_matrix(n_features)
>+ mincv * np.eye(n_features))
> for x in range(n_components)])
> }[cov_type]
>
> Specifically, could you explain the meaning of
>
> {
> ...}[cov_type]
>
> to me?
>
>
> Thanks,
May help if you see it in pseudo-C like this
switch (cov_type)
case 'spherical': return (mincv + mincv * np.dot(rand((n_components, 1)),
np.ones((1, n_features ** 2,
case 'tied': return (make_spd_matrix(n_features)
+ mincv * np.eye(n_features)),
case 'diag': return (mincv + mincv * rand((n_components, n_features)))
** 2,
case 'full': return np.array([(make_spd_matrix(n_features)
+ mincv * np.eye(n_features))
for x in range(n_components)])
Yeah looks backward in python compared to the C-ish
The python is more powerful however because its *data-driven*
ie what is code in C is data in python.
BTW this is one of the motley components collected together under the somewhat
inept moniker of 'functional programming':
http://blog.languager.org/2012/10/functional-programming-lost-booty.html
Also you can make the python look less backward by naming the dictionary,
separate from the lookup:
d = {'spherical' : ..., 'tied' :..., 'diag' : ...}
return d[cov_type]
--
https://mail.python.org/mailman/listinfo/python-list
Re: How to union nested Sets / A single set from nested sets?
On Wednesday, January 6, 2016 at 6:48:28 PM UTC+5:30, mviljamaa wrote:
> I'm forming sets by set.adding to sets and this leads to sets such as:
>
> Set([ImmutableSet(['a', ImmutableSet(['a'])]), ImmutableSet(['b',
> 'c'])])
>
> Is there way union these to a single set, i.e. get
>
> Set(['a', 'b', 'c'])
>
> ?
Dont know what version of python spells it that way.. seems old
In 2.7 you can do this:
>>> a=set([frozenset(['a']), frozenset(['b','c'])])
>>> {y for x in a for y in x}
set(['a', 'c', 'b'])
It may be easier to understand written the way set-expressions in math are
normally written:
{y | x ∈ a, y ∈ x}
And then treat the python as an ASCII-fication of the math
Likewise
>>> frozenset(y for x in a for y in x)
frozenset(['a', 'c', 'b'])
>>>
--
https://mail.python.org/mailman/listinfo/python-list
Re: raise None
On Monday, January 4, 2016 at 11:23:24 AM UTC+5:30, Rustom Mody wrote: > On Monday, January 4, 2016 at 10:49:39 AM UTC+5:30, Steven D'Aprano wrote: > > On Fri, 1 Jan 2016 10:27 am, Ben Finney wrote: > > > > > If I could have the traceback continue into the C code and tell me the > > > line of C code that raised the exception, *that's* what I'd choose. > > > > If you are serious about believing this would be a good thing, you can open > > a ticket on the bug tracker and make an enhancement request that tracebacks > > generated from builtins should expose their internal details: > > > > > > >>> 7 + [] > > Traceback (most recent call last): > > File "", line 1, in > > File "longobject.c", line 3008, in long_add > > File "longobject.c", line 1425, in CHECK_BINOP > > TypeError: unsupported operand type(s) for +: 'int' and 'list' > > > > > > When you open that ticket, be so good as to add me to the Nosy list. > > Prior Art: > An emacs lisp error stops at the boundaries of emacs lisp if I use standard > (debian/ubuntu packaged) emacs. > OTOH if compiled from source it points to the C source (last I remember > trying) I think I mis-remembered this: It is not tracebacks but docs that reach from front-facing lisp (commands) through internal lisp (functions) to C in elisp. -- https://mail.python.org/mailman/listinfo/python-list
Re: raise None
On Monday, January 4, 2016 at 11:42:51 AM UTC+5:30, Dan Sommers wrote: > > I'm saddened but not astonished at just how much opposition there is > > to point (1) ... > > I'll echo the sentiment that we're all adults here, and my opinion that > if you're reading tracebacks, then you want as much information as > possible, even if it seemed irrelevant to the library author at the > time. And I am saddened at how often mediocre Linux system software can throw a traceback at me -- sometimes for things as basic as a missing command-line parameter. Increasingly often a python traceback. I guess most people here are programmers (and adults) but sometimes we want to wear a different hat (I think). Being a vanilla user of your OS is often one such time -- https://mail.python.org/mailman/listinfo/python-list
Re: raise None
On Monday, January 4, 2016 at 10:49:39 AM UTC+5:30, Steven D'Aprano wrote: > On Fri, 1 Jan 2016 10:27 am, Ben Finney wrote: > > > If I could have the traceback continue into the C code and tell me the > > line of C code that raised the exception, *that's* what I'd choose. > > If you are serious about believing this would be a good thing, you can open > a ticket on the bug tracker and make an enhancement request that tracebacks > generated from builtins should expose their internal details: > > > >>> 7 + [] > Traceback (most recent call last): > File "", line 1, in > File "longobject.c", line 3008, in long_add > File "longobject.c", line 1425, in CHECK_BINOP > TypeError: unsupported operand type(s) for +: 'int' and 'list' > > > When you open that ticket, be so good as to add me to the Nosy list. Prior Art: An emacs lisp error stops at the boundaries of emacs lisp if I use standard (debian/ubuntu packaged) emacs. OTOH if compiled from source it points to the C source (last I remember trying) -- https://mail.python.org/mailman/listinfo/python-list
Re: raise None
On Monday, January 4, 2016 at 10:49:39 AM UTC+5:30, Steven D'Aprano wrote: > On Fri, 1 Jan 2016 10:27 am, Ben Finney wrote: > > > If I could have the traceback continue into the C code and tell me the > > line of C code that raised the exception, *that's* what I'd choose. > > If you are serious about believing this would be a good thing, you can open > a ticket on the bug tracker and make an enhancement request that tracebacks > generated from builtins should expose their internal details: > > > >>> 7 + [] > Traceback (most recent call last): > File "", line 1, in > File "longobject.c", line 3008, in long_add > File "longobject.c", line 1425, in CHECK_BINOP > TypeError: unsupported operand type(s) for +: 'int' and 'list' > > > When you open that ticket, be so good as to add me to the Nosy list. Prior Art: An emacs lisp error stops at the boundaries of emacs lisp if I use standard (debian/ubuntu packaged) emacs. OTOH if compiled from source it points to the C source (last I remember trying) -- https://mail.python.org/mailman/listinfo/python-list
Re: raise None
On Monday, January 4, 2016 at 9:02:16 AM UTC+5:30, Chris Angelico wrote: > On Mon, Jan 4, 2016 at 2:04 PM, Rustom Mody wrote: > > On Thursday, December 31, 2015 at 9:05:58 PM UTC+5:30, Steven D'Aprano > > wrote: > >> But I think it is a real issue. I believe in beautiful tracebacks that give > >> you just the right amount of information, neither too little nor two much. > >> Debugging is hard enough with being given more information than you need > >> and having to decide what bits to ignore and which are important. > > > > > > It would be nice if the tutorial (FAQ? Lang-Ref??) had a section on how to > > wade tracebacks > > Hmm, I don't think that's a language reference question. It's more > something that I would put into a series of blog posts. But I agree - > this is a great topic to discuss. Ultimately, debugging consists of > two things: find out more about what's going on, and dig through the > data from the first step to figure out what's significant. Tips for > helping people master either half of that are well worth publishing. Its one of the great paradoxes of programming pedagogy: - Everyone who talks programs by default talks right programs - Everyone who writes programs by default writes wrong programs And if you dont believe that, tell me after having taught programming for 30 odd years :-) -- https://mail.python.org/mailman/listinfo/python-list
Re: raise None
On Thursday, December 31, 2015 at 9:05:58 PM UTC+5:30, Steven D'Aprano wrote: > But I think it is a real issue. I believe in beautiful tracebacks that give > you just the right amount of information, neither too little nor two much. > Debugging is hard enough with being given more information than you need > and having to decide what bits to ignore and which are important. It would be nice if the tutorial (FAQ? Lang-Ref??) had a section on how to wade tracebacks -- https://mail.python.org/mailman/listinfo/python-list
Re: What meaning is '[: , None]'?
On Saturday, January 2, 2016 at 6:14:24 PM UTC+5:30, Robert wrote: > Hi, > > I read a code snippet, in which object w_A is: > > > w_A > Out[48]: array([ 0.10708809, 0.94933575, 0.8412686 , 0.03280939, > 0.59985308]) > > > Then, I don't know what is '[: ' below: > vs_A = w_A[:, None] * xs > > > I don't find the answer after searching around > Could you explain above code to me? > Thanks, You probably want to search for 'slice/slicing' and 'indexing' I get this http://docs.scipy.org/doc/numpy-1.10.0/reference/arrays.indexing.html [Note: I dont know much about this] -- https://mail.python.org/mailman/listinfo/python-list
Re: (Execution) Termination bit, Alternation bit.
On Saturday, December 19, 2015 at 11:26:55 PM UTC+5:30, Skybuck Flying wrote: > Hello, > > I'd like to see instruction execution enhanced with the following two ideas: > > 1. A termination bit, and a terminator pointer. > 2. A alternation bit, and a alternate pointer. > > The purpose of these bits is as follows: > > Before a processor/core executes an instruction both bits are examined. > > 1. If the termination bit is set the instruction is not executed and instead > the processor sets the instruction pointer to the termination pointer. > 2. If the alternation bit is set the instruction is not executed and instead > the processor sets the instruction pointer to the alternation pointer. > > The idea behind this is support multi threading/parallelism better. > > The idea is that Thread A could terminate Thread B immediately so that > Thread B does not continue execution. > The idea is also that Thread A could influence Thread B to start executing a > different path. > > Hopefully these bits are enough for operating systems to add support for > this. Some issues remaining could be items pushed on the stack. > Perhaps operating system can deal with that, or perhaps compiler or perhaps > some other special instructions or software methods can be added. > Hopefully operating systems can include data structures per thread that can > be loaded into the core, and into these bits and pointers so that it becomes > active. > During a context switch these bits and pointers should be loaded > accordingly. > So these two bits and these two pointers become part of the context. > > I think these two features would be usefull to make multi-threading more > responsive and faster reaction time to changes/events occuring. > > (Eventually it would be nice if these low level features would end up in > high level languages like Python ;)) > > Bye, > Skybuck. By some coincidence was just reading: from http://www.wordyard.com/2006/10/18/dijkstra-humble/ which has the following curious extract. [Yeah its outlandish] -- I consider the absolute worst programming construct to be subroutine or the function. We've used it for over 50 years now and we're still having difficulty reducing complexity. What if the unthinkable were true? What if the subroutine was the cause of all our problems? I can prove how the subroutine causes all parts of our software to become coupled and as such cannot support this as the basic building blocks of software. I find the subroutine and all the technology around it (OOP, functional, AOP, etc.) are like a sinking ship where you keep throwing more lifeboats when what you really need is a new boat. (The ship being the subroutine and the lifeboats are OOP, funcional, AOP, etc.). I posit a fourth "condition" for being able to produce better software and that is being able to recognise what specifically isn't working and be ready to ditch it. I see no indication of this for at least another 20 or 70 years give or take 100 years. Computing Industry's Best Kept Secret: The function is *NOT* necessary to build software and may in fact be a bad tool. : : [In response to questions of whats the answer to functions] With functions, it's stack based. You have to wait until the function returns in order to process the next function unless it's an internal function. This is the first in, last out rule just like a stack. I don't mean that functions are bad in of themselves for certain things. I mean that maybe they're not the *only* way. Just like different data structures have different uses. Right now, everyone is using the function. Imagine if the stack was the only data structure you could use. What a horrible world. Yet this is what we have with the function. Unix has pipes. These are queues. As data is piped, software on both ends of the queue can execute at the same time. As data passes from one end of the queue to the other, there is no concept of execution point. Only data transformations and transfers. Another example is the Internet where messages (real ones) get passed back and forth. Simple idea that scales and is in active use. We've look into the stack based way of programming to death. Maybe the queue or other data processing model can be looked at, especially to solve concurrency. I feel it's a shame that there are perfectly acceptable tools available that get sidelined for the status quo. BTW, history dictates that the function is not reusable. Well, maybe it's reusable like sand is reusable to build glass. Once it's actually used, it is forever transformed into something else that can no longer be separated from the whole. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python 2.2 or 3.5
On Sunday, October 11, 2015 at 12:04:18 PM UTC+5:30, Chris Angelico wrote: > On Sun, Oct 11, 2015 at 5:15 PM, Chris Angelico wrote: > > On Sun, Oct 11, 2015 at 4:11 PM, Rustom Mody wrote: > >> At > >> https://docs.python.org/3.5/faq/extending.html#can-i-create-an-object-class-with-some-methods-implemented-in-c-and-others-in-python-e-g-through-inheritance > >> > >> it says > >> In Python 2.2, you can inherit from built-in classes such as int, list, > >> dict, etc. > >> > >> So is it 3.5 or 2.2? > > > > More accurate would be "Since Python 2.2, you can etc etc". Every 3.x > > version permits this, as do all 2.x back as far as 2.2. Seems to > > warrant a docs patch. > > > > http://bugs.python.org/issue25375 Thanks -- More useful than the other responses -- https://mail.python.org/mailman/listinfo/python-list
Re: Python 2.2 or 3.5
On Sunday, October 11, 2015 at 11:09:17 AM UTC+5:30, Mark Lawrence wrote: > On 11/10/2015 06:11, Rustom Mody wrote: > > At > > https://docs.python.org/3.5/faq/extending.html#can-i-create-an-object-class-with-some-methods-implemented-in-c-and-others-in-python-e-g-through-inheritance > > > > it says > > In Python 2.2, you can inherit from built-in classes such as int, list, > > dict, etc. > > > > So is it 3.5 or 2.2? > > > > For some reason google takes me to the 3.3 docs > > Replacing the 3.3 by 3.5 seems to keep the same entry > > > > If just use "3" instead of "3.3" or "3.5" you'll always get the latest > stable version of the docs. You can select any version you like from > the drop down list up in the top left hand corner of the display. Leave aside the decimal point I did not even specify 2 or 3 Just gave "embedding python alternative to swig" to google and I get that 3.3 page -- https://mail.python.org/mailman/listinfo/python-list
Python 2.2 or 3.5
At https://docs.python.org/3.5/faq/extending.html#can-i-create-an-object-class-with-some-methods-implemented-in-c-and-others-in-python-e-g-through-inheritance it says In Python 2.2, you can inherit from built-in classes such as int, list, dict, etc. So is it 3.5 or 2.2? For some reason google takes me to the 3.3 docs Replacing the 3.3 by 3.5 seems to keep the same entry -- https://mail.python.org/mailman/listinfo/python-list
python 2.2 or 3.5
At https://docs.python.org/3.5/faq/extending.html#can-i-create-an-object-class-with-some-methods-implemented-in-c-and-others-in-python-e-g-through-inheritance it says In Python 2.2, you can inherit from built-in classes such as int, list, dict, etc. So is it 3.5 or 2.2? For some reason google takes me to the 3.3 docs Replacing the 3.3 by 3.5 seems to keep the same entry -- https://mail.python.org/mailman/listinfo/python-list
Re: packaging code with compiled libraries
On Tuesday, October 6, 2015 at 1:14:05 AM UTC+5:30, Tim wrote: > And that seems to work, but after reading more from the Python Packaging > Authority, I wonder if that is the right way. Should I be using wheels > instead? > I think my brain fried a little bit while going through the doc. You are not alone https://mail.python.org/pipermail/python-list/2015-July/694818.html [last para] -- https://mail.python.org/mailman/listinfo/python-list
Re: Check if a given value is out of certain range
On Monday, October 5, 2015 at 7:58:34 AM UTC+5:30, Rustom Mody wrote: > On Sunday, October 4, 2015 at 7:18:11 PM UTC+5:30, Steven D'Aprano wrote: > > and some negations may technically be harder to understand, but in a > > practical sense the difference may be negligible: > > > > if x == 1: ... > > > > if x != 1: ... > > > > > > I refuse to believe that the second is *significantly* harder to reason > > about than the first. > > [With hermeneutic/semantic hat firmly on] > one could make a case that > "!=" ≠ "not =" ≠ "≠" > [Back with python hat] > My preference: > not 1 <= x <= 10 I take that back: Unarys binding looser than binaries is "yuck" (in my book) SO it would have to be not (1 <= x <= 10) -- https://mail.python.org/mailman/listinfo/python-list
Re: Check if a given value is out of certain range
On Sunday, October 4, 2015 at 7:18:11 PM UTC+5:30, Steven D'Aprano wrote: > On Sat, 3 Oct 2015 10:12 pm, Laura Creighton wrote: > > > Actually, the fact that adults have more difficulty processing > > negations is one of the earliest things proven experimentally > > in experimental psychology. > > I don't think I've questioned that under some circumstances some negations > can be hard to understand. I've certainly written my share of code > involving negatives that I've had to refactor to understand. A typical > example: > > def function(arg, dontpreprocess=False): > """Perform function on arg. If dontpreprocess is not true, > arg is preprocessed.""" > if not dontpreprocess: > arg = preprocess(arg) > ... > > And of course there are the legendary chains of negations: > > don't not cancel the preprocessor suppressor > > Does the preprocess run or not? :-) > > But I don't think we can jump from a general observation about negations to > the conclusion that a logical disjunction of two different comparisons is > necessarily easier to understand than a negated chained comparison. Some > negations are easy to understand: > > Don't touch that! > > and some negations may technically be harder to understand, but in a > practical sense the difference may be negligible: > > if x == 1: ... > > if x != 1: ... > > > I refuse to believe that the second is *significantly* harder to reason > about than the first. [With hermeneutic/semantic hat firmly on] one could make a case that "!=" ≠ "not =" ≠ "≠" [Back with python hat] My preference: not 1 <= x <= 10 -- https://mail.python.org/mailman/listinfo/python-list
Re: Terminology: "reference" versus "pointer"
On Sunday, September 13, 2015 at 5:32:44 AM UTC+5:30, Ned Batchelder wrote: > In its implementation, CPython uses pointers. But if you say that Python > has pointers because CPython uses pointers, then you might as well say > that Python is statically typed because the CPython source has type > declarations. It's a confusion of implementation and language to conflate > these two. Yes that "because" can be ridiculous/disingenuous. Good deal of it in this thread itself. Consider int. Say there are 10,000 int something_or_other; in the CPython sources Out of these say 50 are the direct implementation python's int The remaining 9950 C-ints have no direct correlate with python's int. The disingenuous reasoning is some kind of statistical argument of 10,000 vs 50. The reasonable reasoning is that only those 50 are relevant to the discussion. Likewise pointers If one were to trace the semantics of looking up a variable in CPython, one would find some C code doing pointer dereferencing. One would also find zillions of other uses of pointers that have no direct correlate to python's variables. What of it? If I were to be more technically correct than saying "Python's variables are C-pointers" I could say something like: "Python variables are C pointers with much stronger data-structure invariants related to ownership. And implemented with ref-counting, gc etc as scaffolding to ensure them. These stronger invariants make impossible in python common C errors like null-pointer referencing. The corresponding cost of these stronger invariants is that C's pointer type is rendered un-first-class in python" -- https://mail.python.org/mailman/listinfo/python-list
Re: Terminology: "reference" versus "pointer"
On Sunday, September 13, 2015 at 4:05:21 AM UTC+5:30, ru...@yahoo.com wrote: > On 09/12/2015 04:14 PM, Emile van Sebille wrote: > > On 9/12/2015 12:58 PM, rurpy--- via Python-list wrote: > > > >> The question is whether what "pointer" means in languages that use the > >> word is*so* different than its meaning in the Python sense > > > > I can't find a single reference to pointer in the python docs outside > > of ctypes. What is its python sense? > > I should have said "proposed sense" (except I don't really mean > proposed as in "let's change all the docs" but as "let's stop the > hissy-fits when someone uses the term"), i.e. the way I, I think > random832, and others use it re python. Sorry, I see in retrospect > my phrasing could be confusing. Here is my post a little way up: --- On Saturday, September 12, 2015 at 10:02:40 PM UTC+5:30, Steven D'Aprano wrote: > On Sat, 12 Sep 2015 02:42 pm, Random832 wrote: > > > Anyway, maybe we do need a term to distinguish Python/C#/Java pointers > > from C/C++ pointers - maybe call it a "non-arithmetic" pointer, since > > the key thing about it is you can't do pointer arithmetic on them to get > > the object "next to" the one it points at. > > How about *just don't call them pointers*? You know, since they aren't > pointers in the computer science sense. > > The Free On-line Dictionary of Computing defines "pointer": > >1. An address, from the point of view of a >programming language. A pointer may be typed, with its type >indicating the type of data to which it points. > Insisting that Python has pointers is like insisting that you use a text > editor by flipping bits. "What happens if I press Ctrl-X?" "Well, these > bits on the screen flip from black to white, these bits flip from white to > black, and these stay the same." > This is from the docs https://docs.python.org/3/library/functions.html#id id(object) Return the "identity" of an object. This is an integer which is guaranteed to be unique and constant for this object during its lifetime. Two objects with non-overlapping lifetimes may have the same id() value. CPython implementation detail: This is the address of the object in memory. --- which may be summarized as: 1. Steven (quoting Online dictionary): Pointer = Address 2. Steven: "Python has pointers" is ridiculous 3. Python docs: id returns an address in (C)Python To which we have Chris saying CPython ≠ Python Which reminds me of another definition Fig-Leaf: A device for converting poor porn into high art Even in languages like C with an ISO standard adhering to the standard is academic (gcc's switch is --pedantic) and it is in practice major implementations like gcc and MSC that define and push the standard. In python, CPython is the standard and other implementations can lay claim to being 'python' to the extent that they adhere to the standard. Or have I missed some ISO-ization? -- https://mail.python.org/mailman/listinfo/python-list
Re: Terminology: "reference" versus "pointer"
On Saturday, September 12, 2015 at 11:26:18 PM UTC+5:30, Akira Li wrote: > Rustom Mody writes: > > > On Saturday, September 12, 2015 at 8:11:49 PM UTC+5:30, Laura Creighton > > wrote: > >> In a message of Sat, 12 Sep 2015 05:46:35 -0700, Rustom Mody writes: > >> >How about lay-English ontology in which "point to" and "refer to" are > >> >fairly > >> >synonymous? > >> > >> This I have found is important in teaching, which is why I favour 'bind' > >> and 'binding' -- rather than pointer, pointer, refer to, referring. > > > > Well we can play humpty dumpty and make any word mean whatever we like. > > However if you are a teacher you will recognize a need for pictures. > > And (as far as I can tell) "Random832" finds a need for the box-n-arrow > > diagrams of classic data-structure books > > Speaking of pictures and names in Python > http://python.net/~goodger/projects/pycon/2007/idiomatic/handout.html#other-languages-have-variables Yeah cute [I think I will even use these in my classes] However they dont address the issue that I think random832 is referring to. viz. I have two variables (or names!) say a and b which look the same >>> a [[1,2],[1,2]] >>> b [[1,2],[1,2]] And yet doing >>> a[0][0] = "Oops!" gives a data structure one "Oops!" whereas doing it to b mysteriously gives 2 Best I can see you can only explain this seemingly-similar-but-structurally-different with box-n-arrow diagrams. Or some moral equivalent. And some people see no advantage to playing semantics and proclaiming "The arrows in C look similar to the arrows in python but they are not the same" -- https://mail.python.org/mailman/listinfo/python-list
Re: Terminology: "reference" versus "pointer"
On Saturday, September 12, 2015 at 10:38:46 PM UTC+5:30, Steven D'Aprano wrote: > On Sat, 12 Sep 2015 10:46 pm, Rustom Mody wrote: > > > On Saturday, September 12, 2015 at 11:57:01 AM UTC+5:30, Ben Finney wrote: > > >> You've clearly committed to some ontology that just doesn't match the > >> Python data model. > > > > How about lay-English ontology in which "point to" and "refer to" are > > fairly synonymous? > > "Pointer" in English is also a synonym for > > - a type of dog; > - an instrument which pierces (as used by engravers, lace workers, etc); > - an item of private information; > - a hint or tip; > - a caution or warning; > - a recommendation; > - the index finger; > - a cricketer fielding at a specific position; > - the hour/minute/second hand on a timepiece; > - a compass needle; > - two specific stars in the constellation of the Great Bear (Ursa Major); > - diagonal braces fastened across the hold of a ship; > - the small icon whose movement across the screen follows that of the > mouse, trackball or other pointing device; > - a signpost or milepost; > > and more. I don't think that arguing on the basis of lay-English or plain > English terms is going to be terribly useful. So if someone's ontology disagrees with yours its not very useful. You're welcome to that view of course Its called "Humpty-Dumpty" (in Alice ontology). We could have had a more 'useful' discussion if alongside the meanings of "pointer" you had provided meanings of "reference" as well -- https://mail.python.org/mailman/listinfo/python-list
Re: Terminology: "reference" versus "pointer"
On Saturday, September 12, 2015 at 9:47:33 PM UTC+5:30, rurpy wrote: > Frankly, I feel a little insulted by people who presume that having > learned what a pointer is in C, that my brain is so rigid that I must > necessarily think that pointer means exactly what pointer means in C > forever after. Its more amusing than insulting Just open CPython sources and there's a pointer on every other line Best I can see, the people frothing at the mouth that python has no pointers are basically saying that "non-first-class" == "non-existent" By that same logic C has neither types nor functions Speaking as a teacher, sometimes one needs to be clean and dishonest Sometimes one needs to be honest and mop up after leaky abstractions -- https://mail.python.org/mailman/listinfo/python-list
Re: Terminology: "reference" versus "pointer"
On Saturday, September 12, 2015 at 10:21:08 PM UTC+5:30, Steven D'Aprano wrote: > Python values are not addresses. Python values are objects. Which means for example...??? Atoms? Stars? People? Countries? > Addresses, even when they exist, are not accessible in the Python language. And you claim that these addresses are less accessible to python than the objects above? -- https://mail.python.org/mailman/listinfo/python-list
Re: Terminology: "reference" versus "pointer"
On Saturday, September 12, 2015 at 10:02:40 PM UTC+5:30, Steven D'Aprano wrote: > On Sat, 12 Sep 2015 02:42 pm, Random832 wrote: > > > Anyway, maybe we do need a term to distinguish Python/C#/Java pointers > > from C/C++ pointers - maybe call it a "non-arithmetic" pointer, since > > the key thing about it is you can't do pointer arithmetic on them to get > > the object "next to" the one it points at. > > How about *just don't call them pointers*? You know, since they aren't > pointers in the computer science sense. > > The Free On-line Dictionary of Computing defines "pointer": > >1. An address, from the point of view of a >programming language. A pointer may be typed, with its type >indicating the type of data to which it points. > Insisting that Python has pointers is like insisting that you use a text > editor by flipping bits. "What happens if I press Ctrl-X?" "Well, these > bits on the screen flip from black to white, these bits flip from white to > black, and these stay the same." > This is from the docs https://docs.python.org/3/library/functions.html#id id(object) Return the "identity" of an object. This is an integer which is guaranteed to be unique and constant for this object during its lifetime. Two objects with non-overlapping lifetimes may have the same id() value. CPython implementation detail: This is the address of the object in memory. -- https://mail.python.org/mailman/listinfo/python-list
Re: Terminology: "reference" versus "pointer"
On Saturday, September 12, 2015 at 8:11:49 PM UTC+5:30, Laura Creighton wrote: > In a message of Sat, 12 Sep 2015 05:46:35 -0700, Rustom Mody writes: > >How about lay-English ontology in which "point to" and "refer to" are fairly > >synonymous? > > This I have found is important in teaching, which is why I favour 'bind' > and 'binding' -- rather than pointer, pointer, refer to, referring. Well we can play humpty dumpty and make any word mean whatever we like. However if you are a teacher you will recognize a need for pictures. And (as far as I can tell) "Random832" finds a need for the box-n-arrow diagrams of classic data-structure books -- https://mail.python.org/mailman/listinfo/python-list
Re: Terminology: "reference" versus "pointer"
On Saturday, September 12, 2015 at 11:57:01 AM UTC+5:30, Ben Finney wrote: > Random832 writes: > > > Ben Finney writes: > > > The reference value is inaccessible to the program, it can only be > > > used to get at the referenced object. > > > > What does it mean to access something, if not to do some operation on > > it? Getting the referenced object is the operation you can do with it. > > You've clearly committed to some ontology that just doesn't match the > Python data model. How about lay-English ontology in which "point to" and "refer to" are fairly synonymous? -- https://mail.python.org/mailman/listinfo/python-list
Re: Python handles globals badly.
On Friday, September 11, 2015 at 9:27:46 PM UTC+5:30, rand...@fastmail.us wrote: > On Fri, Sep 11, 2015, at 11:55, Chris Angelico wrote: > > On Sat, Sep 12, 2015 at 1:49 AM, Ian Kelly wrote: > > > Ah, that makes sense. It's writing into the dict that is created and > > > returned by locals(), but not actually updating the frame locals which > > > are the source of truth. > > > > Yeah... but it only makes sense to people who understand the > > implementation. It's certainly not a logical and sane behaviour that > > would be worth documenting and using. > > What else would you document? Reading from them is a reasonable thing to > do, and works. Writing to them is a reasonable thing to want to do, but > won't work, so you need to document that it doesn't work. This is actually an old elusive holy grail -- first class environments. In denotational semantics the two tools used to model variables and control-flow respectively are environments and continuations. The Scheme inventors were brave enough to mandate first-class continuations but could not make the courage for first-class environments. So every Scheme dialect introduces 1½ class envs in a ½-assed inconsistent way Likewise python's locals-dicts and (I am guessing) most languages with some commitment to first-classness -- https://mail.python.org/mailman/listinfo/python-list
Re: Context-aware return
On Friday, September 11, 2015 at 12:53:28 AM UTC+5:30, Grant Edwards wrote: > On 2015-09-10, Steven D'Aprano wrote: > > > I have a function which is intended for use at the interactive interpreter, > > but may sometimes be used non-interactively. I wish to change it's output > > depending on the context of how it is being called. > > [...] > > Sounds like an excellent way to waste somebody's afternoon when they > start to troubleshoot code that's using your function. Over and over > and over we tell newbies who have questions about what something > returns or how it works > > "Start up an interactive session, and try it!". > > If word gets out about functions like yours, we sort of end up looking > like twits. > > > If I did this thing, would people follow me down the street booing > > and jeering and throwing things at me? > > Only the people who use your function. :) In emacs: You can make a function a 'command' by putting an (interactive) into it. And then in the function if you check interactive-p (nowadays more fashionably 'called-interactively-p' ) then it can figure out whether it was called from elisp or from emacs (top level)... and then change behavior accordingly. IOW this behavior is quite routine in emacs-land The norm being - Some functions are meant to be called only from Lisp - Some functions (commands) only from emacs - And then there are the 'Steven-functions' I find it curious that the people getting upset about this are all the emacs users [as far as I know] ;-) -- https://mail.python.org/mailman/listinfo/python-list
Re: Context-aware return
On Friday, September 11, 2015 at 12:53:28 AM UTC+5:30, Grant Edwards wrote: > On 2015-09-10, Steven D'Aprano wrote: > > > I have a function which is intended for use at the interactive interpreter, > > but may sometimes be used non-interactively. I wish to change it's output > > depending on the context of how it is being called. > > [...] > > Sounds like an excellent way to waste somebody's afternoon when they > start to troubleshoot code that's using your function. Over and over > and over we tell newbies who have questions about what something > returns or how it works > > "Start up an interactive session, and try it!". > > If word gets out about functions like yours, we sort of end up looking > like twits. > > > If I did this thing, would people follow me down the street booing > > and jeering and throwing things at me? > > Only the people who use your function. :) In emacs: You can make a function a 'command' by putting an (interactive) into it. And then in the function if you check interactive-p (nowadays more fashionably 'called-interactively-p' ) then it can figure out whether it was called from elisp or from emacs (top level)... and then change behavior accordingly. IOW this behavior is quite routine in emacs-land The norm being - Some functions are meant to be called only from Lisp - Some functions (commands) only from emacs - And then there are the 'Steven-functions' I find it curious that the people getting upset about this are all the emacs users [as far as I know] ;-) -- https://mail.python.org/mailman/listinfo/python-list
Re: Python handles globals badly.
On Friday, September 11, 2015 at 10:04:25 AM UTC+5:30, Marko Rauhamaa wrote: > Ian Kelly : > > > You can use tabs *or* spaces. If you want to mix the two, then there > > would need to be some official decision made about how many spaces > > compose a tab, and then everybody who wants to use tabs would have to > > configure their editors to conform to that decision, or risk breaking > > their code. Some people like to indent two spaces. Some people like to > > indent four spaces. On the other hand, the de facto standard for > > terminal tab width is eight spaces. However, virtually nobody prefers > > eight spaces of indentation. So the question is which standard are you > > going to adopt, and which groups are you going to upset? > > Indentation preferences and the interpretation of TABs are two separate > things. Required reading http://www.jwz.org/doc/tabs-vs-spaces.html -- https://mail.python.org/mailman/listinfo/python-list
Re: Program in or into (was Python handles globals badly)
On Sunday, September 6, 2015 at 8:05:28 AM UTC+5:30, Steven D'Aprano wrote: > On Sat, 5 Sep 2015 01:18 pm, Rustom Mody wrote: > > > Here's mergesort written in various languages > > http://rosettacode.org/wiki/Sorting_algorithms/Merge_sort > > > > You could look at the java if you like but I think C# takes the cake. > > And of course also there's the python > > > > Now the thought experiment: > > > > For some reason you need to code in C# > > [You need to do this part of the experiment honestly!!] > > > > Would you write the C# code? > > Or would you write the python-ish code in C# ? > > > That depends. Is the example C# code idiomatic for the language? Or was it > written by somebody ignorant of C#, and consequently is a poor example of > badly-written and unidiomatic "Java in C#"? > > If the first, then I expect I would write the C# code, because it is > idiomatic and works. What would you do? I'd cringe And suspect malefide intent on the part of those who wrote that code to show C# in bad light :-) Thats partly joke because the java looks somewhat better and C# and Java are not very different My main point of course was that between the two extremes: 1. What the language mandates eg python mandates a ':' after the if condition C mandates that it be parenthesized 2. Matters of free personal taste there is a large in-between grey area where the language's 'keepers' recommend best (and not) practices which may not exactly be the best for a programmer. eg Consider perl and python. As for regex support they are mostly the same Yet a typical pythonista takes pride that he wrote a 10 line re-free function where a 2-line re would have sufficed A typical perl guy will take pleasure in exactly the opposite achievement A programmer wanting to get his job done need not believe any of these fads&fancies -- https://mail.python.org/mailman/listinfo/python-list
Program in or into (was Python handles globals badly)
On Saturday, September 5, 2015 at 7:24:47 AM UTC+5:30, Chris Angelico wrote: > Indeed. The key to being a good programmer is not "write your code > despite the language you're using", but "write the code in the > language you're using". > A thought experiment for you Chris! Here's mergesort written in various languages http://rosettacode.org/wiki/Sorting_algorithms/Merge_sort You could look at the java if you like but I think C# takes the cake. And of course also there's the python Now the thought experiment: For some reason you need to code in C# [You need to do this part of the experiment honestly!!] Would you write the C# code? Or would you write the python-ish code in C# ? -- https://mail.python.org/mailman/listinfo/python-list
Re: Hello
On Thursday, September 3, 2015 at 10:37:04 AM UTC+5:30, Phuong Phan wrote: > Hi Python community, Hi Phuong Phan > I am new to Python and currently taking one online course of computer science > and programming using Python. I really like Python because it is simple and > clarity but powerful to me. > I just joint Python mailing list and i hope to enjoy Python programming > discussion with you all. > Thank you, > phuong phan You're welcome! You may find the tutor list more useful for you if you are just beginning https://mail.python.org/mailman/listinfo/tutor -- https://mail.python.org/mailman/listinfo/python-list
Re: How to compare lists
On Tuesday, September 1, 2015 at 12:54:08 PM UTC+5:30, Jahn wrote:
> 1.
> How can I save 256 lists, each list has 32 values( hexadecimal numbers)
> 2.
> How to compare the saved lists with another 256 lists ( that are read online
> and have the
> same structure as the list one)?
> ( the first list must be saved in the previous step)
To add to what the others have said/asked:
Many times programmers want sets but they are programmed(!!) to think "Lists!"
This can be because for example
>>> [1,2,3] == [2,1,3]
False
>>> {1,2,3} == {2,1,3}
True
>>> [1,2,3,3] == [1,2,3]
False
>>> {1,2,3,3} == {1,2,3}
True
>>> list(set([1,2,1,3,4,4,]))
[1, 2, 3, 4]
[Though theres no guarantee of the order of the last (that I know) ]
ie you may prefer sets to lists when order and/or repetition dont signify
>
> E.g
???
--
https://mail.python.org/mailman/listinfo/python-list
Re: AttributeError: 'module' object has no attribute '__path__'
On Tuesday, September 1, 2015 at 3:46:15 AM UTC+5:30, Laura Creighton wrote: > Can you make the effort to move your cursor to the bottom of > the mail you are replying to, before you start typing, > so that your reply comes after what was said before, instead of > first thing, and thus before what was said before. In gmail its trivially simple but not all that obvious: There are 3 tiny little dots below which conceal the earlier context. You have to click that to open it. And then start entering below that [Thanks to ChrisA I now know you can also Ctrl-A to open it. Where does Chris find out such arcana I wonder?!] -- https://mail.python.org/mailman/listinfo/python-list
Re: OFF-TOPIC Ben's sig monster quote [was Re: Parametrized Unit Tests]
On Friday, August 28, 2015 at 11:56:53 AM UTC+5:30, Steven D'Aprano wrote: > Completely off-topic. Stop reading now if you only want to read things about > Python. > > > On Fri, 28 Aug 2015 09:46 am, Ben Finney wrote: > > > \ “Of course, everybody says they're for peace. Hitler was for | > > `\ peace. Everybody is for peace. The question is: what kind of | > > _o__) peace?” —Noam Chomsky, 1984-05-14 | > > > With the greatest of respect to Chomsky, I think he is simply wrong about > Hitler. Hitler actually believed that war was good for the national > character, and indeed good for the soul, and that long periods of peace > would enfeeble a nation and make it decadent and effete. Unlike a lot of > people who believe the same thing, Hitler actually had experience in war, > including a medal for bravery and a serious injury due to poison gas. > > Many people over the ages have thought that if only war was more terrible, > we would stop making it. Alas, that appears to be false: no matter how > terrible war is, there is always someone who thinks that it is better than > peace. If you focus on war then no-war is not an option. However we could switch focus a bit from war to semantics and hear the – by humanity timescale – recent (in)famous reference to 'crusade' made by a well-known mensa-IQ head of state... And thence to the underlying mythologies Most every culture/religion I know has a '2-tier' mythology thus: Tier 1. Be nice, Be good, Turn the other cheek, Practice Non-Violence and other such good stuff Tier 2. When the above doesn't work and push comes to shove, mow the 'other guy' down and you are doing God's work (or God himself is doing it... depending on culture) So then people think these mythologies are a/the problem and super-wisely remove them from the education of the rising generation. And then we have new mythologies to replace the old ones -- Superman, Star-Wars... Hollywood in general which 'betters' the earlier mythologies by making good/evil more black&white and removing all question-marks. Its is an elegant separation of concerns: Blood on the screen, popcorn in the lap And inbetween these two mythologies are all the war-mongering ones — martyr, patriot, son-of-the-soil… hero I find it amazing how people cant see that «terrorist» from one side is «freedom-fighter» from the other. To see the consequences that the semantics of our words have, consider this thought-experiment: «X» is holed-up in town T and authorities need to get him out Replace «X» by 'murderer' and bombing out the whole of T to get him looks implausible, unthinkable Replace «X» by 'terrorist' and its suddenly routine Long-story short: The enunciation "terrorist" is as much an act of terror as the acts of the "terrorist" Or Rambo.desugared() == murderer == OBL.desugared() [Making that equation more relevant to context and correspondingly polit incorrect is left as an exercise to the reader] Those who wish to abjure war may consider re/de-educating their children on this matter रुसि [For GG to please not mess my unicode] -- https://mail.python.org/mailman/listinfo/python-list
Re: Please don't make unfounded legalistic demands
On Wednesday, August 26, 2015 at 8:59:44 PM UTC+5:30, Ben Finney wrote: > Terry Reedy writes: > > > I disagree with prohibiting people encumbered by such systems from > > participating. > > I have no power to prohibit people here. I do strongly request that such > threatening legalistic screeds stay away from this forum. Does it really matter? We see right here - outright spam - useful stuff - borderline spam viz. interminable grumbles about top-posting, google-groups html-mail etc etc etc with nary a python issue in sight I dont think anyone would read these with the same eyes (so to speak). Why not treat Jean-Michel (and such) mails with a corresponding double-standard? -- https://mail.python.org/mailman/listinfo/python-list
Re: Sometimes bottle takes a lot of time
On Saturday, August 22, 2015 at 9:03:52 PM UTC+5:30, Michael Torrie wrote: > While it's true this particular problem is possibly beyond the scope of > this python list (and may not be python-related at all), it's too bad a > couple of people have taken the time to reply to your queries to simply > berate you. Yeah -- quite uncalled for. As for beyond scope, I believe Peter Otten recommended bottle just a few days ago. So I dont see whats improper about the question. At some point of course someone may say: "Bottle written in python doesn't mean this is a python question." If after that the questions continue and they are persistent and asinine and... then berating may be ok. Dont see that here -- https://mail.python.org/mailman/listinfo/python-list
Re: Bug!
On Saturday, August 22, 2015 at 6:32:56 AM UTC+5:30, Chris Angelico wrote: > On Sat, Aug 22, 2015 at 9:53 AM, sohcahtoa82 wrote: > > On Friday, August 21, 2015 at 3:42:36 PM UTC-7, hamilton wrote: > >> On 8/21/2015 1:41 PM, Chris Angelico wrote: > >> > Python 3.5 does not support Windows XP. > >> > >> Is there a simple explanation for this ? > >> > >> Or is it just is. > > > > I have no relationship with the Python developers, but I would say that > > running such an old operating system is simply irresponsible due to > > security issues and should be discouraged in any way possible. > > > > Windows XP is 14 years old. In the computing world, that's *ancient*. > > It's time to upgrade and join the modern world. > > The security concerns of XP aren't Python's problem, and Python isn't > in the business of twisting people's arms to make them upgrade just > for the sake of upgrading. However, every new version of Windows > introduces new APIs and features, so maintaining support for an older > version means ignoring all features added since then; conversely, > dropping support for XP means taking advantage of anything that was > added in Vista. That's why the change in support. And it can cost a pretty penny: when someone upgrades from XP (say) to something modern like Windows 10 it almost certainly requires buying a new machine. One of the charms of linux used to be (dunno how true today) that it could run reasonably well on extremely underpowered hardware -- https://mail.python.org/mailman/listinfo/python-list
Re: memory control in Python
On Tuesday, August 18, 2015 at 3:40:11 AM UTC+5:30, Ping Liu wrote: > Hi, Dieter, > > If I move from Python to Jython or IronPython, do I need to retool whatever I > have done? If so, that may take quite a long time. This may make the > reimplementation impossible. Hi Ping There is a message from Laura Creighton that may be useful to you that googlegroups shows in the thread: "python implementation of a new integer encoding algorithm." Thought I'd mention in case you are not seeing other threads. [How she (her mail client) manages to befuddle googlegroups thusly is quite a mystery... ] -- https://mail.python.org/mailman/listinfo/python-list
Re: "no module named kivy" import error in ubuntu 14.04
On Monday, August 17, 2015 at 10:35:48 AM UTC+5:30, rurpy wrote: > I hope someday Python gets a decent packaging/distribution story. You are in august company | The final question was about what he (Guido) hates in Python. "Anything to do | with package distribution", he answered immediately. There are problems | with version skew and dependencies that just make for an "endless | mess". He dreads it when a colleague comes to him with a "simple Python | question". Half the time it is some kind of import path problem and | there is no easy solution to offer. >From https://mail.python.org/pipermail/python-list/2015-July/694818.html Quoting https://lwn.net/Articles/651967/ -- https://mail.python.org/mailman/listinfo/python-list
Re: Python 3 sort() problem
On Monday, August 17, 2015 at 7:32:08 PM UTC+5:30, Владислав wrote: > # first: works fine > x = [1, 2, 4, 2, 1, 3] > x = list(set(x)) > x.sort() > print(x) # output: 1, 2, 3, 4 > > # second: why x became None ?? > x = [1, 2, 4, 2, 1, 3] > x = list(set(x)).sort() > print(x) # output: None > I know that sort() returns None, but I guess that it would be returned x that > was sorted. Why so? > > > Maybe you want sorted? >>> x = [4,2,1,3] >>> sorted(x) [1, 2, 3, 4] [The list(set(..)) is probably for removing duplicates. Right? Which you seem to have worked out it seems? So best when asking questions to focus on one issue at a time] -- https://mail.python.org/mailman/listinfo/python-list
Re: "no module named kivy" import error in ubuntu 14.04
On Monday, August 17, 2015 at 7:30:14 AM UTC+5:30, Chris Angelico wrote: > On Mon, Aug 17, 2015 at 5:16 AM, shiva upreti wrote: > > I am new to linux. I tried various things in attempt to install kivy. I > > installed python 2.7.10 (I think python3 was already installed in ubuntu > > 14.04). Then i downloaded kivy from > > https://pypi.python.org/packages/source/K/Kivy/Kivy-1.9.0.tar.gz, extracted > > it and tried to execute "python setup.py" inside the kivy folder. > > As Laura said, the preferred way to install under Ubuntu would be to > use apt-get. But if you want to install directly from PyPI, the best > way is to use pip. Those are two package managers, which remove from > you the hassle of hunting down all the different dependencies, like > Cython. Try apt-get first, and if that doesn't do what you're looking > for, use pip (maybe inside a virtualenv). It'll chug for a while and > then give you what you need. Its not vanilla apt-get but ppa-apt-get (as Laura's link indicates) -- https://mail.python.org/mailman/listinfo/python-list
Re: Old DbaseV DOS Programmer wants to step over to new/actual modern program software
On Sunday, August 16, 2015 at 10:10:18 PM UTC+5:30, AGOSTINHO TEIXEIRA wrote: > I'm a 25year DBASE-5 DOS programmer and want/have to step over to new > program/platform software, because there is no future anymore for DOS after > W-XP, I've been looking around for alternatives and cannot figure out where > to start, I already have been learning the SQL with SSMS database > system/script this is very important because I work mostly with large > databases invoicing/stock/statements etc. I always manage my users with > design-programs,windows-input,files-views, using custom made windows/input. I > did all this in *.prg files with hard-coding. I have some ideas in mind like > Java with (ECLIPS) because it is very popular, it is the most widely used and > can get tutorials and videos all over the internet. I've read a lot of good > things about Python, that it is much easier but too complicate to define what > to choose, at the first place witch version 2.x or 3.x, a lot of IDE's to > choose from, beside of that witch IDE with what pluggin. I'll need something > suitable to manage/manipulat e M-SQL. I have a lot of programs to rewrite and not much time, that's why it is very important to me to start with something appropriate with the best software combination that I can learn completely from the internet, cannot go back to the classroom, too old for that. I appreciate very much that any of you can help me to figure out to choose the right software combination for my new project. Thanks! Questions 1. Are you talking MSQL, MS-SQL? Quite different and also different from MySQL 2. How bound are you to your DBMS? If you are going to anyway port DBase-V to a modern DBMS, you can as well choose a more python-friendly one -- one of postgres, MySql, Sqlite. Anyways... Assuming you are committed to MsSql, I'd suggest in sequence: 1. Forget about DBMS and study the python tutorial for a few days 2. Forget get about *your* DBMS and play around with Sqlite that runs out of the box. This will familiarize you with python's DBMS model without the headaches of installing many pieces of softwares 3. Pick a python MsSql library and port your stuff to that -- https://mail.python.org/mailman/listinfo/python-list
Re: How to model government organization hierarchies so that the list can expand and compress
On Saturday, August 15, 2015 at 5:12:13 AM UTC+5:30, Alex Glaros wrote: > 3. Could not find Laura's response. Was it deleted? I dont see it either. I expect its in some other thread Laura's mail client is doing funny things to threading... Something Ive been noticing for a few days -- https://mail.python.org/mailman/listinfo/python-list
Re: Is Django the way to go for a newbie?
On Friday, August 14, 2015 at 6:35:27 AM UTC+5:30, Michael Torrie wrote: > On 08/10/2015 10:08 PM, Rustom Mody wrote: > > On Tuesday, August 11, 2015 at 8:59:47 AM UTC+5:30, Michael Torrie wrote: > >> On 08/10/2015 07:49 PM, Dwight GoldWinde wrote: > >>> Thank you, Gary, for this new information. > >>> > >>> I will be looking into virtualenv and vertualenvwrapper. > >>> > >>> I thought that Django was an IDE. But, it seems that an IDE is one more > >>> thing that I need that I didn¹t know I needed!? > >> > >> Django is a programming _library_ (also called a framework) > > > > Please dont conflate library and framework. > > Library, framework, DSL are different approaches for solving similar > > problems. > > I personally tend to prefer DSL's, dislike frameworks and am neutral to > > libraries. > > Which is why I would tend to start with flask + template-language + ORM > > rather than start with a framework. > > Others may have for very good reasons different preferences and that is > > fine¹. > > > > But if you say equate all these, discussion becomes a mess. > > Ahh. Well at least you didn't rail on me for being too lazy to > capitalize acronyms like html. No I am not trolling :-) > > Given that until recently he thought Django was an IDE, I think calling > Django a library is fair, as it describes to him how it relates to > Python. You download it and install it and it goes in site-packages > along with all the other libraries you might install. Of course it > comes with utilities as well (which I mentioned). Making the > distinctions you are making, in this context, is probably ultimately > going to be confusing to him at this stage of the game. As he gets > familiar with django I don't think he'll find this original > simplification confusing, nor has it seemed to make this discussion a mess. > True. Purposive, directed lying is usually better pedagogy than legalistic correctness. > As to the DSL, I'm not quite sure which part of django you're getting > at. Are you referring to the (optional) templating system? Nothing specifically Django I am getting at. Just that learning - a templating engine -- eg Cheetah, Mako - an ORM eg SQLAlchemy - etc is more fun than learning to chant the right mantras that a framework demands without any clue of what/why/how I dont know Django. Used RoR some years ago and it was frightening. And Ruby is not bad. So I assume Rails is. I just assumed -- maybe ignorantly -- that Django and RoR are generically similar systems -- https://mail.python.org/mailman/listinfo/python-list
Re: Is Django the way to go for a newbie?
On Tuesday, August 11, 2015 at 8:59:47 AM UTC+5:30, Michael Torrie wrote: > On 08/10/2015 07:49 PM, Dwight GoldWinde wrote: > > Thank you, Gary, for this new information. > > > > I will be looking into virtualenv and vertualenvwrapper. > > > > I thought that Django was an IDE. But, it seems that an IDE is one more > > thing that I need that I didn¹t know I needed!? > > Django is a programming _library_ (also called a framework) Please dont conflate library and framework. Library, framework, DSL are different approaches for solving similar problems. I personally tend to prefer DSL's, dislike frameworks and am neutral to libraries. Which is why I would tend to start with flask + template-language + ORM rather than start with a framework. Others may have for very good reasons different preferences and that is fine¹. But if you say equate all these, discussion becomes a mess. - ¹ html + js + css is a good example of how/why the DSL approach can lead to a mess. Curl shows a better way https://en.wikipedia.org/wiki/Curl_%28programming_language%29 aside from the politics -- https://mail.python.org/mailman/listinfo/python-list
Re: OT Re: Math-embarrassment results in CS [was: Should non-security 2.7 bugs be fixed?]
On Sunday, August 9, 2015 at 2:57:20 AM UTC+5:30, Marko Rauhamaa wrote:
> Marko Rauhamaa :
>
> > Steven D'Aprano :
> >
> >> The contemporary standard approach is from Zermelo-Fraenkel set
> >> theory: define 0 as the empty set, and the successor to n as the
> >> union of n and the set containing n:
> >>
> >> 0 = {} (the empty set)
> >> n + 1 = n ∪ {n}
> >
> > That definition barely captures the essence of what a number *is*. In
> > fact, there have been different formulations of natural numbers.
>
> Rehashing this old discussion. I ran into this wonderful website:
>
> http://at.metamath.org/mpeuni/mmset.html>
Attention you Hilbertian!
Gödelian here — http://blog.languager.org/2015/07/cs-history-2.html
:-)
Thanks for that link. Need to study it carefully
--
https://mail.python.org/mailman/listinfo/python-list
Re: Who uses IDLE -- please answer if you ever do, know, or teach
On Thursday, August 6, 2015 at 6:36:56 AM UTC+5:30, Terry Reedy wrote: > There have been discussions, such as today on Idle-sig , about who uses > Idle and who we should design it for. If you use Idle in any way, or > know of or teach classes using Idle, please answer as many of the > questions below as you are willing, and as are appropriate > > Private answers are welcome. They will be deleted as soon as they are > tallied (without names). > > I realized that this list is a biased sample of the universe of people > who have studied Python at least, say, a month. But biased data should > be better than my current vague impressions. > > 0. Classes where Idle is used: > Where? > Level? > > Idle users: > > 1. Are you > grade school (1=12)? > undergraduate (Freshman-Senior)? > post-graduate (from whatever)? > > 2. Are you > beginner (1st class, maybe 2nd depending on intensity of first)? > post-beginner? > > 3. With respect to programming, are you > amateur (unpaid) > professional (paid for programming) > > -- > Terry Jan Reedy, Idle maintainer I used idle to teach a 2nd year engineering course last sem It was a more pleasant experience than I expected One feature that would help teachers: It would be nice to (have setting to) auto-save the interaction window [Yeah I tried to see if I could do it by hand but could not find where] Useful for giving as handouts of the class So students rest easy and dont need to take 'literal' notes of the session I will now be teaching more advanced students and switching back to emacs -- python, C, and others -- so really no option to emacs. Not ideal at all but nothing else remotely comparable -- https://mail.python.org/mailman/listinfo/python-list
Re: Most Pythonic way to store (small) configuration
On Thursday, August 6, 2015 at 6:32:03 AM UTC+5:30, Rustom Mody wrote: > By contrast here is a more friendly error message (had put a comma where a > colon > required) > Traceback (most recent call last): > File "", line 1, in > File "/usr/lib/python3.4/ast.py", line 46, in literal_eval > node_or_string = parse(node_or_string, mode='eval') > File "/usr/lib/python3.4/ast.py", line 35, in parse > return compile(source, filename, mode, PyCF_ONLY_AST) > File "", line 2 > "i", 1} Uh... The more helpfulness not evident as the most crucial line not cut-pasted Heres the full bt Traceback (most recent call last): File "", line 1, in File "/usr/lib/python3.4/ast.py", line 46, in literal_eval node_or_string = parse(node_or_string, mode='eval') File "/usr/lib/python3.4/ast.py", line 35, in parse return compile(source, filename, mode, PyCF_ONLY_AST) File "", line 2 "i", 1} ^ SyntaxError: invalid syntax -- https://mail.python.org/mailman/listinfo/python-list
Re: Most Pythonic way to store (small) configuration
On Thursday, August 6, 2015 at 2:31:52 AM UTC+5:30, Tim Chase wrote:
> On 2015-08-05 06:37, Rustom Mody wrote:
> > > config = {}
> > > with open('config.ini') as f:
> > > for row in f:
> > > row = row.strip()
> > > if not row or row.startswith(('#', ';')):
> > > continue
> > > k, _, v = row.partition('=')
> > > config[k.strip().upper()] = v.lstrip()
> > >
> > > which is pretty straight-forward and easy format to edit.
> > >
> > > -tkc
> >
> > JSON handles basic types like this:
> > >>> from json import loads
> > >>> loads("""{"anInt":1, "aString":"2"}""")
> > {'aString': '2', 'anInt': 1}
>
> But requires the person hand-editing the file to make sure that
> opening braces close, that quoted text is properly opened/closed, has
> peculiarities regarding things following back-slashes, etc.
>
> There's a certain simplicity to simply having key/value pairs
> separated by an "=" and then letting the application do whatever it
> needs/wants with those key/value strings.
>
> -tkc
I just checked that literal_eval accepts comments.
So thats one plus for that.
However I must admit that in checking that out I was faced with more than
(I) expected unfriendly error messages like
Traceback (most recent call last):
File "", line 1, in
File "/usr/lib/python3.4/ast.py", line 84, in literal_eval
return _convert(node_or_string)
File "/usr/lib/python3.4/ast.py", line 62, in _convert
in zip(node.keys, node.values))
File "/usr/lib/python3.4/ast.py", line 61, in
return dict((_convert(k), _convert(v)) for k, v
File "/usr/lib/python3.4/ast.py", line 83, in _convert
raise ValueError('malformed node or string: ' + repr(node))
ValueError: malformed node or string: <_ast.Name object at 0x7fe1173ebac8>
By contrast here is a more friendly error message (had put a comma where a colon
required)
Traceback (most recent call last):
File "", line 1, in
File "/usr/lib/python3.4/ast.py", line 46, in literal_eval
node_or_string = parse(node_or_string, mode='eval')
File "/usr/lib/python3.4/ast.py", line 35, in parse
return compile(source, filename, mode, PyCF_ONLY_AST)
File "", line 2
"i", 1}
So overall whether ast.literal_eval is a good idea is not clear to me
--
https://mail.python.org/mailman/listinfo/python-list
Re: Is this an example of tail recursion?
On Wednesday, August 5, 2015 at 10:11:30 PM UTC+5:30, wrote:
> On Wednesday, August 5, 2015 at 10:29:21 AM UTC-6, Chris Angelico wrote:
> > On Thu, Aug 6, 2015 at 2:10 AM, Rustom Mody wrote:
> > > 1 + x
> > > does not *call* 1 .__add__(x)
> > > It *is* that
> > > [Barring corner cases of radd etc]
> > > IOW I am desugaring the syntax into explicit method-calls so you can see
> > > all the calls explicitly
> > > Then it becomes evident -- visibly and in fact --that the tail call is the
> > > __add__ method not the solderdiersVsDefenders
> >
> > Except that it *isn't* that, precisely because of those other cases.
> > When Python sees an expression like "1 + x" and doesn't yet know what
> > x is, it can't do anything other than record the fact that there'll be
> > a BINARY_ADD of the integer 1 and whatever that thing is. That object
> > might well define __radd__, so the call is most definitely not
> > equivalent to the operator.
> >
> > And the ultimate result of that addition might not even be a function
> > call at all, if it's implemented in C. Or if you're running in PyPy
> > and the optimizer turned it into machine code. So no, even though you
> > can define addition for *your own classes* using __add__ or __radd__,
> > you can't reinterpret every addition as a function call.
> >
> > ChrisA
>
> Good (intricate) point.
And I continue to have no idea what Chris is talking about.
Here is C printf
>>> from ctypes import *
>>> cdll.LoadLibrary("libc.so.6")
>>> libc = CDLL("libc.so.6")
>>> libc.printf(b"%s", b"Hello")
5
Hello>>>
As far as I can see printf is a C function and its behaving like (an
ill-behaved) python function as well.
Likewise for anything else written ina C extension module
Or a C-builtin
If its callable from within python its python
That it may also be C seems to me beside the point
[As I said I dont get the point]
--
https://mail.python.org/mailman/listinfo/python-list
