Illegal suggestions on python list
On Thu, Jul 4, 2013 at 9:16 PM, Steven D'Aprano < steve+comp.lang.pyt...@pearwood.info> wrote: > On Thu, 04 Jul 2013 07:02:26 -0700, rusi wrote: > > > On Thursday, July 4, 2013 7:03:19 PM UTC+5:30, Steve Simmons wrote: > >> Boy oh boy! You really are a slow learner Nicos. You have just offered > >> to commit a crime and to include dozens of others in that crime ON A > >> PUBLIC FORUM. Please think before you post. > > > > For the record Steve, let me say, I find Robert Kern's objection barely > > sufficient. > > > > And yours less than that. > > > > Note that you are not objecting to the crime > > Which crime is that? Presumably you mean an actual criminal felony, not a > mere civil offence. Under which jurisdiction? > > > > but to the public > > expression of it. Just look at your objection from the angle of a police > > officer, and you will see that it can certainly be construed as > > abetment/collusion > > If piracy is a crime, and not just a civil offence, then surely so is > libel. You have just accused Steve Simmons of collusion in a felony, > based on absolutely no evidence at all. That's as clear a case of libel > as I've ever seen. Although I'm not sure that the damages should be > terribly high -- there's little evidence that anyone treats your > ridiculously exaggerated claims about other people's supposed crimes as > anything but hot air. > > But, putting damages aside, according to what passes for the reasoning > that you have demonstrated here, your committing libel would make you > equally a "petty criminal" as Nikos. > > > Speaking of petty, this whole witch-hunt is getting ridiculous. Don't you > have something more productive to do? Accusing people of colluding in > crimes because they fail to be sufficiently zealous in "objecting to the > crime" is nuts. > > > -- > Steven > -- > http://mail.python.org/mailman/listinfo/python-list > You've got your OO class hierarchy mixed up and then imposing that on me. See http://www.nolo.com/legal-encyclopedia/crimes-felonies-misdemeanors-infractions-classification-33814.html I did not say or suggest felony. Maybe misdemeanor or infarction. Dunno which. IANAL... -- http://mail.python.org/mailman/listinfo/python-list
Re: Important features for editors
On Sat, Jul 6, 2013 at 4:36 AM, Cameron Simpson wrote: > While I started with vi just slightly before encountering emacs > (mid-to-late 1980s, both), my main trouble with choosing emacs was > the heavy use of control keys. Vi's modal nature means that in > "edit" mode, all the keystrokes are available as edit controls. > Emacs' modeless nature means that all the edit controls must be > control-this and meta/escape-that. > > For this reason, I often expand EMACS as Escape Meta Alt Control Shift. > > Yes... The fact that rms has crippling RSI should indicate that emacs' ergonomics is not right. > I'm a vi user. Once I mastered "hit ESC by reflex when you pause > typing an insert" I was never confused above which mode I was in. > > And now my fingers know vi. > > Yes... vi: (n) A program that has two modes, one in which it beeps and the other in which it corrupts your file :-) > Cheers, > -- > Cameron Simpson > > A novice of the temple once approached the Chief Priest with a question. > > "Master, does Emacs have the Buddha nature?" the novice asked. > > The Chief Priest had been in the temple for many years and could be > relied > upon to know these things. He thought for several minutes before > replying. > > "I don't see why not. It's got bloody well everything else." > > With that, the Chief Priest went to lunch. The novice suddenly achieved > enlightenment, several years later. > > Commentary: > > His Master is kind, > Answering his FAQ quickly, > With thought and sarcasm. > > Heard somewhere: Emacs is my operating system and linux is its device driver. No I dont belong to that camp -- Actually I am quite dissatisfied with emacs nowadays... Keep trying eclipse and getting repulsed by the gorilla. Philosophy being this: What functional programming is to program-semantics, fast-branching (as in git) is to program-source[1]. To complete the trinity, one needs semi-automated refactoring. The first I can do in my sleep; the second still noob-status, the third yet to start! [1] Not necessarily source-code See http://blog.vctr.me/posts/why-you-should-learn-git.html -- http://mail.python.org/mailman/listinfo/python-list
semi-programmer-ish envs/apps using python
Some systems use python as a glue to make environments which are used by professionals that are not primarily programmers. Some egs: Scientific prog with Scipy+matplotlib Data analysis with pandas Visual arts with processing (Is pyprocessing stable enough?) Linguistics with nltk Is there such a list somewhere? -- http://mail.python.org/mailman/listinfo/python-list
Re: Important features for editors
On Sat, Jul 6, 2013 at 12:22 PM, Eric S. Johansson wrote: > ** > On Fri, 05 Jul 2013 23:13:24 -0400, Rustom Mody > wrote: > > Yes... > The fact that rms has crippling RSI should indicate that emacs' ergonomics > is not right. > > > > As someone crippled by Emacs ( actual cause not known), I should also > point out that RMS, instead of doing the responsible thing and using speech > recognition software, burns the hands of other human beings by using them > as biological speech recognition units. > > Hope youve seen this http://www.cs.princeton.edu/~arora/RSI.html -- http://mail.python.org/mailman/listinfo/python-list
Re: Keyboard Layout: Dvorak vs Colemak: is it Worthwhile to Improve the Dvorak Layout?
On Jun 13, 6:19 pm, Steven D'Aprano wrote: > Even if we accept that Dvorak is an optimization, it's a micro- > optimization. +1 Dvorak -- like qwerty and any other keyboard layout -- assumes the computer is a typewriter. This means in effect at least two constraints, necessary for the typewriter but not for the computer: a. The typist can type only 1 key at a time b. One (key)stroke generates exactly 1 letter Exceptions to are Shift (Ctrl) etc but clearly in running use they are the exception not the rule. > Where speed really is vital, such as for court stenographers, special > mechanical > shorthand machines such as stenotypes are used, costing thousands of dollars > but allowing > the typist to reach speeds of over 300 wpm. Yes, instruments like stenotypes speed up typing by unassuming Likewise pianists can be said (and seen) to do more at the piano than typists at a computer because chords are part of the 'allowed language'. Assumption likewise is unnecessarily restrictive on a computer. Think of all the 'abbrev/snippet/shortform/template' systems like yasnippet, textmate-snippets, emacs/vi abbrevs etc. For ordinary English there are things like keyscript http://www.freewebs.com/cassyjanek For example the most common words (estimated to be around 40% of English) are shortformed as: b = but c = with d = had e = this f = of g = that h = the j = which n = and ...etc etc upto z = was then common phrases able to = cb had been = dn do not = dx did not = ex does not = dsx etc Clearly, for programmers this is unlikely to be much use -- programming languages are not English. But but it is certainly an open question whether if the repeating patterns in programming languages are captured into some system, the resulting benefit would be a mere micro-optimization or something more significant. I have seen some good programmers swear by emacs-yasnippets, textmate-snippets etc. -- http://mail.python.org/mailman/listinfo/python-list
Re: regex question
MRAB wrote: > findall returns a list of tuples (what the groups captured) if there is more than 1 group, > or a list of strings (what the group captured) if there is 1 group, or a list of > strings (what the regex matched) if there are no groups. Thanks. It would be good to put this in the manual dont you think? Also, the manual says in the 'match' section "Note If you want to locate a match anywhere in *string*, use search()instead." to guard against users using match when they should be using search. Likewise it would be helpful if the manual also said (in the match,search sections) "If more than one match/search is required use findall" -- http://mail.python.org/mailman/listinfo/python-list
Re: Function "modes" vs. separate functions (was: PyWart: os.path needs immediate attention!)
Ben Finney said: > But this is all getting rather generic and abstract. What specific > real-world examples do you have in mind? regex match vs regex search? -- http://mail.python.org/mailman/listinfo/python-list
Re: Deeply nested dictionaries - should I look into a database or am I just doing it wrong?
I use pyyaml for such. http://yaml.org/ The builtin json support http://docs.python.org/library/json.html is a bit weaker but has the advantage of no extra install -- http://mail.python.org/mailman/listinfo/python-list
Re: Non Programming in python
On Wed, May 11, 2011 at 5:57 PM, Calvin Spealman wrote: > If this is the "non-programming side of python" then maybe some of us have > a lacking definition of what "programming" is. My mechanic stilll has to > check the tire pressure and I need to update the version number in PyPI. > O well you dont like the term 'non-programming'? As I said neither do I... On May 10, 2011 12:46 PM, "rusi" wrote: > > Sorry for a silly subject change: A better one will be welcome -- cant > think of a name myself. > > Maybe another way of describing this list may be 1. Programming from 'inside' or 'under' python and 2. The rest of it which is outside/surrounding the python interpreter Because 1 is mostly called 'programming' and 2 has no name, 2 gets neglected more than it should. Or take any python book and browse the contents. What will you find? Python data structures, Python control structures, OOP in python, advanced function topics, scopes, modules, exceptions etc -- almost all the 'inside' stuff well organized, with the outside stuff strewn around in hard-to-find corners of the index (if at all). Does that reflect the reality of python's actual learning curve? -- http://mail.python.org/mailman/listinfo/python-list
Re: A question on modification of a list via a function invocation
On Monday, September 4, 2017 at 7:50:22 AM UTC+5:30, Chris Angelico wrote: > On Mon, Sep 4, 2017 at 12:05 PM, Steve D'Aprano wrote: > > On Mon, 4 Sep 2017 04:15 am, Stephan Houben wrote: > > > >> Needless to say, according to the definition in Plotkin's paper, Python > >> is "call-by-value". > > > > According to Plotkin's definition, when you pass a value like a 100MB > > string: > > > > "This is a long string of text..." # continues on for millions more > > characters > > > > does the interpreter make a copy of the 100MB string? > > > > If not, then it isn't pass (call) by value. > > This is another proof that you can't divide everything into "pass by > value" vs "pass by reference", unless you mess around with "passing a > reference by value" or other shenanigans. In C, a string is not an > entity; it's simply an array of characters. Arrays are never passed by > value; yet everything in C is passed by value. So you pass a > pointer... by value. > > What would you define LISP's semantics as? Pass by value? Pass by > reference? Pass by name? Pass by immutability? Pass the salt? “Pass the logic" “Oops…” “You slob! You’ve messed my consistency-carpet." Earlier Ben Bacarisse wrote: > The core of the idea is actually what the value-set of Python programs is -- Yes! That!! Parameter-passing models and nomenclature is really a red-herring Its the “== is id” mess that is at the base of the mess: Simply put: pythonistas have no coherent/consistent sense of what python values are. And the endless parameter-passing-nomenclature arguments are just the fallout of that. Maybe that’s what Ben means by?? > the passing by value just drops out of that. -- https://mail.python.org/mailman/listinfo/python-list
Re: meaning of [ ]
On Sunday, September 3, 2017 at 5:10:13 PM UTC+5:30, Rick Johnson wrote:
> Andrej Viktorovich wrote:
> > I suppose p becomes array of strings but what [] means in this statement?
>
> Generally, it's an inline form of writing a loop that returns a list. There
> are other types as well.
Tsk tsk the confusioning continues
Rewrite
[p for p in sys.path]
as
[p | p ∈ sys.path]
Is that clearer?
And then as
{p | p ∈ sys.path}
And refresh the idea of set-builder notation
http://www.mathwords.com/s/set_builder_notation.htm
Note the the clunky ascii-fication of (most) programming languages (including
python)
is a minor distraction
The bigger and more real issue is that sets and lists are similar and different
Sets have no order, lists are ordered
As Peter pointed out this is a no-op
ie
[p for p in sys.path]
could be written as
list(sys.path)
[Not sure why he didnt say just sys.path]
Anyway this is a good example to distinguish
[p for p in sys.path]
from
{p for p in sys.path}
Both work in python
But the second is probably not correct because path-searching is order dependent
--
https://mail.python.org/mailman/listinfo/python-list
Re: A question on modification of a list via a function invocation
On Monday, September 4, 2017 at 1:46:55 PM UTC+5:30, Gregory Ewing wrote: > Stefan Ram wrote: > > JavaScript and Python do not have references as values > > Yes, they do. The difference is that they don't have any > way of *not* having references as values, so there's less > need to use the word explicitly in that way -- most of > the time it's just understood. Well then why these long threads that get nowhere 😎? > Nevertheless, terms such > as "object reference" and "reference to an object" do > get used in relation to Python when clarity is needed. Its because reference (or pointer or …) is central to python's semantics that we need to use them to talk/explain/understand. Its because pointers have been de-first-classed (from C say, as a starting point) that the disagreements arise: - One bunch feel that since they've been de-first-classed they've been removed And could/should not be mentioned - The others feel that since the removal is ½-assed we need to talk of them anyway. All thats gone is the '*' which has become implicit from C's explicit -- https://mail.python.org/mailman/listinfo/python-list
Re: A question on modification of a list via a function invocation
On Monday, September 4, 2017 at 3:35:54 PM UTC+5:30, Antoon Pardon wrote: > Op 04-09-17 om 00:44 schreef Dennis Lee Bieber: > > And is a limited theoretical study, heavy in mathematics and light in > > implementation. > > > > Programming Languages: Design and Implementation (Terrence W Pratt, > > 1975, Prentice-Hall) has a whole section (6-9 Subprograms with Parameters: > > Parameter Transmission Techniques)... > > > > """ > > Basic parameter Transmission Techniques > > > > Transmission by Value: ... the actual parameter is evaluated at the point > > of call. The /values/ of the actual parameter is then transmitted to the > > subprogram and becomes the initial value associated with the corresponding > > formal parameter. ... > > > > Transmission by Reference (Location or Simple Name): In transmission by > > reference a pointer is transmitted, usually a pointer to a data location > > containing the value. ... Any assignment to Y in SUB will change the value > > of X back in the calling program. > > IMO that depends on the semantics of the assignment statement. In an > environment > where an assignment copies the value into the object the variable points to, > this > is correct. However if assignment provides a new object that is now bound to > the > variable, it is incorrect. > > The diagram below tries to illustrate the two different assignment semantics: > > BEFORE > +-+ +-+ > | | | | > | 5 | | 7 | > | | | | > +-+ +-+ > > ^ ^ > | | > > > > x = y > AFTER > > C style| Python style >| > +-+ +-+ | +-+ > | | | | | | | > | 7 | | 7 | | | 7 | > | | | | |---> | | > +-+ +-+ | / +-+ > / > ^ ^ / ^ > | | /| > That's fine as far as it goes But then you have people (Steven above) who feel that python passing has no exceptions (in parameter passing) Does a poor job AFAIAC of explaining the difference between foo and bar in foll >>> def foo(x): x += 2 >>> def bar(x): x.append(2) >>> a=10 >>> b=[10] >>> foo(a) >>> a 10 >>> bar(b) >>> b [10, 2] >>> -- https://mail.python.org/mailman/listinfo/python-list
Re: meaning of [ ]
On Monday, September 4, 2017 at 6:36:11 PM UTC+5:30, Ben Bacarisse wrote:
> Rustom Mody writes:
>
> > On Sunday, September 3, 2017 at 5:10:13 PM UTC+5:30, Rick Johnson wrote:
> >> Andrej Viktorovich wrote:
> >> > I suppose p becomes array of strings but what [] means in this statement?
> >>
> >> Generally, it's an inline form of writing a loop that returns a
> >> list. There are other types as well.
> >
> > Tsk tsk the confusioning continues
> >
> > Rewrite
> > [p for p in sys.path]
> > as
> > [p | p ∈ sys.path]
> >
> > Is that clearer?
> >
> > And then as
> >
> > {p | p ∈ sys.path}
> > And refresh the idea of set-builder notation
> > http://www.mathwords.com/s/set_builder_notation.htm
>
> But [p for p in sys.path] is a list and "set-builder" notation is used
> for sets. Order is crucial for sys.path. You say exactly that below so
> I don't see how referring to sets helps anyone understand lists.
Clearly if the question was of *sets* vs *lists* the distinction is at least as
crucial, maybe even more so than the similarity.
The OP-question here however is one about comprehensions and it appears without
the questioner realizing that — as Peter's answer showed
See the very first line of this:
https://en.wikipedia.org/wiki/List_comprehension
“List comprehension follows the form of the mathematical set-builder notation
(set comprehension)”
ie its both historically and structurally linked
IOW emphasising the incidental sequential nature of the computation
at the cost of the fundamental structure-preserving nature of the concept
>
>
> > As Peter pointed out this is a no-op
> > ie
> > [p for p in sys.path]
> >
> > could be written as
> > list(sys.path)
>
> Both make a copy -- that's not a no-op. It may be a very-little-op but
> not nothing.
Its important…
- whether the machine stack grows up or down
- whether the bytes are ordered little-endian or big-endian
- whether IO is polled or interrupt driven
- whether IO ports are memory-mapped or in separate IO space
And much else
Yet for most people doing most things today in most languages,
these questions are irrelevated
The question of copying is likewise, from a certain point of view, irrelevant.
Of course the further context of the OP may have a mutation on the list
And if he does end up changing sys.path, and not intending it, that would be
a source of nasty bugs for sure
But why assume all that when he does not (yet) know what it is he is writing
More importantly thinks its a *command* when its actually an *expression*
etc? (IMHO an unfortunate consequence of the confusing overloading of the 'for'
keyword)
>
> > [Not sure why he didnt say just sys.path]
>
> Because he wanted code equivalent to [p for p in sys.path].
>
> > Anyway this is a good example to distinguish
> >
> > [p for p in sys.path]
> > from
> > {p for p in sys.path}
> >
> > Both work in python
> > But the second is probably not correct because path-searching is order
> > dependent
>
> Right. So i'm puzzled why you suggest that [p for p in sys.path] should
> be understood by reading about set-builder notation.
Since "-builder" and "-comprehension" (in this context) are synonymous??
[ https://en.wikipedia.org/wiki/Set-builder_notation ]
And I am ready to make a small wager
- that the OP knows of these
- with math-hat on
- And is simply confused by the clunky ASCII syntax
--
https://mail.python.org/mailman/listinfo/python-list
Re: A question on modification of a list via a function invocation
On Monday, September 4, 2017 at 5:58:18 PM UTC+5:30, ROGER GRAYDON CHRISTMAN wrote: > >Does a poor job AFAIAC of explaining the difference between foo and bar in > foll def foo(x): x += 2 > def bar(x): x.append(2) > a=10 > b=[10] > foo(a) > a > >10 > bar(b) > b > >[10, 2] > > Or with just one function: >>> def baz(x,y): > x += y > >>> a = 10 > >>> b = [10] > >>> baz(a,a) > >>> a > 10 > >>> baz(b,b) > >>> b[10, 10] Ha Ha! Lovely [I was about to ask Chris if he is being serious about relating this to the presence of '=' ] However if you desugar the += into __iadd__ then someone may argue the presence of the = is an optical illusion -- https://mail.python.org/mailman/listinfo/python-list
Re: meaning of [ ]
On Monday, September 4, 2017 at 7:57:23 PM UTC+5:30, Rustom Mody wrote:
> On Monday, September 4, 2017 at 6:36:11 PM UTC+5:30, Ben Bacarisse wrote:
> > But [p for p in sys.path] is a list and "set-builder" notation is used
> > for sets. Order is crucial for sys.path. You say exactly that below so
> > I don't see how referring to sets helps anyone understand lists.
>
> Clearly if the question was of *sets* vs *lists* the distinction is at least
> as
> crucial, maybe even more so than the similarity.
> The OP-question here however is one about comprehensions and it appears
> without
> the questioner realizing that — as Peter's answer showed
>
> See the very first line of this:
> https://en.wikipedia.org/wiki/List_comprehension
> “List comprehension follows the form of the mathematical set-builder notation
> (set comprehension)”
>
> ie its both historically and structurally linked
> IOW emphasising the incidental sequential nature of the computation
> at the cost of the fundamental structure-preserving nature of the concept
Incomplete; I meant to say:
ie its both historically and structurally linked.
IOW emphasising the incidental sequential nature of the computation
at the cost of the fundamental structure-preserving nature of the concept
seems to be some ()*&^$W# behavior on the part of people instructing python
The essential meaning of comprehensions is the following diagrams
not the for-loop implementation
If l is
[x₁, x₂,… xₙ ]
[f(x) for x in l]
means this picture:
[x₁, x₂,…xₙ ]
↓ ↓… ↓
[f(x₁), f(x₂),… f(xₙ)]
Likewise
If s is
{x₁, x₂,… xₙ}
{f(x) for x in s}
means this picture:
{x₁, x₂, … xₙ}
↓ ↓ … ↓
{f(x₁), f(x₂),… f(xₙ)}
--
https://mail.python.org/mailman/listinfo/python-list
Re: A question on modification of a list via a function invocation
On Monday, September 4, 2017 at 7:50:39 PM UTC+5:30, Steve D'Aprano wrote: > On Mon, 4 Sep 2017 01:11 pm, Rustom Mody wrote: > > Simply put: pythonistas have no coherent/consistent sense of what python > > values are. And the endless parameter-passing-nomenclature arguments are > > just > > the fallout of that. > > This is not a dispute unique to the Python community. Similar arguments take > place in the Java and Ruby communities, and I daresay many others. Well good to know we agree on this [I would add lisp to this list since its the progenitor of this model] And it is a primary factor for the desirability of transcending the imperative paradigm -- https://mail.python.org/mailman/listinfo/python-list
Re: A question on modification of a list via a function invocation
On Monday, September 4, 2017 at 8:37:45 PM UTC+5:30, Steve D'Aprano wrote: > On Tue, 5 Sep 2017 12:34 am, Rustom Mody wrote: > > > On Monday, September 4, 2017 at 5:58:18 PM UTC+5:30, ROGER GRAYDON CHRISTMAN > > wrote: > >> Or with just one function: >>> def baz(x,y): > >> x += y > >> >>> a = 10 > >> >>> b = [10] > >> >>> baz(a,a) > >> >>> a > >> 10 > >> >>> baz(b,b) > >> >>> b[10, 10] > > > > Ha Ha! Lovely > > > > [I was about to ask Chris if he is being serious about relating this to the > > presence of '=' ] > > > > However if you desugar the += into __iadd__ then someone may argue > > the presence of the = is an optical illusion > > I'm afraid I can't quite follow what people think this example actually > demonstrates. Anton gave a picture explaining why/how references are needed and to be understood I pointed out that while that picture is fine (and necessary) as part of the explanation, it does not properly address the central question of this thread, viz How to understand parameter passing in python. With this example: >>> def foo(x): x += 2 >>> def bar(x): x.append(2) >>> a=10 >>> b=[10] >>> foo(a) >>> a 10 >>> bar(b) >>> b [10, 2] >>> Roger Christman compressed my foo and bar into one baz def baz(x,y): x += y Which leaks or doesnt leak x-modifications depending on its type -- https://mail.python.org/mailman/listinfo/python-list
Re: A question on modification of a list via a function invocation
On Monday, September 4, 2017 at 9:13:43 PM UTC+5:30, Steve D'Aprano wrote: > On Tue, 5 Sep 2017 01:17 am, Rustom Mody wrote: > > > Anton gave a picture explaining why/how references are needed and to be > > understood > > Antoon gave a picture demonstrating one model of Python's semantics. > > It's a nice model that has a lot going for it, in particular that it matches > the > most obvious implementation. But it doesn't describe *Python* semantics, it > describes an overlap between Python the language and the implementation of the > Python interpreter. > > In particular, consider the picture of a name binding to a value: > > > +-+ > | | > | 5 | > | | > +-+ > ^ > | > > > > This picture has three entities, but only two of them exist in Python: > > - the object 5; > > - the name "x" (names are not values in Python at runtime, but they > are entities which exist in Python source code at compile time). > > The third entity is the reference linking the name to the object (the arrow). > This isn't a runtime value in Python, nor is it a compile time entity that > exists in source code. It is pure implementation, and as such, exists outside > of the Python domain. A common fallacy: https://en.wikipedia.org/wiki/Begging_the_question Python does not have references/pointers/whatever ∴ Python does not have references (or whatever you want to (not) call it) -- https://mail.python.org/mailman/listinfo/python-list
Re: meaning of [ ]
On Monday, September 4, 2017 at 10:42:47 PM UTC+5:30, Rick Johnson wrote:
> On Monday, September 4, 2017 at 9:27:23 AM UTC-5, Rustom Mody wrote:
> > On Monday, September 4, 2017 at 6:36:11 PM UTC+5:30, Ben Bacarisse wrote:
> > > Rustom Mody writes:
> > >
> > > > On Sunday, September 3, 2017 at 5:10:13 PM UTC+5:30, Rick Johnson wrote:
> > > >> Andrej Viktorovich wrote:
> > > >> > I suppose p becomes array of strings but what [] means in this
> > > >> > statement?
> > > >>
> > > >> Generally, it's an inline form of writing a loop that returns a
> > > >> list. There are other types as well.
> > > >
> > > > Tsk tsk the confusioning continues
> > > >
> > > > Rewrite
> > > > [p for p in sys.path]
> > > > as
> > > > [p | p ∈ sys.path]
> > > >
> > > > Is that clearer?
> > > >
> > > > And then as
> > > >
> > > > {p | p ∈ sys.path}
> > > > And refresh the idea of set-builder notation
> > > > http://www.mathwords.com/s/set_builder_notation.htm
> > >
> > > But [p for p in sys.path] is a list and "set-builder" notation is used
> > > for sets. Order is crucial for sys.path. You say exactly that below so
> > > I don't see how referring to sets helps anyone understand lists.
> >
> > Clearly if the question was of *sets* vs *lists* the
> > distinction is at least as crucial, maybe even more so than
> > the similarity.
>
> What made you assume the OP question had anything to do with
> sets versus lists? I didn't get that impression. Not to say
> that i could not be wrong, but i see no reason to believe i
> am.
I assume you are addressing this to Ben Bacarisse.
If to me then I am saying mostly what you are (in above para!)
>
> > The OP-question here however is one about comprehensions
> > and it appears without the questioner realizing that — as
> > Peter's answer showed
>
> My understanding of the impetus of the OP's question is a
> simple matter of attempting to intuit the structure of a
> list comprehension in the realms of Python code. Not a
> question as to the supposed "impurity" of python list
> comprehension form compared with set notation form. But
> again, i could be wrong.
My understanding is that the OP saw a 'for' inside a '[]' and wondered
"WTF is this?"
>
> > See the very first line of this:
> > https://en.wikipedia.org/wiki/List_comprehension
> > “List comprehension follows the form of the mathematical
> > set-builder notation (set comprehension)”
>
> I'm not sure if we should consider Wikipedia an "official"
> definition of the Python language, but if it were up to me,
> i would have chosen my words more carefully, as in: "List
> comprehension follows _loosely_ the form of the mathematical
> set-builder notation (set comprehension)”. My understanding
> that list comprehensions were borrowed from other languages.
Wikipedia is probably not the best definer for math either
In any case here its a question of how and what is the link between
a math concept/notation and its form/semantics in python
>
> > ie its both historically and structurally linked IOW
> > emphasising the incidental sequential nature of the
> > computation at the cost of the fundamental structure-
> > preserving nature of the concept
> > >
> > >
> > > > As Peter pointed out this is a no-op
> > > > ie
> > > > [p for p in sys.path]
> > > >
> > > > could be written as
> > > > list(sys.path)
> > >
> > > Both make a copy -- that's not a no-op. It may be a very-little-op but
> > > not nothing.
> >
> >
> > Its important…
> > - whether the machine stack grows up or down
> > - whether the bytes are ordered little-endian or big-endian
> > - whether IO is polled or interrupt driven
> > - whether IO ports are memory-mapped or in separate IO space
> > And much else
> >
> > Yet for most people doing most things today in most languages,
> > these questions are irrelevated
>
> Of course. Just as pointers and memory management are
> irrelevant...
careful! In an ideal world they should be irrelevant
Some knotty problems in python cannot be prized apart without talking of these
>
> > The question of copying is likewise, from a certain point
> > of view, irrelevant.
> >
> > Of course the further context of the OP m
Please improve these comprehensions (was meaning of [ ])
Since these discussions are uselessly abstract and meta
Here is some code I (tried) to write in class the other day
The basic problem is of generating combinations
Using the pascal-identity nCr + nC(r-1) = (n+1)Cr
This can be written (Haskell)
c :: Int -> Int -> Int
c n 0 = 1
c 0 (r+1) = 0
c (n+1) (r+1) = c n r + c n (r+1)
But I dont want NUMBER of combinations I want to generate combinations from
a given set
So change the spec to
c :: [a] -> Int -> [[a]]
ie n stops being a number but is now a set (here list) length n
c n 0 = [[]]
c [] (r+1) = []
c (x:xs) (r+1) = [x:l | l <- c xs r] ++ c xs (r+1)
Runs
? c [1,2,3,4] 2
[[1, 2], [1, 3], [1, 4], [2, 3], [2, 4], [3, 4]] :: [[Int]]
All binomials
? [c [1,2,3,4] r | r <- [0..4]]
[
[[]],
[[1], [2], [3], [4]],
[[1, 2], [1, 3], [1, 4], [2, 3], [2, 4], [3, 4]],
[[1, 2, 3], [1, 2, 4], [1, 3, 4], [2, 3, 4]],
[[1, 2, 3, 4]]
] :: [[[Int]]]
Now thats neat as far as it goes but combinations are fundamentally sets
not lists
So I thought python would do a better job
I tried translating it to python and sets but it turned out more annoying than
helpful
Can someone improve it??
The straightforward translation of the above
Which is ok so far
def c(n,r):
if r == 0:
return [[]]
elif len(n) == 0:
return []
else:
return [[n[0]] + l for l in c(n[1:],r-1)] + c(n[1:],r)
Now to go from returning list of lists to set of sets:
st = frozenset
nullset = st([])
def singleton(x): return st([x])
def splitset(s):
i = iter(s)
e = next(i)
new = st(i)
return e,new
def cs(n,r):
""" Set version of c"""
if r == 0 :
return singleton(nullset)
elif len(n) == 0 :
return nullset
else:
x,xs = splitset(n)
return st([(singleton(x) | l) for l in cs(xs,r-1)]) | cs(xs,r)
def ss0n(fs):
""" Shows a simple-set (ie set-0, contains no subsets) nicely"""
r = "{"
for x in fs:
r += repr(x) + ", "
return r + "}"
def ss1n(fs0):
""" Shows a set-of-sets (ie set-1, contents are sets) nicely"""
r = "{"
for x in fs0:
r += ss0n(x) + ", "
return r + "}"
>>> cs({1,2,3,4}, 2)
frozenset([frozenset([2, 4]), frozenset([3, 4]), frozenset([2, 3]),
frozenset([1, 3]), frozenset([1, 2]), frozenset([1, 4])])
>>> ss1n(cs({1,2,3,4}, 2))
'{{2, 4, }, {3, 4, }, {2, 3, }, {1, 3, }, {1, 2, }, {1, 4, }, }'
>>> ss1n(cs({1,2,3,4}, 2))
'{{2, 4, }, {3, 4, }, {2, 3, }, {1, 3, }, {1, 2, }, {1, 4, }, }'
So how could this be done better?
Here for reference is an abstract math ideal I would like to approximate
c : {t} → Int → {{t}} ## t is an arbitrary unspecified type
c n 0 = {{}}
c {} (r+1) = {}
c ({x} ∪ xs) (r+1) = {{x} ∪ l | l ∈ c xs r} ∪ c xs (r+1)
exactly parallel to the pascal identity
c n 0 = 1
c 0 (r+1) = 0
c (n+1) (r+1) = c n r + c n (r+1)
--
https://mail.python.org/mailman/listinfo/python-list
Re: Please improve these comprehensions (was meaning of [ ])
On Tuesday, September 5, 2017 at 1:44:24 AM UTC+5:30, Ben Bacarisse wrote:
> Rustom Mody writes:
>
> > Here is some code I (tried) to write in class the other day
> >
> > The basic problem is of generating combinations
>
> > Now thats neat as far as it goes but combinations are fundamentally sets
> > not lists
> >
> > So I thought python would do a better job
> > I tried translating it to python and sets but it turned out more annoying
> > than
> > helpful
> > Can someone improve it??
> >
> > The straightforward translation of the above
> > Which is ok so far
> >
> >
> > def c(n,r):
> > if r == 0:
> > return [[]]
> > elif len(n) == 0:
> > return []
> > else:
> > return [[n[0]] + l for l in c(n[1:],r-1)] + c(n[1:],r)
> >
> >
> > Now to go from returning list of lists to set of sets:
>
> def cs(n, r):
> if r == 0:
> return [set()]
> elif len(n) == 0:
> return []
> else:
> return [set([n[0]]) | l for l in cs(n[1:], r-1)] + cs(n[1:], r)
>
> ?
>
> It's not so neat if you also want n to be a set rather than a list
> because the set equivalents of n[0] and n[1:] are a but more complex but
> it's not that bad:
>
> def css(n,r):
> if r == 0:
> return [set()]
> elif len(n) == 0:
> return []
> else:
> rest = n.copy()
> e = rest.pop()
> return [set([e]) | l for l in css(rest, r-1)] + css(rest, r)
Trying out your code Ben…
>>> css({1,2,3,4}, 2)
[set([1, 2]), set([1, 3]), set([1, 4]), set([2, 3]), set([2, 4]), set([3, 4])]
>>> type(css({1,2,3,4}, 2))
Whereas with the cs I earlier gave:
>>> cs(frozenset([1,2,3,4]), 2)
frozenset([frozenset([2, 4]), frozenset([3, 4]), frozenset([2, 3]),
frozenset([1, 3]), frozenset([1, 2]), frozenset([1, 4])])
>>> type(cs(frozenset([1,2,3,4]), 2))
So in case I did not make it clear enough earlier, there are three collection
types in the spec.
A small amount of meta-combinatorics on the combinatorics!
Lets say
{1,2} : ℘ Int ## powerset
[1,2] : ℒ Int ## list type constructor
There are many others eg
⟆1,2⟅ : ℬ Int ## Bag type constructor
Not to mention iterators
Lets just stay with set and list for simplicity
So the combinations enumerator has the general type (schema)
[For ℛ being one of the above collection type constructors]
c : ℛ t → Int → ℛ ℛ t
However each of these ℛ's could be different
c : ℛ₁ t → Int → ℛ₂ ℛ₃ t
This gives 8 possibilities (assuming 2 constructors)
Your function had type
css : ℘ t → Int → ℒ ℘ t
whereas I wanted
cs : ℘ t → Int → ℘ ℘ t
And this has not yet touched on the difference between set and frozenset!
Why do we need frozenset at all?
Because the set type wont close in python!
## List of lists... ok
>>> [[1,2],[3,4]]
[[1, 2], [3, 4]]
## List of sets slightly clunky but still ok
>>> [{1,2},{3,4}]
[set([1, 2]), set([3, 4])]
## Set of sets??… Sorry!!
>>> {{1,2},{3,4}}
Traceback (most recent call last):
File "", line 1, in
TypeError: unhashable type: 'set'
--
https://mail.python.org/mailman/listinfo/python-list
Re: A question on modification of a list via a function invocation
On Tuesday, September 5, 2017 at 6:42:07 PM UTC+5:30, Gregory Ewing wrote: > Steve D'Aprano wrote: > > The third entity is the reference linking the name to the object (the > > arrow). > > This isn't a runtime value in Python, nor is it a compile time entity that > > exists in source code. It is pure implementation, and as such, exists > > outside > > of the Python domain. > > The fact that there is a connection between the name and the > object is very much part of Python's abstract semantics. > > There are different ways to implement that connection, but > *any* implementation of Python has to include *some* > representation of it. > > There are also different words that can be used to describe > it. You can say that names are bound to objects, or that > names refer to objects, or that names hold references to > objects. These are all equally good ways of talking about > the exact same abstract concept. > > To me this argument about whether Python has references > or not is like an American person saying that cars have > hoods, and a British person saying he's wrong, hoods > are an implementation detail and cars actually have > bonnets instead. Also called playing humpty-dumpty I believe there is a germ of value behind all this empty polemics There are 3 equivalence relations: 1. == — mathematical, too coarse to understand nuances of python semantics 2. is — machine representation, too fine to be useful 3. graph (or topological) equality which experienced pythonistas have internalized in understanding when two data structures are same or different [Roughly Anton's diagrams that are beyond my drawing capability!] And yet pythonistas need that to understand python data structures >>> a = [1,2] >>> b = [a,a] >>> c = [[1,2],[1,2]] >>> b == c True >>> b is c False >>> p = [1,2] >>> q = [p,p] >>> r = [[1,2],[1,2]] >>> q == r True >>> q is r False >>> b == q True >>> b == r True >>> b is q False >>> b is r False Now the pythonista understands that b and c may be math-= but have different structure Whereas b is graph-equal to q And c is graph-equal to r However there is no available operation to show/see that distinction The trouble is that graph-isomorphism is NP-complete so the crucial operation cannot be reasonably implemented Let the endless threads continue 😈 -- https://mail.python.org/mailman/listinfo/python-list
Re: Please improve these comprehensions (was meaning of [ ])
On Tuesday, September 5, 2017 at 6:59:11 PM UTC+5:30, Ben Bacarisse wrote:
> Rustom Mody writes:
>
> > On Tuesday, September 5, 2017 at 1:44:24 AM UTC+5:30, Ben Bacarisse wrote:
> >> Rustom Mody writes:
> >>
> >> > Here is some code I (tried) to write in class the other day
> >> >
> >> > The basic problem is of generating combinations
> >>
> >> > Now thats neat as far as it goes but combinations are fundamentally sets
> >> > not lists
> >> >
> >> > So I thought python would do a better job
> >> > I tried translating it to python and sets but it turned out more
> >> > annoying than
> >> > helpful
> >> > Can someone improve it??
> >> >
> >> > The straightforward translation of the above
> >> > Which is ok so far
> >> >
> >> >
> >> > def c(n,r):
> >> > if r == 0:
> >> > return [[]]
> >> > elif len(n) == 0:
> >> > return []
> >> > else:
> >> > return [[n[0]] + l for l in c(n[1:],r-1)] + c(n[1:],r)
> >> >
> >> >
> >> > Now to go from returning list of lists to set of sets:
> >>
> >> def cs(n, r):
> >> if r == 0:
> >> return [set()]
> >> elif len(n) == 0:
> >> return []
> >> else:
> >> return [set([n[0]]) | l for l in cs(n[1:], r-1)] + cs(n[1:], r)
> >>
> >> ?
> >>
> >> It's not so neat if you also want n to be a set rather than a list
> >> because the set equivalents of n[0] and n[1:] are a but more complex but
> >> it's not that bad:
> >>
> >> def css(n,r):
> >> if r == 0:
> >> return [set()]
> >> elif len(n) == 0:
> >> return []
> >> else:
> >> rest = n.copy()
> >> e = rest.pop()
> >> return [set([e]) | l for l in css(rest, r-1)] + css(rest, r)
> >
> > Trying out your code Ben…
> >
> >>>> css({1,2,3,4}, 2)
> > [set([1, 2]), set([1, 3]), set([1, 4]), set([2, 3]), set([2, 4]), set([3,
> > 4])]
> >
> >>>> type(css({1,2,3,4}, 2))
> >
> >
> > Whereas with the cs I earlier gave:
> >>>> cs(frozenset([1,2,3,4]), 2)
> > frozenset([frozenset([2, 4]), frozenset([3, 4]), frozenset([2, 3]),
> > frozenset([1, 3]), frozenset([1, 2]), frozenset([1, 4])])
>
> If you want a (frozen) sets of sets I'd just the code to
>
> def css(n, r):
> if r == 0:
> return frozenset({frozenset()})
> elif len(n) == 0:
> return frozenset()
> else:
> rest = set(n)
> e = rest.pop()
> return frozenset([frozenset([e])
> | l for l in list(css(rest, r-1))]) | css(rest, r)
>
> >>> css(frozenset({1,2,3,4}), 2)
> frozenset({frozenset({2, 4}), frozenset({3, 4}), frozenset({2, 3}),
> frozenset({1, 3}), frozenset({1, 2}), frozenset({1, 4})})
>
> The switch from lists (using +) and frozen sets using | is the most
> obvious change, but if the top-level argument might itself be a
> frozenset then the copy must be changed to a set constructor so that pop
> will work.
Yes…
Pop et al wont work with frozen sets
Containment wont work with sets — what mathematicians call 'not closed'
All of which amounts to this that python sets are not really pleasant for
math-work
[Just for context: A teacher may have more important things to teach than python
If the niggles get overbearing the vehicle may not be worth it
]
Besides I find the name pop ridiculous
Stacks imply a stronger order usage-discipline than lists
Sets are unordered compared to lists
To use a name traditionally reserved for a stack op on sets is quite nonsensical
--
https://mail.python.org/mailman/listinfo/python-list
Re: A question on modification of a list via a function invocation
On Tuesday, September 5, 2017 at 7:12:48 PM UTC+5:30, Rustom Mody wrote: > On Tuesday, September 5, 2017 at 6:42:07 PM UTC+5:30, Gregory Ewing wrote: > > Steve D'Aprano wrote: > > > The third entity is the reference linking the name to the object (the > > > arrow). > > > This isn't a runtime value in Python, nor is it a compile time entity that > > > exists in source code. It is pure implementation, and as such, exists > > > outside > > > of the Python domain. > > > > The fact that there is a connection between the name and the > > object is very much part of Python's abstract semantics. > > > > There are different ways to implement that connection, but > > *any* implementation of Python has to include *some* > > representation of it. > > > > There are also different words that can be used to describe > > it. You can say that names are bound to objects, or that > > names refer to objects, or that names hold references to > > objects. These are all equally good ways of talking about > > the exact same abstract concept. > > > > To me this argument about whether Python has references > > or not is like an American person saying that cars have > > hoods, and a British person saying he's wrong, hoods > > are an implementation detail and cars actually have > > bonnets instead. > > Also called playing humpty-dumpty > > I believe there is a germ of value behind all this empty polemics > There are 3 equivalence relations: > 1. == — mathematical, too coarse to understand nuances of python semantics > 2. is — machine representation, too fine to be useful > 3. graph (or topological) equality which experienced pythonistas have > internalized > in understanding when two data structures are same or different > [Roughly Anton's diagrams that are beyond my drawing capability!] > > > And yet pythonistas need that to understand python data structures > > >>> a = [1,2] > >>> b = [a,a] > >>> c = [[1,2],[1,2]] > >>> b == c > True > >>> b is c > False > >>> p = [1,2] > >>> q = [p,p] > >>> r = [[1,2],[1,2]] > >>> q == r > True > >>> q is r > False > >>> b == q > True > >>> b == r > True > >>> b is q > False > >>> b is r > False To make it more clear Suppose ≡ is graph-equal. The pythonista understands that b ≢ c ## ≡ is finer than == Whereas b ≡ r ie ≡ is coarser than is Its another matter that the name 'is' makes these discussions much harder in python than in equivalent languages like java, lisp, javascript etc by making the mostly unnecessary and irrelevant "is machine-rep same" sound the same(!) as "is conceptually same" -- https://mail.python.org/mailman/listinfo/python-list
Re: Please improve these comprehensions (was meaning of [ ])
On Tuesday, September 5, 2017 at 7:32:52 PM UTC+5:30, Chris Angelico wrote: > On Tue, Sep 5, 2017 at 11:49 PM, Rustom Mody wrote: > > Pop et al wont work with frozen sets > > Containment wont work with sets — what mathematicians call 'not closed' > > All of which amounts to this that python sets are not really pleasant for > > math-work > > Funnily enough, Python has never boasted that it's great for > mathematicians. True that > Time and time again I see posts here that try to > explain Python from the POV of pure mathematics, and they always seem > to end up getting convoluted and awkward. Unrelated that. Look at all the fundamental operations here https://docs.python.org/3.6/library/operator.html What percentage of these are unrelated to math? And how do you write even the simplest assignment statement without a (mathematical) expression on the rhs? And a look at history: What *were* Turing, Church, von Neumann, even Knuth by training? Mathematicians or CS-ists? And what *are* the contributions of Turing, Church, von Neumann, Knuth to CS? -- https://mail.python.org/mailman/listinfo/python-list
Re: Python console's workspace path
On Tuesday, September 5, 2017 at 7:58:23 PM UTC+5:30, Andrej Viktorovich wrote:
> Hello,
>
> I run Python 3.6 console under windows 10. Where is default console directory?
>
> I run script:
> >>> tf = open ("aaa.txt", "w")
> >>> tf.write(" %s" % 123)
> >>> tf.close()
>
> Where file aaa.txt will be created? Can I change default work space location?
> How?
>>> from os import getcwd
>>> getcwd()
You'll see where/what python takes as cwd (current working directory)
There are other things on windows like rt-click the python executable icon
on your desktop and adjust the "open in..." to whatever you want
But I dont know too much about this to say 😊
--
https://mail.python.org/mailman/listinfo/python-list
Re: Run python module from console
On Tuesday, September 5, 2017 at 8:45:00 PM UTC+5:30, Andrej Viktorovich wrote: > Hello, > > I suppose I can run python module by passing module as param for executable: > > python.exe myscr.py > > But how to run script when I'm inside of console and have python prompt: > > >>> >> import myscr # Note no .py extension -- https://mail.python.org/mailman/listinfo/python-list
Re: Run python module from console
On Tuesday, September 5, 2017 at 8:45:00 PM UTC+5:30, Andrej Viktorovich wrote: > Hello, > > I suppose I can run python module by passing module as param for executable: > > python.exe myscr.py > > But how to run script when I'm inside of console and have python prompt: > > >>> By and large not straightforwardly possible At python prompt you call *functions* At OS prompt you call apps/programs/scripts including python *scripts* They are different with different calling conventions However if you look up on the __name__ == '__main__' trick you can find ways of getting both function call and script call behavior https://stackoverflow.com/questions/419163/what-does-if-name-main-do -- https://mail.python.org/mailman/listinfo/python-list
Re: A question on modification of a list via a function invocation
On Tuesday, September 5, 2017 at 10:45:45 PM UTC+5:30, Ned Batchelder wrote: > On 9/5/17 1:02 PM, Steve D'Aprano wrote: > > On Tue, 5 Sep 2017 11:37 pm, Gregory Ewing wrote: > > > >> Dennis Lee Bieber wrote: > >>> Pascal, probably Modula-2, Visual BASIC are closer to the C++ reference > >>> semantics, in that the definition of a function declares how the > >>> argument(s) are passed. > >> Well, sort of. In Pascal and Modula, and also VB I think, > >> parameters are the only things that can be declared as having > >> reference semantics, whereas references in C++ are first-class > >> things that can be stored in any variable. > > No, they aren't first-class. > > Did you mis-read Gregory's claim? He said, "references *in C++* are > first-class things". You seem to be talking below about Python things. I think its mostly true of C++ And Steven did say: (I don't know enough about C++ to distinguish between the last two opinions, but I'm strongly leaning towards "not values at all".) So he seems to be talking of C++ (as analogous to python??) But I dont see that any of it is relevant Whether references are - first-class (Algol-68, pointers-in-C) or are simply - second class (C++) - invisible (python, lisp, ruby, javascript) has little to do with what we are talking The question is whether we need the *idea* of references (modulo humpty-dumpty-fication) to talk *about* the language; ie it needs to be there in the human/informal ontology, even if the docs play word-games and try to avoid trigger-words in honour of PC. In my view its almost the defining quality of imperative languages that the semantics of the language is not properly/fully comprehensive without (something like) references. [Replace "imperative language" with "assignment and mutation" if you like] -- https://mail.python.org/mailman/listinfo/python-list
Re: A question on modification of a list via a function invocation
On Wednesday, September 6, 2017 at 3:34:41 AM UTC+5:30, Marko Rauhamaa wrote: > Chris Angelico : > > > That shows that the Java '==' operator is like the Python 'is' > > operator, and checks for object identity. You haven't manipulated > > pointers at all. In contrast, here's a C program that actually > > MANIPULATES pointers: > > > > [...] > > > > You can't do this with Python, since pointer arithmetic fundamentally > > doesn't exist. You can in C. Can you in Java? > > You can't do it in Pascal, either, but Pascal definitely has pointers. > > Pointer arithmetics is not an essential part of C. One could argue that > it was a mistake to include it in the language. This is subjective of course… but still I wonder where you are coming from… You of course know that writing Unix was the genesis and raison d'être for C right? And what is an OS but a thin layer of abstraction on top of bare ISP? ie is not a Linux-OS just an x86 hw + some new ‘instructions’ called system-calls? Which is to say IMHO being able to punch holes into the hi-level-language abstraction seems to be a sine qua non for being suitable as a language for writing OSes. Do you think its reasonable/feasible to do that without easy access to all the machine resources eg memory, IO, interrupts etc accessible in the OS-writing language? [BTW I think Microsoft has done a better job than classic C of repeating this with C# — C# is almost as high-level as python, lisp etc and as low (or lower) than C; ie it is effectively two languages, called ‘safe’ and ‘unsafe’ parts ] -- https://mail.python.org/mailman/listinfo/python-list
Re: Please improve these comprehensions (was meaning of [ ])
On Wednesday, September 6, 2017 at 6:27:24 AM UTC+5:30, Steve D'Aprano wrote: > On Wed, 6 Sep 2017 12:19 am, Rustom Mody wrote: > > > And how do you write even the simplest assignment statement without a > > (mathematical) expression on the rhs? > > name = other_name > > is not a mathematical expression. Its giving something a new name. > > name = obj.attribute > > is not a mathematical expression. (That's not a dot product.) > Ok you win (that) [And I see your stocks of straw are overflowing. Wholesale prices?] > > > > What were Turing, Church, von Neumann, even Knuth by training? > > Mathematicians > > or CS-ists? > > > > And what are the contributions of Turing, Church, von Neumann, Knuth to CS? > > Who cares? We're talking about Python, not Computer Science. He who forgets history is doomed to repeat it. Start with your own statement: “Lisp is a functional language” And see the history a little bit more http://blog.languager.org/2015/04/cs-history-1.html 1960 : McCarthy got the idea of functional programming from an earlier invention of a certain Backus called 'The Formula Translator' which would later shorten to ForTran 1980s: The functional programming community was decrying lisp: "Success of lisp set back the development of functional programming by 10 years" And most significant: “McCarthy did not consider Lisp to be a functional language” Of course nothing to be surprised here: You know more java than old java-heads And more lisp than John McCarthy 😉 -- https://mail.python.org/mailman/listinfo/python-list
Re: Please improve these comprehensions (was meaning of [ ])
On Wednesday, September 6, 2017 at 6:58:29 AM UTC+5:30, Rustom Mody wrote: > On Wednesday, September 6, 2017 at 6:27:24 AM UTC+5:30, Steve D'Aprano wrote: > > On Wed, 6 Sep 2017 12:19 am, Rustom Mody wrote: > > > What were Turing, Church, von Neumann, even Knuth by training? > > > Mathematicians > > > or CS-ists? > > > > > > And what are the contributions of Turing, Church, von Neumann, Knuth to > > > CS? > > > > Who cares? We're talking about Python, not Computer Science. > Of course nothing to be surprised here: You know more java than old java-heads > And more lisp than John McCarthy 😉 Also noteworthy here: You know more about list comprehensions than their inventor — Greg Ewing [No I normally would not call Greg their inventor but in this case following through your logic that python exists in a historical, contextual vacuum] -- https://mail.python.org/mailman/listinfo/python-list
Re: A question on modification of a list via a function invocation
On Wednesday, September 6, 2017 at 9:22:15 AM UTC+5:30, Chris Angelico wrote: > On Wed, Sep 6, 2017 at 1:42 PM, Stefan Ram wrote: > > Steve D'Aprano writes: > >>So in what sense are references part of the Python language? > > > > It would be possible to describe Python using a concept > > called "reference", it's just that the The Python Language > > Reference, Release 3.6.0 (PRL) does /not/ do this. > > And programming language experts usually use the terms that > > the language specification uses with the meaning that the > > language specification is giving them. And this is why I say > > that JavaScript and Python do not have references. > > (Except "attribute references".) > > > >>Inside the interpreter, you (probably?) could print out the value of the > >>pointer, or manipulate it in some fashion. > > > > Well, this /is/ from the PRL: > > > > »An object's identity never changes once it has been created; > > you may think of it as the object's address in memory.«. > > ¯¯ > > - The Python Language Reference, Release 3.6.0; > > 3.1 Objects, values and types > > > > It's not called "reference", it's called "identity". But it > > might agree with your idea of a pointer of an implementation. > > And you /can/ print it. > > > print( id( 'abc' )) > > 4163144 > > Printing out an address is only half the point (pun intended) of a > pointer - and the useless half. Given a pointer, you need to be able > to dereference it. How can you, given the id of a Python object, > access the object itself? The nearest I've ever seen is a function > that searches every object it can find, looking for one with the same > id. Well ⅓ the point of pointers may be printing them out — which even in a language with 1st class pointers like C is rarely done/needed Another ⅓ is dereferencing, pointer-arithmetic etc... the various manifestations of 1st-class pointers And the third ⅓ is to provide explanations to people asking authentic questions [like the OP of this thread] Sure you can say with Steven that this can be 'explained' by saying an object can be in two places at one time. Others would then say 'Humpty-dumpty!' since you have removed the most basic intuition of objects and you are in effect saying that a python object means what you ordain it means without further ado/explanation Since you believe a reference-less dictionary can be a model for such explanations, why not provide that? -- https://mail.python.org/mailman/listinfo/python-list
Re: A question on modification of a list via a function invocation
On Wednesday, September 6, 2017 at 9:55:10 AM UTC+5:30, Chris Angelico wrote: > On Wed, Sep 6, 2017 at 2:17 PM, Rustom Mody wrote: > > Well ⅓ the point of pointers may be printing them out — which even in a > > language > > with 1st class pointers like C is rarely done/needed > > But still the useless part. You don't actually *achieve* anything by > printing out the pointer. > > > Another ⅓ is dereferencing, pointer-arithmetic etc... the various > > manifestations > > of 1st-class pointers > > This is the part that matters. > > > And the third ⅓ is to provide explanations to people asking authentic > > questions > > [like the OP of this thread] > > Only questions that actually relate to one of the previous parts. [dangling pointer ?¿?¿ ] > > > Sure you can say with Steven that this can be 'explained' by saying an > > object > > can be in two places at one time. > > Others would then say 'Humpty-dumpty!' since you have removed the most basic > > intuition of objects and you are in effect saying that a python object > > means what you ordain it means without further ado/explanation > > > > Since you believe a reference-less dictionary can be a model for such > > explanations, > > why not provide that? > > A piece of paper works just fine. However, it's hard to use that > method of explanation in an email. I am ready to bet that if ASCII is insufficient then you are drawing pictures You can call them whatever you like - pointers, references - data structure diagrams - graphs vertices, edges - I think I'll call them Antoon-art in honor of Antoon Pardon who has the patience to draw them I believe it was Marko Rauhamaa who have another half dozen metaphors: - doggies and pussies er.. sorry leashes Whatever you use, you will have to reify in your explanation the idea of pointer/graph-edge/etc even and especially because, the language disallows such a reification -- https://mail.python.org/mailman/listinfo/python-list
Re: A question on modification of a list via a function invocation
On Wednesday, September 6, 2017 at 12:51:25 PM UTC+5:30, Gregory Ewing wrote: > Rustom Mody wrote: > > 2. is — machine representation, too fine to be useful > > Disagree - "is" in Python has an abstract definition that > doesn't depend on machine representation. > > -- > Greg There is this (AFAIAC sophistry) in the docs describing the data model https://docs.python.org/3/reference/datamodel.html | Every object has an identity, a type and a value. An object’s identity never | changes once it has been created; you may think of it as the object’s address | in memory. The ‘is’ operator compares the identity of two objects; the id() | function returns an integer representing its identity. | CPython implementation detail: For CPython, id(x) is the memory address where | x is stored. Can you explain what "id" and "is" without talking of memory? In fact we have got so used to the term 'memory' that it actually seems strange when someone like Dijkstra grumbles at the anthropomorphism and asks why its not called 'store'. -- https://mail.python.org/mailman/listinfo/python-list
Re: Please improve these comprehensions (was meaning of [ ])
On Wednesday, September 6, 2017 at 4:29:56 PM UTC+5:30, Gregory Ewing wrote: > Seems to me you're making life difficult for yourself (and > very inefficient) by insisting on doing the whole computation > with sets. If you want a set as a result, it's easy enough > to construct one from the list at the end. Sure with programmer hat firmly on that is the sensible view. But there are equally legitimate other hats to consider: Learning combinatorics for example. And from that point of view Python (or Haskell or whatever) should be mostly irrelevant. Whereas what should be relevant is what SICP calls ‘procedural epistemology’: https://mitpress.mit.edu/sicp/front/node3.html | Underlying our approach to this subject is our conviction that "computer | science" is not a science and that its significance has little to do with | computers. The computer revolution is a revolution in the way we think and in | the way we express what we think. The essence of this change is the emergence | of what might best be called procedural epistemology the study of the | structure of knowledge from an imperative point of view, as opposed to the | more declarative point of view taken by classical mathematical subjects. | Mathematics provides a framework for dealing precisely with notions of "what | is." Computation provides a framework for dealing precisely with notions of | "how to." Coming to the details in this case, the important difference between permutations and combinations is not the numbers nPr and nCr but that a permutation is a list and a combination is a set. So this definition of permutations is fine (almost): def perms(l): if not l: return [[]] x, xs = l[0], l[1:] return [p[:i] + [x] + p[i:] for p in perms(xs) for i in range(0,len(l))] >>> perms([1,2,3]) [[1, 2, 3], [2, 1, 3], [2, 3, 1], [1, 3, 2], [3, 1, 2], [3, 2, 1]] Because the abstract idea of a permutation is a list (sequence) And the implementation here is faithful to that [The outer being a list is a mild annoyance... We can let it pass] However in this: def c(n,r): if r == 0: return [[]] elif len(n) == 0: return [] else: return [[n[0]] + l for l in c(n[1:],r-1)] + c(n[1:],r) the [n[0]] + l is misguidingly overspecific, ie it suggests an order which has no relevance or connection to the problem. Note that *as a programmer* this may be fine From the pov of studying math, its wrong Now if you want to agree with Chris in saying that python is unsuitable for doing math, that's fine. [I am tending to agree myself] I posted it because I genuinely thought I had missed some obvious way of splitting a set into an (arbitrary) element and a rest without jumping through hoops. Evidently not -- https://mail.python.org/mailman/listinfo/python-list
Re: A question on modification of a list via a function invocation
On Wednesday, September 6, 2017 at 5:08:20 PM UTC+5:30, Steve D'Aprano wrote: > On Wed, 6 Sep 2017 07:13 pm, Rustom Mody wrote: > > > > Can you explain what "id" and "is" without talking of memory? > > Yes. > > id() returns an abstract ID number which is guaranteed to be an integer, and > guaranteed to be distinct for all objects which exist at the same time. When > an > object ceases to exist, its ID number may be re-used. > > `is` compares the two operands for identity. If the two operands are the same > object, `is` returns True, if they are distinct objects, `is` returns False. >>> a = (1,2) >>> b = (1,2) >>> a is b False >>> x = 1 >>> y = 1 >>> x is y True a seems to be as 'same' to b as x is to y Python seems to think otherwise Evidently your ‘same’ is not the same as mine?? > > > In fact we have got so used to the term 'memory' that it actually seems > > strange when someone like Dijkstra grumbles at the anthropomorphism and asks > > why its not called 'store'. > > And if it were called "store" (grocery store? shoe store? clothes store?) > Dijkstra would have grumbled at the metaphor and asked why it wasn't > called "memory". Memory is an old (middle-English) word. Until say 1945 it could be used in sentences like the following “I have memories of walking in the woods with my dad” “Where are the eggs?” “Oops! Totally slipped my memory… Sorry" “The Dalai Lama has memories of his past lives” Are you using ‘memory’ in this kind of way? -- https://mail.python.org/mailman/listinfo/python-list
Re: A question on modification of a list via a function invocation
On Wednesday, September 6, 2017 at 4:03:40 PM UTC+5:30, ROGER GRAYDON CHRISTMAN
wrote:
> On 5 Sep 2017 14:28:44, (Dennis Lee Bier) wrote:
> > On 5 Sep 2017 17:57:18 GMT,
> >> But what does "a C++ reference" refer to?
> >>
>
> > Per Stroustrup (The C++ Programming Language 4th Ed, page 189)
>
> > """
> > * ...> * A reference always refers to the object to which it was
> > initialized.
> > * ...
>
> > A reference is an alternative name for an object, an alias. ...
> > """
>
> > {Hmmm, and I see that the syntax can be used outside of parameter
> > declaration -- which is the only place I'd seen it previously... either
> > this is a change from earlier standards, or my classes just didn't feel the
> > need to expose a non-parameter reference -- since, based upon the above
> > book, you can not declare a bare reference "variable"; it MUST be
> > initialized with a real object.}
>
> I think I can say something about this, having been a teacherof the classes
> you refer to. I intentionally avoided reference variables.
> IMO, the 'good' use for declaring a new reference variable (i.e. not
> parameter)would be when (1) the object to which you refer to is
> time-consuming to access(2) you plan to refer to this object more then once,
> and don't want to repeatthat time-consuming process, and (3) you really want
> a reference, and not a copy.
> The first two years of programming courses really do not have a purposethat
> meets all three, so can "didn't feel the need" is probably applicable.
> I intentionally avoided them because reference variables simply compoundthe
> problem of aliasing, so unless you really limit your reference variableto a
> very tight sandbox, you could be causing more headache than you save.
> I do admit to occasionally defining a method that returned a reference,such
> as one that overloads the [] operator. But even so, I would generallybe
> reluctant to giving an outside client a direct access to my
> database'sinternal structures. (Thank you Python for separating __getitem__
> and __setitem__)
> Python doesn't eliminate aliasing, of course, since most assignment
> operationscreate aliases. But at least it's nice to know that aliasing
> immutable valuesis harmless. Hence my unit on building recursive data
> structures entirelyout of tuples.
The realization that immutability is a significant virtue is now beginning
to percolate mainstream programming
Ive seen it in recent C# books as a definite recommendation… Something like
- Use value types
- Use getters but no setters
And you have a good design
Python makes this hard by giving less status to immutable types than mutable
ones
- set comprehensions exist not frozenset comprehensions
- Likewise tuples and lists
--
https://mail.python.org/mailman/listinfo/python-list
Re: A question on modification of a list via a function invocation
On Wednesday, September 6, 2017 at 5:48:48 PM UTC+5:30, Chris Angelico wrote: > On Wed, Sep 6, 2017 at 10:11 PM, Rustom Mody wrote: > > On Wednesday, September 6, 2017 at 5:08:20 PM UTC+5:30, Steve D'Aprano > > wrote: > >> On Wed, 6 Sep 2017 07:13 pm, Rustom Mody wrote: > >> > >> > >> > Can you explain what "id" and "is" without talking of memory? > >> > >> Yes. > >> > >> id() returns an abstract ID number which is guaranteed to be an integer, > >> and > >> guaranteed to be distinct for all objects which exist at the same time. > >> When an > >> object ceases to exist, its ID number may be re-used. > >> > >> `is` compares the two operands for identity. If the two operands are the > >> same > >> object, `is` returns True, if they are distinct objects, `is` returns > >> False. > > > >>>> a = (1,2) > >>>> b = (1,2) > >>>> a is b > > False > >>>> x = 1 > >>>> y = 1 > >>>> x is y > > True > > > > a seems to be as 'same' to b as x is to y > > Python seems to think otherwise > > > > Evidently your ‘same’ is not the same as mine?? > > *facepalm* > > I got nothing to say to you. Have you been on this list all this time > and still don't understand that Python sometimes optimizes immutables? Losing 'memory' of context Chris? Let me erm… remind: I said 'is' refers to "same in machine representation" Greg disagreed: « "is" in Python has an abstract definition that doesn't depend on machine representation.» I said: In that case please restate the definition of 'is' from the manual which invokes the notion of 'memory' without bringing in memory. Steven gave his explanation by dropping 'memory' and gave a definition Which I showed does not match expected common sense Sure you can bring in the notion (now!) of optimization if you like But you cant have it both ways - 'is' is a fundamental conceptual notion of sameness - 'is' is a machine/implementation specific notion of sameness which changes depending on machine/implementation specific decisions Of course you can have a third hand… Its usually called sophistry The trouble with sophistrizing is that you get caught in your own net: You (and Steven) claim that references (and aliases such as pointers) can be expunged from the language semantics. If you do that the term 'memory' remains standalone without any semantics. And when you make a bogus expulsion of that as well, extant behavior becomes unexplainable… Except with a… (which I share) *facepalm* -- https://mail.python.org/mailman/listinfo/python-list
Re: Please improve these comprehensions (was meaning of [ ])
On Wednesday, September 6, 2017 at 5:59:17 PM UTC+5:30, nopsidy wrote:
> https://www.youtube.com/watch?v=pNe1wWeaHOU&list=PLYI8318YYdkCsZ7dsYV01n6TZhXA6Wf9i&index=1
> Thank you,
> -Alex Goretoy
> http://launchpad.net/~a1g
You (Alex) are top-posting. I am not fussy. But others here can be
In any case thanks for quoting Stefan's post which I would not see otherwise
>
>
> On Wed, Sep 6, 2017 at 7:22 PM, Stefan Ram wrote:
> > Rustom Mody writes:
> >>Because the abstract idea of a permutation is a list (sequence)
> >
> > Traditional mathematical books (which are not influenced by
> > computer programming terminology) often use "n-tuple"
> > (or "sequence") instead of "list" IIRC.
> >
> > It is important to note that - according to me - a Python
> > data structure with the same /name/ as a mathematical concept
> > does not always have to be the best way to implement that
> > mathematical concept. E.g., sometimes a Python list might be
> > the best way to implement a mathematical tuple, or a Python
> > tuple may be the best way to implement a mathematical set.
I came to the conclusion and said more or less what you are saying Stefan…
when programmer hat is on. viz that the simplest solution (all lists) is
probably the way to go.
I've taught this (with the simple list-solution) many times over decade(s)
Then this time I thought: "Hey! Python now has sets. And even set-
comprehensions! Maybe the solution could be more sparkling clean if I switch
from lists to sets?"
However every effort of mine was clumsy and unsatisfactory.
So thought of asking if I am missing something… Evidently not
- the set data type does not nest — {1,2} possible {{1,2},{3,4}} not
- the frozenset datatype is (pragmatically) incomplete — no clean way to
separate an element from a (frozen)set
So all in all too many hoops to jump through
[Greg talked of efficiency — not my primary concern (here)]
PS As said I do not see your posts (Stefan) unless someone quotes them
--
https://mail.python.org/mailman/listinfo/python-list
Re: Why do we nned both - __init__() and __new__()
On Thursday, September 7, 2017 at 4:27:48 PM UTC+5:30, Andrej Viktorovich wrote:
> Hello
>
> For my understanding both - __init__() and __new__() works like constructors.
> And __new__() looks is closer to constructor. __init__() is more for variable
> initialization. Why I can't just initialize in __init__() ?
>
> class ExampleClass(object):
> def __new__(cls,value):
> print("creating new instance with val %s" % (value,) )
> instance = super(ExampleClass,cls).__new__(cls)
> return instance
> def __init__(self, value):
> print("Initialising instance... with val %s" % (value,))
> self.payload = value
>
> exampleInstance = ExampleClass(42)
> print(exampleInstance.payload)
If you are not sure, forget about __new__
__init__ is the one you need mostly
[Ive never used new (in Python); C++ is a different case altogether]
See
https://mail.python.org/pipermail/tutor/2008-April/061424.html
and further thread
--
https://mail.python.org/mailman/listinfo/python-list
Re: A question on modification of a list via a function invocation
On 06/09/17 14:02, Stefan Ram wrote: > Chris Angelico writes: >> The 'is' operator tests if two things are the same thing. > >»Roughly speaking, to say of two things that they are >identical is nonsense, and to say of one thing that it >is identical with itself is to say nothing at all.« > > Ludwig Wittgenstein, Tractatus Logico-Philosophicus (5.5303) Someone who is philosophically literate in technical forum: a rare treat! Nice!! Wittgenstein is a favorite of mine and I often reserve one lecture for his: “Limits of my language are the limits of my world” Then amplified by Roman Jacobson’s “Languages differ not in what we can say but what we must say” And finally with Whorf's evidence that words can set buildings on fire https://web.stanford.edu/dept/SUL/library/extra4/sloan/mousesite/Secondary/Whorfframe2.html [Today it would be send countries to war] However Wittgenstein's quote above on identity is too terse to properly grasp the real difficulty https://plato.stanford.edu/entries/identity/ shows at some (verbose!) length that identity is and can only be a hopelessly circular definition. A problem which has little to do with python, programming languages, or CS in general; it is a fundamental universal problem -- https://mail.python.org/mailman/listinfo/python-list
Re: A question on modification of a list via a function invocation
On Thursday, September 7, 2017 at 6:52:04 PM UTC+5:30, Gregory Ewing wrote: > Rustom Mody wrote: > > > I said: In that case please restate the definition of 'is' from the manual > > which > > invokes the notion of 'memory' without bringing in memory. > > I don't know whether it's in the manual, but at least for > mutable objects, there is a way to define the notion of > "same object" that doesn't require talking about "memory": > > Two names refer to the same object if and only if mutations > made through one are visible through the other. Seems a sensible comment! [Aside from the fact that 'visible' is likely ill or circularly defined — my other comment to Stefan. But lets just ignore that for now and assume that 'visible' has no grey/dispute areas] > > Python has definite rules concerning when mutable objects > will be the same or not, and every correct implementation > must conform to them. In that sense it's a fundamental > concept that doesn't depend on implementation. I'd like to know what these rules are > > There is more leeway when it comes to immutable objects; > implementations are free to cache and re-use them, so > well-written code avoids depending on the result of > "is" for immutable objects. Which sounds like saying that 'isness' of immutables is ill/un-defined Not that I object if this is said My objection is to the claim that the isness of python's is and the isness of 'conceptually-same' are the same. I believe that your definition of same and the one I earlier gave are similar (same?? Not sure) Repeating here for ease: (with some clarifications) We say equivalence relation R is coarser than S is xSy ⇒ xRy So x is y ⇒ x == y but not (necessarily) vice versa However there are not 2 but 3 equivalence relations: 1. == — mathematical, too coarse to understand nuances of python semantics 2. is — machine representation, too fine to be useful 3. graph (or topological) equality which experienced pythonistas have internalized in understanding when two data structures are same or different [Roughly Anton's diagrams that are beyond my drawing capability!] And yet pythonistas need 3 to understand python data structures ie 3 captures pythonistas intuition of same better than 1 or 2 >>> a = [1,2] >>> b = [a,a] >>> c = [[1,2],[1,2]] >>> b == c True >>> b is c False >>> p = [1,2] >>> q = [p,p] >>> r = [[1,2],[1,2]] >>> q == r True >>> q is r False >>> b == q True >>> b == r True >>> b is q False >>> b is r False Now the pythonista understands that b and c may be math-= but have different structure Whereas b is graph-equal to q And c is graph-equal to r However there is no available operation to show/see that distinction The trouble is that graph-isomorphism is NP-complete so the crucial operation cannot be reasonably implemented To make it more clear ≡ is graph-equal, ie 2. The pythonista understands that b ≢ c ## ≡ is finer than == Whereas b ≡ r ie ≡ is coarser than is And b and r are python-equivalent without any memory relation in the sense that no sequence of valid operations applied to b and to r will tell them apart — sometimes called 'trace-equivalence' -- https://mail.python.org/mailman/listinfo/python-list
Re: A question on modification of a list via a function invocation
On Friday, September 8, 2017 at 7:39:38 AM UTC+5:30, Steve D'Aprano wrote: > On Fri, 8 Sep 2017 04:24 am, Rustom Mody wrote: > > > On Thursday, September 7, 2017 at 6:52:04 PM UTC+5:30, Gregory Ewing wrote: > >> Rustom Mody wrote: > >> > >> > I said: In that case please restate the definition of 'is' from the > >> > manual > >> > which invokes the notion of 'memory' without bringing in memory. > >> > >> I don't know whether it's in the manual, but at least for > >> mutable objects, there is a way to define the notion of > >> "same object" that doesn't require talking about "memory": > >> > >> Two names refer to the same object if and only if mutations > >> made through one are visible through the other. > > > > Seems a sensible comment! > > > Except that it is wrong, or at least over-generalised. It is trivially easy to > show false positives: > > py> class K: # defines an object > ... def __init__(self, x): > ... self.x = x > ... def append(self, value): > ... self.x.append(value) > ... > py> a = [] > py> b = K(a) > py> a is b # these are not the same object (they're different types) > False > py> b.append(99) # but modifying b modifies a > py> a > [99] > > > Rustom, I've already given you the definitive answer to your question about > how > to define `is` without talking about memory. You haven't replied or > acknowledged it, so here is it again: > > `is` compares the two operands for identity. Preamble… so far so good > If the two operands are the same > object, `is` returns True, if they are distinct objects, `is` returns False. restated a is b iff a is b A more than usually egregious demo of the circularity of defining isness/sameness Models are needed Math is one possible model Machines are another Paper and pen — which Chris keeps referring to — is another Remove all models and you have frank hopeless circularity > > > This does require that we agree on "same object", which as you point out is > (in > its full generality) a difficult thing to define. More than difficult, impossible in the fully abstract philosophical case When concretized to specific models not necessarily the fundamental circularity then pushed out to the model 1 + 2 = 3 Are these '3's on your and my screen same? Same font? Same time? E.g. in the past I've raised > the paradox of My Grandfather's Axe. Dont see the relevance (here) > > But the intuitive, common-sense notion of "same object" is, I think, > sufficient > here. If you want to argue that it is *not* sufficient, I think it's up to you > to demonstrate a problem with the definition. > Its not that you cant raise philosophical problems if you want But when concretized to (basic) math, there are no disputes so the argument becomes obtuseness to no point In the case of python data model every single interminable thread like this one, obviously started by a noob asking something genuinely and indicating a real confusion disproves your claim to obvious intuition and common sense Just to reiterate: Someone asked a question Its not clear what (s)he understood from what we have going on and on about for 100s of posts > Can you show an actual false positive (two distinct objects for which `is` > returns True) or false negative (the same object given as both operands for > `is` nevertheless returns False)? In the absence of any actual bugs in the > definition, I maintain that it is sufficient. You are not paying attention — the example above I gave in which python arbitrarily hi-handedly, inconsistently manifests different behavior between integer 1 and tuple (1,2) I am now dropping off this thread [more important things to do] with this observation: There are these strange wondrous things in the world called 'mothers' They take bawling shiing peeing pieces of fleshy exasperation called 'babies' And convert them into intelligent human beings Dunno how they do it… More easily: if I, knowing English, read a German-English dictionary its ok, a well-founded action — learning unknown-German via known-English But reading a 'normal' English-English dictionary like Webster, Oxford etc is borderline infinite recursion… And occasionally fails — ambiguities, grey areas Still it mostly works… with enough good faith However bootstrapping the whole process from absolute zero — the mothers' task — is frankly beyond my ken Bare (pure-philosophical, model-less) identity/sameness is analogous So… what you think is obvious and trivially intuitive — the bald fact of semantics and comprehension — is to me quite miraculous -- https://mail.python.org/mailman/listinfo/python-list
Re: The Incredible Growth of Python (stackoverflow.blog)
On Sunday, September 10, 2017 at 7:12:10 AM UTC+5:30, Gregory Ewing wrote: > Pavol Lisy wrote: > > Interesting reading: > > https://stackoverflow.blog/2017/09/06/incredible-growth-python/?cb=1 > > So, Python's rate of expansion is accelerating, like > the universe. Does that mean there's some kind of dark > energy fuelling its growth? Something to do with the small Hamming-distance between "God" and "Guido" ? -- https://mail.python.org/mailman/listinfo/python-list
Re: The Incredible Growth of Python (stackoverflow.blog)
On Sunday, September 10, 2017 at 3:15:32 PM UTC+5:30, Skip Montanaro wrote: > > * asyncio with its a-dialect > > What is a/the "a-dialect"? > > S I'd guess its the async/await (semi)keyworded python Compre with the (IMHO) better suggestion for codef/cocall https://lists.gt.net/python/dev/1197316?do=post_view_threaded -- https://mail.python.org/mailman/listinfo/python-list
Re: Python in Perspective
On Monday, September 11, 2017 at 3:08:51 AM UTC+5:30, bream...@gmail.com wrote: > On Sunday, September 10, 2017 at 11:21:26 AM UTC+1, Leam Hall wrote: > > y'all, > > > > My god-kids and their proginators lost most everything because of > > Harvey. I spent much of yesterday worrying about a friend who had gone > > quiet as he evacuated his family ahead of Irma. > > > > Please keep Python in perspective. Whether we use 1.5 or 4rc1 is a lot > > less critical than using Python to work together well and solving big > > problems as friends. > > > > In years gone by I spent time on the soapbox but never came away cleaner > > or with stronger friendships. I just ranted and spent years wondering > > why nothing actually changed. Please don't make my mistake; come up with > > your own. > > > > Together. As friends. > > > > Leam > > What do you have to say about the people who die every year in the monsoon, > as they are dying right now, as opposed to the occasional hurricane that hits > the richest nation in the world? Will Trump the Chump cure all the worlds > ills, or is he too busy looking after his highly paid mates in the oil and > gas industries, who are actively paying for the education system in some US > states to the detriment of facts, as in there is no man made global warming? Dont know whether to laugh or to weep http://time.com/4935117/hurricane-irma-guns-florida/ -- https://mail.python.org/mailman/listinfo/python-list
Re: The Incredible Growth of Python (stackoverflow.blog)
On Monday, September 11, 2017 at 12:51:59 PM UTC+5:30, Gregory Ewing wrote: > Chris Angelico wrote: > > Async functions in > > JS are an alternative to callback hell; most people consider async > > functions in Python to be an alternative to synchronous functions. > > What do you base that on? Seems to me async is an alternative > to callback-based frameworks such as Twisted. > > Calling async functions an alternative to sync functions > doesn't make sense, because if sync functions will do what > you want, there's no need to use async ones. The choice usually is: sync-functions-in-threads with lock-race-hell vs callback-hell -- https://mail.python.org/mailman/listinfo/python-list
Re: The Incredible Growth of Python (stackoverflow.blog)
On Monday, September 11, 2017 at 1:28:24 PM UTC+5:30, Marko Rauhamaa wrote: > Gregory Ewing: > > > Chris Angelico wrote: > >> Async functions in > >> JS are an alternative to callback hell; most people consider async > >> functions in Python to be an alternative to synchronous functions. > > > > What do you base that on? Seems to me async is an alternative > > to callback-based frameworks such as Twisted. > > > > Calling async functions an alternative to sync functions > > doesn't make sense, because if sync functions will do what > > you want, there's no need to use async ones. > > Asyncio makes it possible to write a single-threaded program in > multithreading style. > > The multithreading style means entwining the state of a finite state > machine in the form of the source code. While a callback-based program > will use one or more variables (object attributes) to store the state -- > or leave it implicit -- an asyncio program marks each state with the > "await" keyword. > > The multithreading style is convenient in cases where each state is > blocked on a single possible event. Trouble is, most state machines I > run into (and that's my bread and butter), each state is blocked on > several or even numerous alternative events. Do you have some reading material suggestions for grokking the a-world? -- https://mail.python.org/mailman/listinfo/python-list
Re: String to Dictionary conversion in python
On Saturday, September 16, 2017 at 2:04:39 AM UTC+5:30, jlad...@itu.edu wrote:
> On Thursday, September 14, 2017 at 11:33:56 PM UTC-7, Ian wrote:
> > On Fri, Sep 15, 2017 at 12:01 AM, wrote:
> > > Hi,
> > >
> > > Can anyone help me in the below issue.
> > >
> > > I need to convert string to dictionary
> > >
> > > string = " 'msisdn': '7382432382', 'action': 'select', 'sessionId':
> > > '123', 'recipient': '7382432382', 'language': 'english'"
> > >
> > > Can anyone help me with the code
> >
> > It looks like this might do what you need:
> >
> > py> import ast
> > py> string = " 'msisdn': '7382432382', 'action': 'select',
> > 'sessionId': '123', 'recipient': '7382432382', 'language': 'english'"
> > py> ast.literal_eval('{%s}' % string)
> > {'sessionId': '123', 'recipient': '7382432382', 'msisdn':
> > '7382432382', 'action': 'select', 'language': 'english'}
>
> Very clever!
Yeah… I used to think thus
But literal_eval has excessive crud in its error messages:
>>> from ast import literal_eval
>>> literal_eval("{'x':1}")
{'x': 1}
Ok…
>>> literal_eval("{x:1}")
Traceback (most recent call last):
File "", line 1, in
File "/usr/lib/python2.7/ast.py", line 80, in literal_eval
return _convert(node_or_string)
File "/usr/lib/python2.7/ast.py", line 63, in _convert
in zip(node.keys, node.values))
File "/usr/lib/python2.7/ast.py", line 62, in
return dict((_convert(k), _convert(v)) for k, v
File "/usr/lib/python2.7/ast.py", line 79, in _convert
raise ValueError('malformed string')
ValueError: malformed string
>>> literal_eval("'x':1")
Traceback (most recent call last):
File "", line 1, in
File "/usr/lib/python2.7/ast.py", line 49, in literal_eval
node_or_string = parse(node_or_string, mode='eval')
File "/usr/lib/python2.7/ast.py", line 37, in parse
return compile(source, filename, mode, PyCF_ONLY_AST)
File "", line 1
'x':1
^
SyntaxError: invalid syntax
> And definitely not an answer that would be acceptable for a homework
> assignment.
😇
--
https://mail.python.org/mailman/listinfo/python-list
Re: [Tutor] beginning to code
On Monday, September 18, 2017 at 5:23:49 PM UTC+5:30, Rick Johnson wrote:
> On Sunday, September 17, 2017 at 8:51:38 PM UTC-5, INADA Naoki wrote:
> > >
> > > >
> > > > I would agree that testing any of those for '== True' or
> > > > the like is pointless redundancy,
> > >
> > > But what's wrong with syntactical redundancy when it brings
> > > _clarity_ to the source code? And why can't Python be smart?
> > > Consider the collowing code:
> > >
> > > if bool(someObject) == True:
> > > # Do something
> > >
> > > Yes, from a "byte-code perspective", this source code is
> > > superfluous, but, from a source code perspective, this code
> > > is perfectly balanced between explicit and implicit.
> >
> > I can't agree with you. It's too redundant. It doesn't
> > provide any information about what coder think.
>
> It's not about what the "coder thinks", many times what the
> coder thinks is wrong, it's about writing code that is
> intuitive to as wide an audience as possible.
>
> > While PEP 8 recommends `if x:`, I accept `if x > 0` or `if
> > len(x) > 0` when I review code in my company.
>
> So when `x` is an iterable, as in:
>
> if len(x) > 0:
> # blah
>
> You're okay with the explicit test. Or when `x` is a
> numeric, as in:
>
> if x > 0:
> # blah
>
> You're okay with the explicit test. So, from a standpoint of
> consistency, you /should/ be okay with this:
>
> if bool(x) == True:
> # blah
>
> But you're not! :-).
I have a feeling Rick that you are mixing up two unrelated things:
- the bool(x) part
- the ... == True part
The operation
x == True
for true(!)/proper booleans x is a no-op
because True == True is True
and False == True is False
And there are no other (proper) booleans
However because anything else can be bool-ish even though not boolean
you need the bool(x) to effect the mapping:
{None, 0, "" {}, []} → False
Everything_else → True
This mapping is neither obvious nor trivial
And one could argue that leaving python to implicitly make [] (say) into False
should be documented
So if you drop the hangup with the red-herring ...==True
you have a point in asking for the bool(...)
--
https://mail.python.org/mailman/listinfo/python-list
Re: [Tutor] beginning to code
On Monday, September 18, 2017 at 6:25:09 PM UTC+5:30, Rustom Mody wrote:
> On Monday, September 18, 2017 at 5:23:49 PM UTC+5:30, Rick Johnson wrote:
> > On Sunday, September 17, 2017 at 8:51:38 PM UTC-5, INADA Naoki wrote:
> > > >
> > > > >
> > > > > I would agree that testing any of those for '== True' or
> > > > > the like is pointless redundancy,
> > > >
> > > > But what's wrong with syntactical redundancy when it brings
> > > > _clarity_ to the source code? And why can't Python be smart?
> > > > Consider the collowing code:
> > > >
> > > > if bool(someObject) == True:
> > > > # Do something
> > > >
> > > > Yes, from a "byte-code perspective", this source code is
> > > > superfluous, but, from a source code perspective, this code
> > > > is perfectly balanced between explicit and implicit.
> > >
> > > I can't agree with you. It's too redundant. It doesn't
> > > provide any information about what coder think.
> >
> > It's not about what the "coder thinks", many times what the
> > coder thinks is wrong, it's about writing code that is
> > intuitive to as wide an audience as possible.
> >
> > > While PEP 8 recommends `if x:`, I accept `if x > 0` or `if
> > > len(x) > 0` when I review code in my company.
> >
> > So when `x` is an iterable, as in:
> >
> > if len(x) > 0:
> > # blah
> >
> > You're okay with the explicit test. Or when `x` is a
> > numeric, as in:
> >
> > if x > 0:
> > # blah
> >
> > You're okay with the explicit test. So, from a standpoint of
> > consistency, you /should/ be okay with this:
> >
> > if bool(x) == True:
> > # blah
> >
> > But you're not! :-).
>
> I have a feeling Rick that you are mixing up two unrelated things:
> - the bool(x) part
> - the ... == True part
>
> The operation
> x == True
> for true(!)/proper booleans x is a no-op
> because True == True is True
> and False == True is False
> And there are no other (proper) booleans
>
> However because anything else can be bool-ish even though not boolean
> you need the bool(x) to effect the mapping:
>
> {None, 0, "" {}, []} → False
> Everything_else → True
>
> This mapping is neither obvious nor trivial
Sufficiently non-obvious that I missed the key element:
{None, 0, "" {}, [], False} → False
--
https://mail.python.org/mailman/listinfo/python-list
Re: [Tutor] beginning to code
On Tuesday, September 19, 2017 at 4:41:01 PM UTC+5:30, Antoon Pardon wrote:
> Op 19-09-17 om 11:22 schreef Steven D'Aprano:
> > Except for bools, where people freak out and are convinced the world will
> > end if you just ask an object "are you true or false?".
> >
> > Perhaps just a *tiny* exaggeration *wink*
>
> On the other hand, python is very eager to convert objects to a bool. For
> strings and iterators you are expected to write a dunder method. If you
> think it makes no sense to see specific instances as true or false, you
> have to explicitly write a __bool__ that raises an exception. I think
> it would have been a better choice that a TypeError would have been
> raised if __bool__ wasn't defined.
How exceptional is python's choice to NOT raise exceptions can be seen by
examples:
>>> [] + 2
Traceback (most recent call last):
File "", line 1, in
TypeError: can only concatenate list (not "int") to list
>>> [] < 0
Traceback (most recent call last):
File "", line 1, in
TypeError: unorderable types: list() < int()
>>> 1[2]
Traceback (most recent call last):
File "", line 1, in
TypeError: 'int' object is not subscriptable
>>> 2 < []
Traceback (most recent call last):
File "", line 1, in
TypeError: unorderable types: int() < list()
>>> len(2)
Traceback (most recent call last):
File "", line 1, in
TypeError: object of type 'int' has no len()
>>> [x for x in 1]
Traceback (most recent call last):
File "", line 1, in
TypeError: 'int' object is not iterable
>>> -[]
Traceback (most recent call last):
File "", line 1, in
TypeError: bad operand type for unary -: 'list'
>>> [] or []
[]
# Ah well... Same category as...
>>> ("empty" if [] else "nonempty")
'nonempty'
>>>
--
https://mail.python.org/mailman/listinfo/python-list
grapheme cluster library
Is there a recommended library for manipulating grapheme clusters? In particular, in devanagari क् + ि = कि in (pseudo)unicode names KA-letter + I-sign = KI-composite-letter I would like to be able to handle KI as a letter rather than two code-points. Can of course write an automaton to group but guessing that its already available some place… -- https://mail.python.org/mailman/listinfo/python-list
Re: grapheme cluster library
On Saturday, October 21, 2017 at 11:51:57 AM UTC+5:30, Chris Angelico wrote: > On Sat, Oct 21, 2017 at 3:25 PM, Stefan Ram wrote: > > Rustom Mody writes: > >>Is there a recommended library for manipulating grapheme clusters? > > > > The Python Library has a module "unicodedata", with functions like: > > > > |unicodedata.normalize( form, unistr ) > > | > > |Returns the normal form »form« for the Unicode string »unistr«. > > |Valid values for »form« are »NFC«, »NFKC«, »NFD«, and »NFKD«. > > > > . I don't know whether the transformation you are looking for > > is one of those. > > No, that's at a lower level than grapheme clusters. > > Rustom, have you looked on PyPI? There are a couple of hits, including > one simply called "grapheme". There is this one line solution using regex (or 2 char solution!) Not perfect but a good start >>> from regex import findall >>> veda="""ॐ पूर्णमदः पूर्णमिदं पूर्णात्पुर्णमुदच्यते पूर्णस्य पूर्णमादाय पूर्णमेवावशिष्यते ॥ ॐ शान्तिः शान्तिः शान्तिः ॥""" >>> findall(r'\X', veda) ['ॐ', ' ', 'पू', 'र्', 'ण', 'म', 'दः', ' ', 'पू', 'र्', 'ण', 'मि', 'दं', ' ', 'पू', 'र्', 'णा', 'त्', 'पु', 'र्', 'ण', 'मु', 'द', 'च्', 'य', 'ते', '\n', 'पू', 'र्', 'ण', 'स्', 'य', ' ', 'पू', 'र्', 'ण', 'मा', 'दा', 'य', ' ', 'पू', 'र्', 'ण', 'मे', 'वा', 'व', 'शि', 'ष्', 'य', 'ते', ' ', '॥', '\n', 'ॐ', ' ', 'शा', 'न्', 'तिः', ' ', 'शा', 'न्', 'तिः', ' ', 'शा', 'न्', 'तिः', ' ', '॥'] >>> Compare >>> [x for x in veda] ['ॐ', ' ', 'प', 'ू', 'र', '्', 'ण', 'म', 'द', 'ः', ' ', 'प', 'ू', 'र', '्', 'ण', 'म', 'ि', 'द', 'ं', ' ', 'प', 'ू', 'र', '्', 'ण', 'ा', 'त', '्', 'प', 'ु', 'र', '्', 'ण', 'म', 'ु', 'द', 'च', '्', 'य', 'त', 'े', '\n', 'प', 'ू', 'र', '्', 'ण', 'स', '्', 'य', ' ', 'प', 'ू', 'र', '्', 'ण', 'म', 'ा', 'द', 'ा', 'य', ' ', 'प', 'ू', 'र', '्', 'ण', 'म', 'े', 'व', 'ा', 'व', 'श', 'ि', 'ष', '्', 'य', 'त', 'े', ' ', '॥', '\n', 'ॐ', ' ', 'श', 'ा', 'न', '्', 'त', 'ि', 'ः', ' ', 'श', 'ा', 'न', '्', 'त', 'ि', 'ः', ' ', 'श', 'ा', 'न', '्', 'त', 'ि', 'ः', ' ', '॥'] What is not working are the vowel-less consonant-joins: ie ... 'र्', 'ण' ... [3,4 element of the findall] should be one 'र्ण' But its good enough for me for now I think PS Stefan I dont see your responses unless someone quotes them. Thanks anyway for the inputs -- https://mail.python.org/mailman/listinfo/python-list
Re: grapheme cluster library
On Saturday, October 21, 2017 at 9:22:24 PM UTC+5:30, MRAB wrote:
> On 2017-10-21 05:11, Rustom Mody wrote:
> > Is there a recommended library for manipulating grapheme clusters?
> >
> > In particular, in devanagari
> > क् + ि = कि
> > in (pseudo)unicode names
> > KA-letter + I-sign = KI-composite-letter
> >
> > I would like to be able to handle KI as a letter rather than two
> > code-points.
> > Can of course write an automaton to group but guessing that its already
> > available some place…
> >
> You can use the regex module to split a string into graphemes:
>
> regex.findall(r'\X', string)
Thanks MRAB
Yes as I said I discovered r'\X'
Ultimately my code was (effectively) one line!
print("".join(map[x] for x in findall(r'\X', l)))
with map being a few 100 elements of a dictionary such as
map = {
...
'ॐ': "OM",
...
}
$ cat purnam-deva
ॐ पूर्णमदः पूर्णमिदं पूर्णात्पुर्णमुदच्यते
पूर्णस्य पूर्णमादाय पूर्णमेवावशिष्यते ॥
$ ./devanagari2roman.py purnam-deva
OM pUraNamadaH pUraNamidaM pUraNAtpuraNamudachyate
pUraNasya pUraNamAdAya pUraNamavAvashiShyate ..
OM shAntiH shAntiH shAntiH ..
Basically, an inversion of the itrans input method
https://en.wikipedia.org/wiki/ITRANS
--
https://mail.python.org/mailman/listinfo/python-list
Re: grapheme cluster library (Posting On Python-List Prohibited)
On Monday, October 23, 2017 at 8:06:03 AM UTC+5:30, Lawrence D’Oliveiro wrote: > On Saturday, October 21, 2017 at 5:11:13 PM UTC+13, Rustom Mody wrote: > > Is there a recommended library for manipulating grapheme clusters? > > Is this <http://anoopkunchukuttan.github.io/indic_nlp_library/> any good? Thanks looks promising. Dunno how much it lives up to the claims [For now the one liner from regex's findall has sufficed: findall(r'\X', «text») [Thanks MRAB for the library] > Bear in mind that the logical representation of the text is as code points, > graphemes would have more to do with rendering. Heh! Speak of Euro/Anglo-centrism! In a sane world graphemes would be called letters And unicode codepoints would be called something else — letterlets?? To be fair to the Unicode consortium, they strive hard to call them codepoints But in an anglo-centric world, the conflation of codepoint to letter is inevitable I guess. To hear how a non Roman-centric view of the world would sound: A 'w' is a poorly double-struck 'u' A 't' is a crossed 'l' Reasonable? The lead of https://en.wikipedia.org/wiki/%C3%9C has | Ü, or ü, is a character…classified as a separate letter in several extended Latin alphabets | (including Azeri, Estonian, Hungarian and Turkish), but as the letter U with an | umlaut/diaeresis in others such as Catalan, French, Galician, German, Occitan and Spanish. -- https://mail.python.org/mailman/listinfo/python-list
Re: grapheme cluster library
On Monday, October 23, 2017 at 1:15:35 PM UTC+5:30, Steve D'Aprano wrote:
> On Mon, 23 Oct 2017 05:47 pm, Rustom Mody wrote:
>
> > On Monday, October 23, 2017 at 8:06:03 AM UTC+5:30, Lawrence D’Oliveiro
> > wrote:
> [...]
> >> Bear in mind that the logical representation of the text is as code points,
> >> graphemes would have more to do with rendering.
> >
> > Heh! Speak of Euro/Anglo-centrism!
>
> I think that Lawrence may be thinking of glyphs. Glyphs are the display form
> that are rendered. Graphemes are the smallest unit of written language.
>
>
> > In a sane world graphemes would be called letters
>
> Graphemes *aren't* letters.
>
> For starters, not all written languages have an alphabet. No alphabet, no
> letters. Even in languages with an alphabet, not all graphemes are letters.
>
> Graphemes include:
>
> - logograms (symbols which represent a morpheme, an entire word, or
> a phrase), e.g. Chinese characters, ampersand &, the ™ trademark
> or ® registered trademark symbols;
>
> - syllabic characters such as Japanese kana or Cherokee;
>
> - letters of alphabets;
>
> - letters with added diacritics;
>
> - punctuation marks;
>
> - mathematical symbols;
>
> - typographical symbols;
>
> - word separators;
>
> and more. Many linguists also include digraphs (pairs of letters) like the
> English "th", "sh", "qu", or "gh" as graphemes.
>
>
> https://www.thoughtco.com/what-is-a-grapheme-1690916
>
> https://en.wikipedia.org/wiki/Grapheme
Um… Ok So I am using the wrong word? Your first link says:
| For example, the word 'ghost' contains five letters and four graphemes
| ('gh,' 'o,' 's,' and 't')
Whereas new regex findall does:
>>> findall(r'\X', "ghost")
['g', 'h', 'o', 's', 't']
>>> findall(r'\X', "church")
['c', 'h', 'u', 'r', 'c', 'h']
--
https://mail.python.org/mailman/listinfo/python-list
Re: Let's talk about debuggers!
On Wednesday, October 25, 2017 at 6:37:47 PM UTC+5:30, Thomas Jollans wrote: > Hi, > > I just wanted to know what tools everyone used for debugging Python > applications - scripts / backend / desktop apps / notebooks / whatever. > Apart from the usual dance with log files and strategically inserted > print() calls, that is. > > Of course we all know and mildly dislike pdb. > > Personally, in practice, I'm most likely to need a debugger when > prototyping a function in a Jupyter notebook. There, ipdb, summoned with > the %%debug magic incantation, does the trick. > > Sometimes, though, I miss having a visual debugger. You know, the kind > that Visual Basic has had for decades. There's one in Chrome dev tools > if you ever have the misfortune of writing JavaScript. > > What options are there for Python (that work)? What text editors (and > IDEs) have a decent integrated debugger or debugging plugin? (Is there > anything for Sublime?) Does anyone use them? (How do YOU debug?) > > I vaguely remember WinPDB, but that hasn't seen a release in more than > seven years... pdb inside emacs works (to a fashion) And it shows the arrow for current line so its at least quasi-gui I believe idle too is much more usable than a few years earlier -- https://mail.python.org/mailman/listinfo/python-list
Re: Ide vs ide
On Saturday, October 28, 2017 at 11:59:14 AM UTC+5:30, Andrew Z wrote: > Yeah, lets start the war! > // joking! > > But if i think about it... there are tons articles and flame wars about "a > vs b". > And yet, what if the question should be different: > > If you were to create the "ide" for yourself (think lego) , what are the > functions that you _use_ and like a lot? [Not really an answer to your question…] But in a related direction: I think we need to talk more systematically about - programming-in-the-small: [< 70 lines — one or so screenfuls; only 1 file] - -in-the-medium : all files in one directory - -in-the-large : multiple directories/languages/OSes etc - -huge : millions of lines; thousands of man-years I think one of the main attractions (to me but also generally to teachers) is that languages like python make programming-in-the-tiny a realistic possibility ie a couple of lines worked out possibly file-less, at the interpreter prompt. [The other day I was writing a program to split alternate lines of a file; Apart from file-handling it was these two lines: for x in lines[0::2]: print(x.strip()) for x in lines[1::2]: print(x.strip()) ] So coming to your question: IDEs are good for medium and (diminishingly) for large programs. Useful python programs are often small; even tiny -- https://mail.python.org/mailman/listinfo/python-list
Re: Ide vs ide
On Saturday, October 28, 2017 at 4:46:03 PM UTC+5:30, Christian Gollwitzer
wrote:
> Am 28.10.17 um 09:04 schrieb Rustom Mody:
> > [The other day I was writing a program to split alternate lines of a file;
> > Apart from file-handling it was these two lines:
> >
> > for x in lines[0::2]: print(x.strip())
> > for x in lines[1::2]: print(x.strip())
> > ]
>
> ...and using the best(TM) tool for it, it is a one-liner:
>
> gawk '{ print > "split" NR%2}' input.txt
Ooo!¡!
--
https://mail.python.org/mailman/listinfo/python-list
Re: Invoking return through a function?
On Sunday, October 29, 2017 at 9:52:01 PM UTC+5:30, Rick Johnson wrote: > On Sunday, October 29, 2017 at 9:19:03 AM UTC-5, Alberto Riva wrote: > > In a language like Lisp > > Python is nothing like Lisp, and for good reason! Sure, we > have a few lispers and functional fanboys who hang around > here, and sometimes Rustom can get a little preachy about > FP, but mostly, we tolerate the fanboyism -- so long as it's > not rabid fanboyism. Rick's personal comments are one of the standard entertainments of this list. Enjoy! The comments on FP are more problematic: - These misconceptions are more widespread than just Rick - They are right enough to be hard to refute - And wrong enough to cause confusion and misdirection - And irrelevant to (threads like) this one My super-short rejoiner to the FP-irrelevancy is: «If there is one key takeaway from functional programming maybe it should be: "Truth is a function of time" » In more detail: - Lisp (1960) was the second functional language; its predecessor was something called Formula Translator — usually shortened to Fortran (c. 1957) - By the late 80s, many FPers had begun regard Lisp as a setback for functional programming. [Dont get me wrong: Ive enjoyed Scheme more than any other programming language. Its just that conflating Lisp and FP is an error (in 2017)] More historical details at http://blog.languager.org/2015/04/cs-history-1.html and sequel At a more conceptual level, people dont get that there are two dimensions - the apply-lambda axis — usually called functional programming - the eval-quote axis — which has precious little to do with FP (and is more relevant to your question) These two dimensions of power uniquely coincide in Lisp (Scheme). As you correctly (almost) point out - Python is very much a lisp… its semantic under-belly - However, syntactically its more like C/Java etc in the sense of having a rigid fixed-at-language-design-time syntax More at http://blog.languager.org/2013/08/applying-si-on-sicp.html For a question like macros (syntax-extensions) that sits between the two your question is interesting and I am not sure I know how to do it… I remember seeing something about this recently but my google-foo is failing me at the moment However I would look at - PEP 263 https://www.python.org/dev/peps/pep-0263/ — Source Code Encodings… - Hooking into the codec module https://docs.python.org/3/library/codecs.html - hooking into ast module https://docs.python.org/3/library/ast.html An old attempt in this direction: http://code.activestate.com/recipes/546539/ You've already got the moral-hi-horse guys giving you the dope of why this is evil. Swallow if you like. My own lightweight suggestion would be that the natural pythonic way of unstructured exit is exceptions. Not as succinct as a tailormade syntax extension. But good enough IMHO PS I personally would be interested if you get this (syntax extension) running -- https://mail.python.org/mailman/listinfo/python-list
Re: pythonw.exe error
On Monday, October 30, 2017 at 10:11:49 PM UTC+5:30, Igor Korot wrote: > Hi, > > > > On Oct 30, 2017 11:27 AM, "George Kalamaras via Python-list" wrote: > > When I am running IDLE return to me Missing python36.dll error > > Στάλθηκε από την Αλληλογραφία για Windows 10 > > > Could you please translate this from Greek? Google translate tells me this is "Sent from mail for Windows 10" IOW its probably a mail auto-footer of the OP, not the error message -- https://mail.python.org/mailman/listinfo/python-list
Re: Invoking return through a function?
On Tuesday, October 31, 2017 at 7:45:18 AM UTC+5:30, Alberto Riva wrote: > On 10/30/2017 12:23 AM, Rustom Mody wrote: > > On Sunday, October 29, 2017 at 9:52:01 PM UTC+5:30, Rick Johnson wrote: > >> On Sunday, October 29, 2017 at 9:19:03 AM UTC-5, Alberto Riva wrote: > > > >>> In a language like Lisp > >> > >> Python is nothing like Lisp, and for good reason! Sure, we > >> have a few lispers and functional fanboys who hang around > >> here, and sometimes Rustom can get a little preachy about > >> FP, but mostly, we tolerate the fanboyism -- so long as it's > >> not rabid fanboyism. > > > > Rick's personal comments are one of the standard entertainments of this > > list. Enjoy! > > > > The comments on FP are more problematic: > > > > - These misconceptions are more widespread than just Rick > > - They are right enough to be hard to refute > > - And wrong enough to cause confusion and misdirection > > - And irrelevant to (threads like) this one > > > > My super-short rejoiner to the FP-irrelevancy is: > > «If there is one key takeaway from functional programming maybe it should > > be: "Truth is a function of time" » > > > > In more detail: > > - Lisp (1960) was the second functional language; its predecessor was > > something called Formula Translator — usually shortened to Fortran (c. 1957) > > - By the late 80s, many FPers had begun regard Lisp as a setback for > > functional programming. [Dont get me wrong: Ive enjoyed Scheme more than > > any other > > programming language. Its just that conflating Lisp and FP is an error (in > > 2017)] > > > > More historical details at > > http://blog.languager.org/2015/04/cs-history-1.html and sequel > > > > At a more conceptual level, people dont get that there are two dimensions > > - the apply-lambda axis — usually called functional programming > > - the eval-quote axis — which has precious little to do with FP (and is > > more relevant to your question) > > > > These two dimensions of power uniquely coincide in Lisp (Scheme). > > > > As you correctly (almost) point out > > - Python is very much a lisp… its semantic under-belly > > - However, syntactically its more like C/Java etc in the sense of having a > > rigid > > fixed-at-language-design-time syntax > > > > More at http://blog.languager.org/2013/08/applying-si-on-sicp.html > > > > For a question like macros (syntax-extensions) that sits between the two > > your > > question is interesting and I am not sure I know how to do it… > > I remember seeing something about this recently but my google-foo is > > failing me > > at the moment > > > > However I would look at > > - PEP 263 https://www.python.org/dev/peps/pep-0263/ — Source Code Encodings… > > - Hooking into the codec module > > https://docs.python.org/3/library/codecs.html > > - hooking into ast module https://docs.python.org/3/library/ast.html > > > > An old attempt in this direction: > > http://code.activestate.com/recipes/546539/ > > > > You've already got the moral-hi-horse guys giving you the dope of why this > > is evil. Swallow if you like. My own lightweight > > suggestion would be that the natural pythonic way of unstructured exit is > > exceptions. Not as succinct as a tailormade syntax extension. But good > > enough IMHO > > > > PS I personally would be interested if you get this (syntax extension) > > running > > Thanks for the interesting reply! But once again: I was not proposing to > add lisp-style macros to Python; I have no interest in doing that since > I believe it's pretty much impossible :) https://github.com/pythonql/pythonql is the example that shows how lisp-style extended-syntax (macros) can be done via file-encodings in a modern python. Or if you prefer modern lingo: “How to embed an internal DSL into python” Note: I am not recommending you take this line; just that its not impossible as you seem to imagine. My own feeling about lisp-macros is conflicted: - They are likely the most unique feature of lisp, putting it at the top of the blub-language tower - They are the single reason Lisp can never succeed like mainstream languages: Any significant Lisp sub-ecosystem will inevitably develop a macro set which succinctly and precisely expresses its needs but is arcane and incomprehensible to someone from another sub-ecosystem. This is Turing-completeness Lisp-specific style: The basic Turing-result is that programs can be arbitrarily complex to the point of being unanalysable. For mainstream languages that complexity sits squarely in the application For lisp there is a choice of simplifying the application by concentrating the complexity in a macro/DSL layer between implementation and application -- https://mail.python.org/mailman/listinfo/python-list
Re: Invoking return through a function?
On Tuesday, October 31, 2017 at 11:05:30 AM UTC+5:30, Steve D'Aprano wrote: > On Tue, 31 Oct 2017 02:26 pm, Rustom Mody wrote: > > > My own feeling about lisp-macros is conflicted: > > - They are likely the most unique feature of lisp, putting it at the top of > > the blub-language tower > > - They are the single reason Lisp can never succeed like mainstream > > languages: Any significant Lisp sub-ecosystem will inevitably develop a > > macro set which succinctly and precisely expresses its needs but is arcane > > and incomprehensible to someone from another sub-ecosystem. > > Well said. That's one of the disadvantages of Forth as well: since Forth > allows you to define your own control-structures, even the structure of the > code can be unfamiliar. > > Another way to put it might be that any sufficiently complex Lisp program > doesn't look like Lisp any more. It seems we agree on the facts but not the accounting Facts: A fixed syntax language (C, Java, Python etc) is likely to have similar looking programs across a wide spectrum of applications as compared to a syntax-definable-at-runtime language like Lisp Accounting: You seem to count this as advantage to fixed-syntax? Note that if you carry this principle all the way, any application whatever running on an x86 will be running x86 instructions; which look more uniform than the diverse hl-languages that produced them. > > Except perhaps for the myriad parentheses *wink* Not so: reader-macros can change lisp all the way to the lexical level And used to do things like html-templating, sql-embedding etc -- https://mail.python.org/mailman/listinfo/python-list
Re: Thread safety issue (I think) with defaultdict
On Friday, November 3, 2017 at 6:28:28 AM UTC+5:30, Steve D'Aprano wrote: > On Fri, 3 Nov 2017 07:24 am, Chris Angelico wrote: > > > On Fri, Nov 3, 2017 at 3:27 AM, Israel Brewster wrote: > >> > >> Actually, that saying is about regular expressions, not threads :-) . In > >> the end, threads are as good a way as handling concurrency as any other, > >> and simpler than many. They have their drawbacks, of course, mainly in the > >> area of overhead, and of course only multiprocessing can *really* take > >> advantage of multiple cores/CPU's on a machine, but unlike regular > >> expressions, threads aren't ugly or complicated. Only the details of > >> dealing with concurrency make things complicated, and you'll have to deal > >> with that in *any* concurrency model. > >> > > > > Thank you. I've had this argument with many people, smart people (like > > Steven), people who haven't grokked that all concurrency has costs - > > Of course I grok that all concurrency has costs. Apart from comparatively rare > cases of "embarrassingly parallel" algorithms, any form of concurrent or > parallel processing is significantly harder than sequential code. > > > > that threads aren't magically more dangerous than other options. > > There's nothing magical about it. > > Threads are very much UNMAGICALLY more dangerous than other options because > they combine: > > - shared data; and > > - non-deterministic task switching. … which is to say «bad mix of imperative programming and concurrency» «The world is concurrent» [Joe Armstrong creator of Erlang] If you get up from your computer just now for a coffee, it does not mean I have to at the same time. More pertinently, it would be rather wasteful if the billion+ transistors of an i7 waited for each other rather than switching independently. The problem is that von Neumann preferred to simplify the programming task along the lines nowadays called "imperative programming"… after whom we get the terms "von Neumann model", "von Neumann machine" etc IOW threads are a particularly extreme example of the deleterious effects of stuffing the world into the mold of someone's (von Neumann's) brain. ie shared data + task switching = combinatorially explosive results Take your own statement «any form of concurrent or parallel processing is significantly harder than sequential code» and apply it to the abc of imperative programming: Problem: Interchange values of variables x and y Layman answer: x = y y = x [Ignore for a moment that python has an answer that is almost identical to the above and is correct: x,y = y,x] "Correct" answer: temp = x x = y y = temp Correct? Really??? Or is that being trained to "think like a programmer" means learning to convolute our brains into an arbitrary and unnecessary sequentiality? -- https://mail.python.org/mailman/listinfo/python-list
Re: Read Firefox sqlite files with Python
On Monday, November 6, 2017 at 8:42:29 AM UTC+5:30, Steve D'Aprano wrote:
> On Mon, 6 Nov 2017 12:39 am, Paul Moore wrote:
>
> > On 5 November 2017 at 01:22, Steve D'Aprano wrote:
> >> On Sun, 5 Nov 2017 04:32 am, Steve D'Aprano wrote:
> >>
> >>> I'm trying to dump a Firefox IndexDB sqlite file to text using Python 3.5.
> >>>
> >>>
> >>> import sqlite3
> >>> con = sqlite3.connect('foo.sqlite')
> >>> with open('dump.sql', 'w') as f:
> >>> for line in con.iterdump():
> >>> f.write(line + '\n')
> >>
> >>
> >> Never mind. I dumped the file using the sqlite3 command line tool. Thank
> >> you to all those who answered.
> >>
> >> The file contains three INSERT statements, the first two don't have
> >> anything of interest, and the third (which presumably contains all the data
> >> I'm trying to recover) is an opaque 600+ KB blob.
> >>
> >> Naturally. Why would you use a database as a database, when instead you
> >> could just dump a big ball of mud into it?
> >
> > Hmm, *.sql files normally contain SQL source code (as this one does).
>
> The .sql file is the result of running .dump from the sqlite command line
> tool. The original source database is 'foo.sqlite'. To be precise, it is the
> database used by the Firefox Add-On "One Tab".
>
> /home/steve/.mozilla/firefox/2z5po7dx.default/storage/permanent/indexeddb+++extension-at-one-tab-dot-com/idb/1832832054obnaet.sqlite
>
> One Tab provides an alternative bookmark-like function, allowing you to record
> URLs in groups for later use -- a bit like bookmarks. So I've been using this
> for some months, until the add-on stopped working. (Yet again an automatic
> update has screwed me and broken functionality.) So now I'm trying to
> retrieve the bookmarks.
[Not python-related and likely not an answer… Just what I would try]
1. Get hold of an old live ubuntu (say 12.4) ISO/flash/CD and boot
2. Mount /home
3. Make livecd~/.mozilla symlink to home/~steven/.mozilla
Do you see your bookmarks?
--
https://mail.python.org/mailman/listinfo/python-list
Re: How to Generate dynamic HTML Report using Python
On Tuesday, November 21, 2017 at 5:27:42 PM UTC+5:30, Ned Batchelder wrote: > On 11/20/17 9:50 AM, Stefan Ram wrote: > > Ned Batchelder writes: > >> Also, why set headers that prevent the Python-List mailing list from > >> archiving your messages? > >I am posting to a Usenet newsgroup. I am not aware of any > >"Python-List mailing list". > > > >I am posting specifically to the Usenet, because I am aware > >of it's rules and I like it and wish to support it. > > > >I do not post to a "mailing list" because I do not know which > >rules apply for mailing lists and whether mailing lists in > >general or any specific mailing list is an environment that I > >like or wish to support. > > > > The dual nature of this online community has long been confusing and > complicated. It's both a newsgroup and a mailing list. Add in Google > Groups, and you really have three different faces of the same content. > > The fact is, posting to comp.lang.python means that your words are also > being distributed as a mailing list. Because of your messages' headers, > they are not in the archive of that list > (https://mail.python.org/pipermail/python-list/2017-November/thread.html), > or in Google Groups > (https://groups.google.com/forum/#!topic/comp.lang.python/0ejrtZ6ET9g). > It makes for odd reading via those channels. > > I don't understand the motivation for limiting how words are > distributed, but others on this list also do it. For example, Dennis Lee > Bieber's messages are not in the Python-List archives either. If > something is worth saying, why not let people find it later? To which I would add: Setting headers is hardly a working method. Somebody quotes Stefan or Dennis and they are on the archives And some quote including emails some not etc -- https://mail.python.org/mailman/listinfo/python-list
Re: How to Generate dynamic HTML Report using Python
On Tuesday, November 21, 2017 at 7:06:18 PM UTC+5:30, Rustom Mody wrote: > On Tuesday, November 21, 2017 at 5:27:42 PM UTC+5:30, Ned Batchelder wrote: > > On 11/20/17 9:50 AM, Stefan Ram wrote: > > > Ned Batchelder writes: > > >> Also, why set headers that prevent the Python-List mailing list from > > >> archiving your messages? > > >I am posting to a Usenet newsgroup. I am not aware of any > > >"Python-List mailing list". > > > > > >I am posting specifically to the Usenet, because I am aware > > >of it's rules and I like it and wish to support it. > > > > > >I do not post to a "mailing list" because I do not know which > > >rules apply for mailing lists and whether mailing lists in > > >general or any specific mailing list is an environment that I > > >like or wish to support. > > > > > > > The dual nature of this online community has long been confusing and > > complicated. It's both a newsgroup and a mailing list. Add in Google > > Groups, and you really have three different faces of the same content. > > > > The fact is, posting to comp.lang.python means that your words are also > > being distributed as a mailing list. Because of your messages' headers, > > they are not in the archive of that list > > (https://mail.python.org/pipermail/python-list/2017-November/thread.html), > > or in Google Groups > > (https://groups.google.com/forum/#!topic/comp.lang.python/0ejrtZ6ET9g). > > It makes for odd reading via those channels. > > > > I don't understand the motivation for limiting how words are > > distributed, but others on this list also do it. For example, Dennis Lee > > Bieber's messages are not in the Python-List archives either. If > > something is worth saying, why not let people find it later? > > To which I would add: > Setting headers is hardly a working method. > Somebody quotes Stefan or Dennis and they are on the archives > And some quote including emails some not > etc O and one more thing: If Stefan or Dennis say something to the above dont expect a response from me since I would not have seen theirs 😉 -- https://mail.python.org/mailman/listinfo/python-list
Re: Benefits of unicode identifiers (was: Allow additional separator in identifiers)
On Friday, November 24, 2017 at 12:20:29 AM UTC+5:30, Mikhail V wrote: > Ok, I personally could find some practical usage for that, but > merely for fun. I doubt though that someone with less > typographical experience and overall computer literacy could > really make benefits even for personal usage. > > So - fun is one benefit. And fun is important. But is that the > idea behind it? Are you under-estimating the fun-value? Python 3.5.3 (default, Sep 14 2017, 22:58:41) [GCC 6.3.0 20170406] on linux Type "help", "copyright", "credits" or "license" for more information. >>> python.el: native completion setup loaded >>> A = 1 >>> Α = 2 >>> А = 3 >>> (A, Α, А) (1, 2, 3) >>> # And there are 5 other variations on this magic trick >>> # Or if you prefer… >>> A == Α False >>> Now compare with the boring spoilsport called python 2: Python 2.7.13 (default, Jan 19 2017, 14:48:08) [GCC 6.3.0 20170118] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> python.el: native completion setup loaded >>> A = 1 >>> Α = 2 File "", line 1 Α = 2 ^ SyntaxError: invalid syntax >>> Personally I feel that there should be a law against languages that disallow the creation of magic tricks!¡! -- https://mail.python.org/mailman/listinfo/python-list
Re: Benefits of unicode identifiers (was: Allow additional separator in identifiers)
On Saturday, November 25, 2017 at 6:03:52 PM UTC+5:30, Rustom Mody wrote: > On Friday, November 24, 2017 at 12:20:29 AM UTC+5:30, Mikhail V wrote: > > Ok, I personally could find some practical usage for that, but > > merely for fun. I doubt though that someone with less > > typographical experience and overall computer literacy could > > really make benefits even for personal usage. > > > > So - fun is one benefit. And fun is important. But is that the > > idea behind it? > > Are you under-estimating the fun-value? > > Python 3.5.3 (default, Sep 14 2017, 22:58:41) > [GCC 6.3.0 20170406] on linux > Type "help", "copyright", "credits" or "license" for more information. > >>> python.el: native completion setup loaded > >>> A = 1 > >>> Α = 2 > >>> А = 3 > >>> (A, Α, А) > (1, 2, 3) > >>> # And there are 5 other variations on this magic trick > >>> # Or if you prefer… > >>> A == Α > False > >>> > > Now compare with the boring spoilsport called python 2: > > Python 2.7.13 (default, Jan 19 2017, 14:48:08) > [GCC 6.3.0 20170118] on linux2 > Type "help", "copyright", "credits" or "license" for more information. > >>> python.el: native completion setup loaded > >>> A = 1 > >>> Α = 2 > File "", line 1 > Α = 2 > ^ > SyntaxError: invalid syntax > >>> > > Personally I feel that there should be a law against languages that disallow > the creation of magic tricks!¡! I should mention also that some languages are even more advanced in their jovialness regarding unicode tricks Haskell: GHCi, version 8.0.2: http://www.haskell.org/ghc/ :? for help Prelude> let flag = 1 Prelude> let flag = 2 Prelude> flag == flag False Prelude> (flag, flag) (2,1) Prelude> Python3 is quite boring by contrast: Python 3.5.3 (default, Sep 14 2017, 22:58:41) [GCC 6.3.0 20170406] on linux Type "help", "copyright", "credits" or "license" for more information. >>> python.el: native completion setup loaded >>> flag = 1 >>> flag = 2 >>> flag == flag True >>> (flag, flag) (2, 2) >>> -- https://mail.python.org/mailman/listinfo/python-list
Re: Pros and cons of Python sources?
On Saturday, November 25, 2017 at 9:45:07 PM UTC+5:30, Michael Torrie wrote: > On 11/25/2017 02:20 AM, Martin Schöön wrote: > > Some time ago I was advised that having a Python installation > > based on several sources (pip and Debian's repos in my case) > > is not a good idea. I need to tidy up my installation and I > > don't know what to opt for and what to opt out. > > > > What are the pros and cons of the alternatives including the > > ones I haven't mentioned? Completeness, currency, bugs... > > The problem with mixing repository-installed packages with pip-installed > packages is that there's always a chance a Debian update will overwrite > a pip package, possibly with an older version. Or a pip-installed > package might bring in a new version that's not compatible with some > debian-installed package, breaking something. On (recent?) debian/ubuntu pip seems to use the 'user-scheme' which means pip runs without sudo and installs in ~/.local/lib So I dont believe literal overwriting would occur What could occur is shadowing — two versions of package foo and an unclarity of which is in use… Alister's suggestion is what I always try first. Doesnt always work because OS packages could be stale and/or non-existent -- https://mail.python.org/mailman/listinfo/python-list
Re: Increasing the diversity of people who write Python (was: Benefits of unicode identifiers)
On Friday, November 24, 2017 at 10:52:47 PM UTC+5:30, Rick Johnson wrote: > Furthermore, if we are to march headlong onto the glorious > battlefields of diversity and equality… Obligatory viewing for those who underappreciate diversity, equality and such https://youtu.be/Zh3Yz3PiXZw [My old colleague, a numerical analyst pointed out to me today that the 'correct answer' is not twenty two thousand but twenty million two thousand] -- https://mail.python.org/mailman/listinfo/python-list
Re: Compile Python 3 interpreter to force 2-byte unicode
On Sunday, November 26, 2017 at 3:43:29 AM UTC+5:30, Chris Angelico wrote: > On Sun, Nov 26, 2017 at 9:05 AM, wojtek.mula wrote: > > Hi, my goal is to obtain an interpreter that internally > > uses UCS-2. Such a simple code should print 65535: > > > > import sys > > print sys.maxunicode > > > > This is enabled in Windows, but I want the same in Linux. > > What options have I pass to the configure script? > > Why do you want to? What useful value do you have in creating this > buggy interpreter? I see that you are familiar with this bug: https://bugs.python.org/issue13153 And I see it or something very close is still buggy in python 3.5 [No it does not allow me to paste an SMP char but if I open a file containing one it crashes and rather messily — no way to close the idle other than killing the shell] No thats not a diatribe against idle; just that its reasonable to want python to support work-arounds for reasonably common bugs in the current unicode-ecosystem -- https://mail.python.org/mailman/listinfo/python-list
Re: [META] Why are duplicate posts coming through?
On Monday, November 27, 2017 at 5:35:09 AM UTC+5:30, Skip Montanaro wrote: > Chris, > > Please forward one or two to me. Mark Sapiro and I have been banging on the > SpamBayes instance which supports the Usenet gateway. I suppose it's > possible some change caused the problem you're seeing. > > Skip > > On Nov 26, 2017 5:22 PM, "Chris Angelico" wrote: > > Not sure whether this is an issue for -owner or not; apologies if not. > > I'm seeing a whole lot of reasonably-recent posts getting re-sent, > with "nospam" attached to the posters' names. And they're getting > re-sent multiple times. Sometimes the posts have encoding problems > (small amounts of mojibake). > > What's going on? Is there something going haywire with the news/mail > gateway? Is there a rogue client re-posting a bunch of news? Somebody > testing something? And the spam continues unabated Except that the subject lines are changed -- https://mail.python.org/mailman/listinfo/python-list
Re: connect four (game)
On Monday, November 27, 2017 at 9:08:42 AM UTC+5:30, Chris Angelico wrote: > On Mon, Nov 27, 2017 at 1:55 PM, Michael Torrie wrote: > > On 11/26/2017 07:11 AM, bartc wrote: > >>> You may argue that testing doesn't matter for his small game, written > >>> for his own education and amusement. The fact is that software in > >>> general is of abysmal quality across the boards, and promoting a habit > >>> of unit testing is good, even for trivial, home-grown stuff. > >> > >> I thought people were being hard on the OP. > > > > I wasn't being hard on the OP. My observation is about the state of > > *all* software. My software especially, your software, Microsoft's > > software. It all is of rather poor quality compared to the rigors of > > other industries like civil engineering, manufacturing, etc. > > Not all software is poor quality compared to all examples of those > industries. You'll find the equivalent of software bugs in a lot of > hardware situations; the difference with software is that we have 100% > perfect reproduction in the end-user products, so we call it a design > flaw instead of a production artifact. (How often do you buy a box of > something and find that a couple of them just break?) Even in > large-scale civil engineering projects, there are plenty of > stupidities. The house I'm living in has a place where the tiled floor > doesn't quite align with the wall that it meets, and I can't figure > out why; somewhere, two things that ought to have been parallel just > aren't. Bridges have been known to crack, cars break down for no good > reason, your hamburger just doesn't taste right today. > > Aviators have pinned down the best solution to this, I think. A pilot > is not expected to be perfect; he is expected to follow checklists. A > preflight checklist. A departure checklist. A landing checklist. > Everything that needs to be done right is mentioned on the list, and > you just go through the list and make sure you've done everything. And thats where the analogy breaks down. Presumably a 50 person short-flight and a 600-person transcontinental may have at least something in common in their pilot-checklists What common will you find in a multi-million line OS, a thousand line script and a student prime-numbers first-program? No I am not dissing on testing and TDD; just that universality¹ of computing devices is something that our civilization is nowhere near understanding, leave alone dealing with — two programs can be more far apart than a bullock cart and a jet. And yet they are both programs ¹ Ive seen CS PhDs ask a student why a student didnt incorporate some error-checking into his compiler which amounted to solving the halting problem. More mundanely I see students have a hard time seeing their phones and their laptops as 'the same' -- https://mail.python.org/mailman/listinfo/python-list
Re: Benefits of unicode identifiers (was: Allow additional separator in identifiers)
On Monday, November 27, 2017 at 3:43:20 PM UTC+5:30, Antoon Pardon wrote: > Op 23-11-17 om 19:42 schreef Mikhail V: > > Chris A wrote: > > > >>> On Fri, Nov 24, 2017 at 1:10 AM, Mikhail V wrote: > >>> > Chris A wrote: > > Fortunately for the world, you're not the one who decided which > characters were permitted in Python identifiers. The ability to use > non-English words for function/variable names is of huge value; the > ability to use a hyphen is of some value, but not nearly as much. > >>> Fortunately for the world we have Chris A. Who knows what is > >>> fortunate and of huge values. > >>> So is there any real world projects example of usage of non-latin scripts > >>> in identifiers? Or is it still only a plan for the new world? > > > >> Yes, I've used them personally. And I know other people who have. > > > > Oh, I though it would be more impressive showcase for 'huge value'. > > If we drop the benefit of the bare fact that you can do it, or you just > > don't know English, how would describe the practical benefit? > > If you don't know english, then programming at all will be just too hard. > > (or one must define a new whole language specially for some local script) > > Well maybe the value is not huge, but I really appreciate the possibility. > Being able to write something like below, makes things a lot more clear > for me. > > Po = Pc + R * Vec(cos(θo), sin(θo)) > Pe = Pc + R * Vec(cos(θe), sin(θe)) > 𝚫θ = θe - θo > 𝚫P = Pe - Po Yeah… This is important And Ive tried to elaborate such suggestions here http://blog.languager.org/2014/04/unicoded-python.html [includes some of your suggestions!] I should emphasize that the details there range between straightforward and facetious. The general sense of going beyond ASCII is not facetious at all In fact its ridiculous in the reverse direction: just as FORTRAN and COBOL believed that programming IN ALL UPPERCASE was somehow kosher, likewise a 2017 language believing that sticking to ASCII is sound is faintly ridiculous. But that brings me to the opposite point: I feel its important to distinguish ‘parochial/sectarian unicode’ from ‘universal unicode’. More on the distinction http://blog.languager.org/2015/03/whimsical-unicode.html More on the universal aspect: http://blog.languager.org/2015/02/universal-unicode.html Having said that I should be honest to mention that I saw your post first on my phone where the θ showed but the 𝚫 showed as a rectangle something like ⌧ I suspect that Δ OTOH would have worked… dunno So yes, there can be non-trivial logistic problems going beyond ASCII As there are problems with errant mail-clients transmitting indentation-sensitive languages and so on! -- https://mail.python.org/mailman/listinfo/python-list
Re: connect four (game)
On Monday, November 27, 2017 at 12:12:24 PM UTC+5:30, Chris Angelico wrote: > On Mon, Nov 27, 2017 at 3:04 PM, Rustom Mody wrote: > >> Aviators have pinned down the best solution to this, I think. A pilot > >> is not expected to be perfect; he is expected to follow checklists. A > >> preflight checklist. A departure checklist. A landing checklist. > >> Everything that needs to be done right is mentioned on the list, and > >> you just go through the list and make sure you've done everything. > > > > And thats where the analogy breaks down. > > Presumably a 50 person short-flight and a 600-person transcontinental may > > have > > at least something in common in their pilot-checklists > > What common will you find in a multi-million line OS, a thousand line script > > and a student prime-numbers first-program? > > You locate a pure function. I can pretty much guarantee that the first > two will have a number of them, and the third one may or may not, but > almost certainly should. Pure functions are the easiest to unit-test. > Then you build up from there. > > > No I am not dissing on testing and TDD; just that universality¹ of > > computing devices > > is something that our civilization is nowhere near understanding, leave > > alone > > dealing with — two programs can be more far apart than a bullock cart and a > > jet. > > And yet they are both programs > > ... so? I know how to drive a car… and various two-wheelers. I not so sure of a bus/truck… I suppose I could get one from here to there at a pinch… without killing someone… though not quite sure of that! Doesn't translate into knowing how to 'drive' planes or bullock-carts gcc is tested with dejagnu. Do you imagine that knowing python's unittest or nose directly translates into dejagnu expertise? And even if we stay with industry-strength programs — gcc, linux-kernel, CPython, KDE — do you imagine that testing one helps in testing the other? I doubt it (though I am hardly an expert with testing frameworks) Once again let me end by saying that testing and TDD are good ideas And it would be nice if there was more of it in/for python [See http://osherove.com/tdd-kata-1/ one of the first hits that google gives (me) for TDD python, and you find the python example actually shows Ruby!] -- https://mail.python.org/mailman/listinfo/python-list
Re: Benefits of unicode identifiers (was: Allow additional separator in identifiers)
On Monday, November 27, 2017 at 6:48:56 PM UTC+5:30, Rustom Mody wrote: > Having said that I should be honest to mention that I saw your post first on > my phone where the θ showed but the 𝚫 showed as a rectangle something like ⌧ > > I suspect that Δ OTOH would have worked… dunno Yeah Δ shows whereas 𝚫 doesn't (on my phone) And ⌧ does show but much squatter than the replacement char the phone shows when it cant display a char -- https://mail.python.org/mailman/listinfo/python-list
Re: Increasing the diversity of people who write Python (was: Benefits of unicode identifiers)
On Friday, November 24, 2017 at 10:11:24 PM UTC+5:30, Skip Montanaro wrote:
> > Because if I already can't understand the words, it will be more useful
> > to me to be able to type them reliably at a keyboard, for replication,
> > search, discussion with others about the code, etc.
>
> I am probably not alone in my Americo-centric world where I can't even
> easily type accented Latin-1 characters. I happen to be using Linux as
> I type this, but type at a Windows keyboard at work (ugh) and have
> long been a user of Macs (still have one or two at home). Might the
> problem be further multiplied by the number of different ways I have
> of entering text? Would Emacs running on Linux, but displaying on
> Windows be different than Chrome running directly on Linux?
I strongly suspect that any recent emacs will have M-x insert-char
(earlier it was called ucs-insert) default bound C-x 8 RET (yeah thats clunky)
which will accept at the minibuffer input
At which point the hex for é which is e9 can be entered — yeah its unreasonable
to expect to remember that!
Its more reasonable to remember that that is an e acute;
And e itself is a latin lower case letter
All of which becomes entering (in the minibuffer)
LATIN SMALL LETTER E ACUTE
- upper case not required; emacs will upcase it for you
- And will also provide some tab/star expansion help
ie *letter e acuteTAB
expands to
LATIN *L LETTER E ACUTE
Further TAB-prodding will give you these choices
LATIN CAPITAL LETTER E ACUTE (É)LATIN CAPITAL LETTER E WITH ACUTE (É)
LATIN CAPITAL LETTER E WITH CIRCUMFLEX AND ACUTE (Ế)
LATIN CAPITAL LETTER E WITH MACRON AND ACUTE (Ḗ)
LATIN SMALL LETTER E ACUTE (é) LATIN SMALL LETTER E WITH ACUTE (é)
LATIN SMALL LETTER E WITH CIRCUMFLEX AND ACUTE (ế)
LATIN SMALL LETTER E WITH MACRON AND ACUTE (ḗ)
You could go one step more sophisticated and use TeX-input method
(C-x RET C-\)
After which \'e will collapse as é
“Yeah ok but how the ^)*^$# am I to remember the mantra \'e?!” you may ask
True… So as you rightly do,
- pick it up from google
- put emacs into tex input mode
- paste from google into emacs
- place point on the new char and type C-u C-x =
Among other things emacs will helpfully inform you (among other things)
to input: type "\'{e}" or "\'e" with TeX input method
--
https://mail.python.org/mailman/listinfo/python-list
Re: Increasing the diversity of people who write Python (was: Benefits of unicode identifiers)
On Monday, November 27, 2017 at 8:07:47 PM UTC+5:30, Chris Angelico wrote:
> On Tue, Nov 28, 2017 at 1:25 AM, Rustom Mody wrote:
> > You could go one step more sophisticated and use TeX-input method
> > (C-x RET C-\)
> > After which \'e will collapse as é
> > “Yeah ok but how the ^)*^$# am I to remember the mantra \'e?!” you may ask
> > True… So as you rightly do,
> > - pick it up from google
> > - put emacs into tex input mode
> > - paste from google into emacs
> > - place point on the new char and type C-u C-x =
> > Among other things emacs will helpfully inform you (among other things)
> > to input: type "\'{e}" or "\'e" with TeX input method
>
> Which is closely related to the Compose key input method that I use.
> First, you assign a key on your keyboard to be Compose (at least on
> all my systems, there isn't one by default); I use the key between
> left Ctrl and left Alt.
Ha Ha So you wont speak the unspeakable?¿!¡
I also have my compose set (to Capslock)
And I entered those chars above with C?? and C!! where C is Capslock
I most frequently use that for ⇒ (C=>) → (C->) ¹ (C^1) ₁ (C_1) etc
One can find other goodies at /usr/share/X11/locale/en_US.UTF-8/Compose
I didn't start with mentioning that to Skip because his basic requirement
(as I got it) was that
- input method should be OS-neutral
- emacs can be assumed
And so the only OS-non-neutrality that I am aware of is that sometimes
Alt works as Meta (gui-emacsen) and sometimes not terminal/text emacsen
(typically, though I believe some ppl successfully tweak this also)
And so M-x can mean Alt-x (chord) or ESC-x (sequence) and a few such anomalies
But beyond that emacsen should be same for all OSes (modulo versions)
--
https://mail.python.org/mailman/listinfo/python-list
Re: Increasing the diversity of people who write Python (was: Benefits of unicode identifiers)
On Monday, November 27, 2017 at 10:49:35 PM UTC+5:30, Skip Montanaro wrote: > > I strongly suspect that any recent emacs will have M-x insert-char > > (earlier it was called ucs-insert) default bound C-x 8 RET (yeah thats > > clunky) > > which will accept at the minibuffer input > > I tried C-x 8 e acute TAB > > and was prompted with "E-acute". I don't know why it would have > capitalized the "e". Unicode codepoint names are (evidently) ALLCAPS-ASCII Still, I plowed ahead and hit RET > > which yielded an "Invalid character" message in the minibuffer. Unicode is a million+ codepoints Hundred thousand+ of which are assigned This means that (as an analogy) emacs is fishing around in a 100,000 line file which contains lines like LATIN SMALL LETTER A:a:0x61 LATIN CAPITAL LETTER A:A:0x41 DIGIT ONE:1:0x31 ... 100,000 such lines… one of which is LATIN SMALL LETTER E WITH ACUTE:é:0xe9 [Just now fishing around I find its worse than that C-u C-x = tells me: character: é (displayed as é) (codepoint 233, #o351, #xe9) name: LATIN SMALL LETTER E WITH ACUTE old-name: LATIN SMALL LETTER E ACUTE general-category: Ll (Letter, Lowercase) So those hundred thousand chars can have multiple names!! And that constitutes the search space ] So now coming to your attempt: [ Writing this mail, Ive finally done: (global-set-key (kbd "") 'insert-char) which allows me to use F9 instead of the clunky C-x 8 RET I'll assume that binding following ] If I type F9*e acuteTAB I get 121 possibilities: CANADIAN SYLLABICS FINAL DOUBLE ACUTE (ᐥ) COMBINING DOTTED ACUTE ACCENT (᷁) COMBINING DOUBLE ACUTE ACCENT (̋) CYRILLIC CAPITAL LETTER U WITH DOUBLE ACUTE (Ӳ) CYRILLIC SMALL LETTER U WITH DOUBLE ACUTE (ӳ) DEVANAGARI ACUTE ACCENT (॔) DOUBLE ACUTE ACCENT (˝) GREEK UPSILON WITH ACUTE AND HOOK SYMBOL (ϓ) LATIN CAPITAL LETTER A ACUTE (Á) LATIN CAPITAL LETTER A WITH ACUTE (Á) LATIN CAPITAL LETTER A WITH BREVE AND ACUTE (Ắ) LATIN CAPITAL LETTER A WITH CIRCUMFLEX AND ACUTE (Ấ) LATIN CAPITAL LETTER A WITH RING ABOVE AND ACUTE (Ǻ) LATIN CAPITAL LETTER AE WITH ACUTE (Ǽ) LATIN CAPITAL LETTER C ACUTE (Ć) LATIN CAPITAL LETTER C WITH ACUTE (Ć) LATIN CAPITAL LETTER C WITH CEDILLA AND ACUTE (Ḉ) LATIN CAPITAL LETTER E ACUTE (É) LATIN CAPITAL LETTER E WITH ACUTE (É) LATIN CAPITAL LETTER E WITH CIRCUMFLEX AND ACUTE (Ế) LATIN CAPITAL LETTER E WITH MACRON AND ACUTE (Ḗ) LATIN CAPITAL LETTER G WITH ACUTE (Ǵ) LATIN CAPITAL LETTER I ACUTE (Í) LATIN CAPITAL LETTER I WITH ACUTE (Í) LATIN CAPITAL LETTER I WITH DIAERESIS AND ACUTE (Ḯ) LATIN CAPITAL LETTER K WITH ACUTE (Ḱ) LATIN CAPITAL LETTER L ACUTE (Ĺ) LATIN CAPITAL LETTER L WITH ACUTE (Ĺ) LATIN CAPITAL LETTER M WITH ACUTE (Ḿ) LATIN CAPITAL LETTER N ACUTE (Ń) LATIN CAPITAL LETTER N WITH ACUTE (Ń) LATIN CAPITAL LETTER O ACUTE (Ó) LATIN CAPITAL LETTER O DOUBLE ACUTE (Ő) LATIN CAPITAL LETTER O WITH ACUTE (Ó) LATIN CAPITAL LETTER O WITH CIRCUMFLEX AND ACUTE (Ố) LATIN CAPITAL LETTER O WITH DOUBLE ACUTE (Ő) LATIN CAPITAL LETTER O WITH HORN AND ACUTE (Ớ) LATIN CAPITAL LETTER O WITH MACRON AND ACUTE (Ṓ) LATIN CAPITAL LETTER O WITH STROKE AND ACUTE (Ǿ) LATIN CAPITAL LETTER O WITH TILDE AND ACUTE (Ṍ) LATIN CAPITAL LETTER P WITH ACUTE (Ṕ) LATIN CAPITAL LETTER R ACUTE (Ŕ) LATIN CAPITAL LETTER R WITH ACUTE (Ŕ) LATIN CAPITAL LETTER S ACUTE (Ś) LATIN CAPITAL LETTER S WITH ACUTE (Ś) LATIN CAPITAL LETTER S WITH ACUTE AND DOT ABOVE (Ṥ) LATIN CAPITAL LETTER U ACUTE (Ú) LATIN CAPITAL LETTER U DIAERESIS ACUTE (Ǘ) LATIN CAPITAL LETTER U DOUBLE ACUTE (Ű) LATIN CAPITAL LETTER U WITH ACUTE (Ú) LATIN CAPITAL LETTER U WITH DIAERESIS AND ACUTE (Ǘ) LATIN CAPITAL LETTER U WITH DOUBLE ACUTE (Ű) LATIN CAPITAL LETTER U WITH HORN AND ACUTE (Ứ) LATIN CAPITAL LETTER U WITH TILDE AND ACUTE (Ṹ) LATIN CAPITAL LETTER W WITH ACUTE (Ẃ) LATIN CAPITAL LETTER Y ACUTE (Ý) LATIN CAPITAL LETTER Y WITH ACUTE (Ý) LATIN CAPITAL LETTER Z ACUTE (Ź) LATIN CAPITAL LETTER Z WITH ACUTE (Ź) LATIN SMALL LETTER A ACUTE (á) LATIN SMALL LETTER A WITH ACUTE (á) LATIN SMALL LETTER A WITH BREVE AND ACUTE (ắ) LATIN SMALL LETTER A WITH CIRCUMFLEX AND ACUTE (ấ) LATIN SMALL LETTER A WITH RING ABOVE AND ACUTE (ǻ) LATIN SMALL LETTER AE WITH ACUTE (ǽ) LATIN SMALL LETTER C ACUTE (ć) LATIN SMALL LETTER C WITH ACUTE (ć) LATIN SMALL LETTER C WITH CEDILLA AND ACUTE (ḉ) LATIN SMALL LETTER E ACUTE (é) LATIN SMALL LETTER E WITH ACUTE (é) LATIN SMALL LETTER E WITH CIRCUMFLEX AND ACUTE (ế) LATIN SMALL LETTER E WITH MACRON AND ACUTE (ḗ) LATIN SMALL LETTER G WITH ACUTE (ǵ) LATIN SMALL LETTER I ACUTE (í) LATIN SMALL LETTER I WITH ACUTE (í) LATIN SMALL LETTER I WITH DIAERESIS AND ACUTE (ḯ) LATIN SMALL LETTER K WITH ACUTE (ḱ) LATIN SMALL LETTER L ACUTE (ĺ) LATIN SMALL LETTER L WITH ACUTE (ĺ) LATIN SMALL LETTER M WITH ACUTE (ḿ) LATIN SMALL LETTER N ACUTE (ń) LATIN SMALL LETTER N WITH ACUTE (ń) LATIN SMALL LETTER O ACUTE (ó) LATIN SMALL LETTER O DOUBLE ACUTE (ő) LATIN SMALL LETTER O WITH ACUTE (ó) LATIN SMALL LETTER O WITH CIRCUMFLEX AND ACUTE (ố) LATIN SMALL LETTER O WITH DOUBLE ACUTE (
Re: why won't slicing lists raise IndexError?
On Tuesday, December 5, 2017 at 12:40:01 AM UTC+5:30, Jason Maldonis wrote: > I was extending a `list` and am wondering why slicing lists will never > raise an IndexError, even if the `slice.stop` value if greater than the > list length. > > Quick example: > > my_list = [1, 2, 3] > my_list[:100] # does not raise an IndexError, but instead returns the full > list > > Is there any background on why that doesn't raise an IndexError? Knowing > that might help me design my extended list class better. For my specific > use case, it would simplify my code (and prevent `if isinstance(item, > slice)` checks) if the slicing raised an IndexError in the example I gave. Data Structures have invariants. Some of these are just side-notes… interesting, cute Some are more fundamental, the raison d'être for the data structure Whether the following inv is that fundamental or not I wont offer an opinion It certainly seems important (to me) Python slice inv: (∀ n:ℤ, l:sequence | l[:n] + l[n:] == l) Your preferred inv: (∀ n:ℤ, l:sequence ∧ jason_caveat(n) | l[:n] + l[n:] == l) where def jason_caveat(n,l): return 0 ≤ n ≤ len(l) Do you consider it arguable that your preferred invariant is at least more heavy-weight if not downright clunkier? Note I am not offering a view on this. eg for zip python does this >>> zip([1,2,3], [4,5,6,7,8]) [(1, 4), (2, 5), (3, 6)] I find myself sometimes needing this Sometimes needing it extended to the longer (with what??) Sometimes needing your preferred behavior — an exception On a more fundamental note: def const(x): return 42 has the invariant that const(x) == 42 when x is well-defined This is true for most mainstream languages Lazy functional languages (like Haskell) make a big deal of not having the definedness caveat. People (like me) not quite on the FP bandwagon are conflicted on whether the mathematical elegance is worth the computational mess -- https://mail.python.org/mailman/listinfo/python-list
Re: Please tell me how to execute python file in Ubuntu by double clicking on file. (Posting On Python-List Prohibited)
On Tuesday, December 5, 2017 at 2:28:44 PM UTC+5:30, Lawrence D’Oliveiro wrote: > On Tuesday, December 5, 2017 at 3:39:26 AM UTC+13, Rick Johnson wrote: > > > > Sounds like your OS file associations are all botched-up ... > > Linux doesn’t do “OS file associations”. From a strict pov thats right But then from a strict pov linux is not an OS, its just one component of an OS https://www.howtogeek.com/177213/linux-isnt-just-linux-8-pieces-of-software-that-make-up-linux-systems/ The more pragmatic answer to this question is to run $ man xdg-mime $ man xdg-open etc (terrible documentation like everything else gnome… but thats another story) -- https://mail.python.org/mailman/listinfo/python-list
Re: we want python software
On Wednesday, December 6, 2017 at 3:10:24 AM UTC+5:30, Igor Korot wrote:
> Hi, Tony,
>
> On Tue, Dec 5, 2017 at 11:10 AM, Tony van der Hoff wrote:
> > On 05/12/17 16:55, Igor Korot wrote:
> >> Hi,
> >>
> >> On Tue, Dec 5, 2017 at 9:10 AM, Jyothiswaroop Reddy wrote:
> >>> Sir,
> >>> I am b.tech student I would like to learn python. So please send
> >>> the python software.
> >> Sorry, we don't send anything. You will have to go get it yourself. -)
> >>
> > Well, at least try to be helpful:
> > https://www.python.org/downloads/
>
> This is LMGIFY.
> If they say they are tech students - they should know how to work with Google.
>
> And I even tried to be polite. I should have probably write something like:
>
> 1. Open the Web browser.
> 2. In the "Address Bar" type "www.pyton.org".
> 3. Find the link which reads "Downloads". Click on it.
> 4. Carefully read what version you need to install for your OS.
> 5. Apply the acquired knowledge and download the appropriate version.
> 6. Click on the installer (if on Windows).
> 7. Follow all the prompts.
> 8. Enjoy.
>
> but this is too much for the tech student.
You are assuming that the strangeness of the request is about 'tech'
[engineering/tech existed centuries before computers]
Do remember one can be a tech-{student,professional} without
- ever having encountered free-software
- internet/USENET culture
… from which pov the request would not look so odd
--
https://mail.python.org/mailman/listinfo/python-list
Politeness (was: we want python software)
On Wednesday, December 6, 2017 at 4:05:43 PM UTC+5:30, Steve D'Aprano wrote:
> On Wed, 6 Dec 2017 02:49 pm, Rustom Mody wrote:
>
> > You are assuming that the strangeness of the request is about 'tech'
> > [engineering/tech existed centuries before computers]
> >
> > Do remember one can be a tech-{student,professional} without
> > - ever having encountered free-software
> > - internet/USENET culture
> >
> > … from which pov the request would not look so odd
>
> So you're suggesting that rather than being unwilling to google for "Download
> Python" because he doesn't understand free software culture, the OP is
> unwilling to google for "Download Python" because he thinks it is proprietary
> software and wants a bunch of strangers on the Internet to send him a pirate
> copy?
>
> I'm not entirely sure that's better...
Dunno anything about OP so no 'suggesting'…
I did hint one point above which can be restated more explicitly.
An engineering degree (aka “B.Tech”) can be in any of
- IT, CS, Computer Engineering etc
- aeronautics, civil, electrical, mechanical… classical, non-computer related
- bioinformatics, statistics, "scientific computing" etc ie heavy-duty *users*
of computers
For the latter two classes it would be normal/natural for the student to have
little knowledge/interest in computer-related stuff except as a user.
Are you interested in the latest disk-drive technology? power-supplies?
kernel? systemd-vs-sysv? We use these all the time. Likewise these other
fields are *users* of computers.
Inter alia I will mention: I have a colleague working on ACM's next curriculum
And the inter-disciplinarity of CS is the next big deal it would appear.
ie "unwilling to google" could well be "ignorant of google (usage/practices)"
Do consider the possibility that a student could be a non-owner of a computer
and/or studying in a college in a poor/non networked location.
So…
So while the specific slurs/attacks on some country are of near-zero interest
to me — to support or oppose — the deeper divisions and inequities are (IMHO)
more important.
So here's a little statistical exercise for you:
- Take any demographic of your choice containing programmers.
- Compute the male/female programmers in that population
- Now come to this list and work out the same ratio
- How do these ratios compare?
[When's the last time a woman appeared here?]
IOW I would wish Ethan's "control yourself" to be imperated — preferably
by oneself, if not then forcibly.
And especially when the vitriol is flung at a first-time poster.
--
https://mail.python.org/mailman/listinfo/python-list
Lies (was: we want python software)
On Wednesday, December 6, 2017 at 3:05:33 PM UTC+5:30, Steve D'Aprano wrote: > (By the way Rustom, if you're reading, thank you for that link to the video a > few weeks ago about teaching 2 + 2 = 22. My blood pressure just about doubled > watching it.) [Ref: https://youtu.be/Zh3Yz3PiXZw ] Yes… Lies are a big problem today. [For myself] Between being nice and being truthful, latter should have priority. I was at first surprised and even a bit shocked when people called me right-wing. Over time Ive come to accept that lies (left-wing) is upstream of hate (right-wing). And to the extent that effects must be stemmed from causes, the world is probably safer with the right than the left Coming to this thread, I am surprised that you took to task Abhiram R for his (minor) slips of posting, neglecting to mention that the repeated vituperative posts of "KM" are chock-full of - grammatical errors - spelling errors - top-posting - Indianisms like “lakh” “coolie” which are unlikely decipherable by an international audience And that in a post critical of Indians! -- https://mail.python.org/mailman/listinfo/python-list
Re: Anything similar to __END__ in perl
On Friday, December 8, 2017 at 3:13:56 PM UTC+5:30, Karsten Hilbert wrote:
> On Thu, Dec 07, 2017 at 11:55:48PM -0600, Peng Yu wrote:
>
> > Hi, perl has __END__ which ignore all the lines below it.
> >
> > Is there anything similar to __END__ in python? Thanks.
>
> Something similar is:
>
> import sys
> sys.exit()
That will give syntax (or something) errors for what follows
I'd say something similar is """
eg
$ cat xyz.py
def f():
print("hello world")
f()
"""
Tyger Tyger burning bright
In the forests of the night
What immortal hand or eye
Dare frame thy fearful symmetry
"""
--
https://mail.python.org/mailman/listinfo/python-list
Re: we want python software
On Wednesday, December 6, 2017 at 3:10:24 AM UTC+5:30, Igor Korot wrote:
> Hi, Tony,
>
> On Tue, Dec 5, 2017 at 11:10 AM, Tony van der Hoff wrote:
> > On 05/12/17 16:55, Igor Korot wrote:
> >> Hi,
> >>
> >> On Tue, Dec 5, 2017 at 9:10 AM, Jyothiswaroop Reddy wrote:
> >>> Sir,
> >>> I am b.tech student I would like to learn python. So please send
the python software.
> >> Sorry, we don't send anything. You will have to go get it yourself. -)
> >>
> > Well, at least try to be helpful:
> > https://www.python.org/downloads/
>
> This is LMGIFY.
> If they say they are tech students - they should know how to work with
Google.
>
> And I even tried to be polite. I should have probably write something like:
>
> 1. Open the Web browser.
> 2. In the "Address Bar" type "www.pyton.org".
> 3. Find the link which reads "Downloads". Click on it.
> 4. Carefully read what version you need to install for your OS.
> 5. Apply the acquired knowledge and download the appropriate version.
> 6. Click on the installer (if on Windows).
> 7. Follow all the prompts.
> 8. Enjoy.
>
> but this is too much for the tech student.
You are assuming that the strangeness of the request is about 'tech'
[engineering/tech existed centuries before computers]
Do remember one can be a tech-{student,professional} without
- ever having encountered free-software
- internet/USENET culture
â | from which pov the request would not look so odd
--
https://mail.python.org/mailman/listinfo/python-list
repeating posts
Repeating old posts again appearing [No not complaining… I know people are working on it. Thanks Skip and whoever else] Just thought I'd mention they are now mildly mojibaked -- https://mail.python.org/mailman/listinfo/python-list
Re: Please tell me how to execute python file in Ubuntu by double clicking on file. (Posting On Python-List Prohibited)
On Friday, December 8, 2017 at 6:40:17 AM UTC+5:30, Python wrote: > On Thu, Dec 07, 2017 at 01:29:11PM +1100, Steve D'Aprano wrote: > > On Thu, 7 Dec 2017 08:22 am, Python wrote: > > >> > Linux doesn’t do “OS file associations”. > > >> > > >> Then how does my Linux box know that when I double-click on a text file, > > >> it > > >> launches kwrite rather than (say) the Gimp or LibreOffice? > > > > > > The answer to that is (sadly) complicated. > > > > Actually, no, the answer to my question is very simple: Lawrence is mistaken > > about Linux not doing file associations. It does -- it is merely handled by > > the desktop environment (if there is one). > > Pedantically speaking, this is only *probably true*, not certainly > true (e.g. running Linux on a text console with something like > midnight commander, some unrelated file manager while running a > particular desktop environment, etc.). > > But more importantly, practically speaking, it still doesn't really > provide much more help to the OP than Lawrence's answer. He may well > know already that the desktop environment is what does the job (and > probably does even, in broad terms, if he's familiar with computers in > general), but have no idea how to configure it. A reasonably helpful > answer would be one that mentioned a few of the likely possibilities > (Gnome, KDE, Unity, /etc/mime.types, "other"), and gave hints for how > to find out the answer for each. A thoroughly helpful answer would > be, well, outside the scope of this list/group. > > Pedantry has its place, FWIW. In the computer field, as with other > science and engineering disciplines, often precision is much more > essential than in other fields. I personally find such precision is > especially warranted if you take it upon yourself to criticize what > someone else has said. Though, providing such precision via natural > language often turns out to be more challenging than one would hope... I was sending some files to some students. Since it was more than one, the natural choice was a tarball. [I believe that since it was a very tiny total space I did not compress the tarball… but I dont remember this part exactly] The point is that instead of sending a stuff.tgz or stuff.tar file I sent a file called just stuff; ie I must have done: $ tar xvf stuff directory rather than the more normal $ tar xvf stuff.tar directory I got a return mail soon enough: “Your file is corrupt; it wont open” (in file-roller or whatever tar-GUI the kids nowadays use) I could have given them the answer: There are no associations in Linux. Just $ mv stuff stuff.tar and it will work As it happens I am lazy; easier to believe that my file was "wrongly" named; did the mv myself, and resent the now "correct" tarball; problem solved. Whether there was nothing wrong in what I did, the "wrong-right" was de facto, or de jure… I will leave to more wise persons than myself -- https://mail.python.org/mailman/listinfo/python-list
Re: Please tell me how to execute python file in Ubuntu by double clicking on file. (Posting On Python-List Prohibited)
On Sunday, December 10, 2017 at 10:12:38 AM UTC+5:30, Rustom Mody wrote: > I was sending some files to some students. > Since it was more than one, the natural choice was a tarball. > [I believe that since it was a very tiny total space I did not compress the > tarball… but I dont remember this part exactly] > The point is that instead of sending a stuff.tgz or stuff.tar file I sent a > file > called just stuff; ie I must have done: > $ tar xvf stuff directory > rather than the more normal > $ tar xvf stuff.tar directory Er… Not xvf of course but cvf [And yeah the v is not necessary] -- https://mail.python.org/mailman/listinfo/python-list
Re: Please tell me how to execute python file in Ubuntu by double clicking on file. (Posting On Python-List Prohibited)
On Sunday, December 10, 2017 at 11:15:15 AM UTC+5:30, Frank Millman wrote: > "Rustom Mody" wrote in message > > > > I was sending some files to some students. > Since it was more than one, the natural choice was a tarball. > [I believe that since it was a very tiny total space I did not compress the > tarball… but I dont remember this part exactly] > The point is that instead of sending a stuff.tgz or stuff.tar file I sent a > file > called just stuff; ie I must have done: > $ tar xvf stuff directory > rather than the more normal > $ tar xvf stuff.tar directory > > I got a return mail soon enough: “Your file is corrupt; it wont open” > (in file-roller or whatever tar-GUI the kids nowadays use) > > I could have given them the answer: There are no associations in > Linux. Just > $ mv stuff stuff.tar > and it will work > As it happens I am lazy; easier to believe that my file was "wrongly" named; > did the mv myself, and resent the now "correct" tarball; problem solved. > > > > I had a similar experience a few years ago, but the recipient was not a > student, but a bank's IT department! > > I had to send them an encrypted document, and their spec specified PGP. I > used GPG instead, which produces exactly the same result, but with a .gpg > file extension. > > I was told that my file did not work. After much time trying to figure out > what was wrong, I spoke to one of their staff over the phone, and asked him > to right-click on the file, select 'rename', and change '.gpg' to '.pgp'. He > did so, tried again, and said 'Ah, now it works'. Inspired by this thread, I added alias o="xdg-open" to my ~/.bash_aliases And as best as I can see, now $ o foo.png $ o bar.mp3 $ o baz.pdf and $ o http://python.org all do the “Right Thing” My main attraction for this is that I often end up doing evince foo.png instead of eog foo.png The one thing that does not work (yet) is $ o foo.py starts up gedit (instead of emacs) PS. As it happens I had figured out something for my students some years ago: https://bitbucket.org/rustom/vit-projects/wiki/emacsasdefault I’ll have to reread and recheckout what I wrote back then 😉 -- https://mail.python.org/mailman/listinfo/python-list
Re: Please tell me how to execute python file in Ubuntu by double
This thread is getting like a mini hologram of our current surreal time… If we can put aside who is right and wrong for a moment we see the more frightening spectacle that Repubs and democrats, Remainers and Brexiters and so on all over — by getting more and more shrill are not talking to each other but past each other So… On Tuesday, December 12, 2017 at 2:45:32 AM UTC+5:30, Rick Johnson wrote: > Rustom Mody wrote: > > [...] > > > Whether there was nothing wrong in what I did, the "wrong- > > right" was de facto, or de jureâ | I will leave to more wise > > persons than myself > > A file with no extension (regardless of the OS or desktop enviroment that it > was created on), is like a sealed box with no label to indicate the contents. So to Rick: Not if you use something like file (magic) My (unschooled) estimate is it gets its detection right 80% of the time And to Chris and others who think file(magic) is a replacement for file-associations. Even assuming that magic works 100% : Say I have an html file. That means its ALSO a text file. So its equally legitimate to set defaults to use… - a plain text editor (of which there are hundreds) - to open it in browser of choice (also plural nowadays) - some sort of html composer - etc Which means we are beyond the nature of the file per se to the pattern of its usage Yeah… magic… in the category of mind-reading? sooth-saying? -- https://mail.python.org/mailman/listinfo/python-list
Re: Answers to homework questions [WAS]: Re: Python homework
On Thursday, December 14, 2017 at 3:53:21 PM UTC+5:30, Lorenzo Sutton wrote: > Hi Roger, > > On 13/12/17 23:31, ROGER GRAYDON CHRISTMAN wrote: > > On Wed, Dec 13, 2017, Lorenzo Sutton wrote: > >> > > On 05/12/17 06:33, nick martinez2 via Python-list wrote: > >>> I have a question on my homework. > [...] > >> For this kind of problem I think the collections module [1] can be very > >> useful. In this case in particular have a look at the Counter package ;) > [...] > > > > A nice answer at face value, and for general questions, but > > perhaps not the best given the subject line and the first sentence > > in the OP's note. > > > [...] > > When I teach my course, I have no desire to have > > all my students turn into cargo cultists. > > > > At least this particular student did post his intended solution, > > instead of outright begging for code. And most of the responses > > I see did attempt to work within the perceived constraints > > regarding what language tools the student was expected to use. > > I see your point as a teacher, but after all this *is* a Python mailing > list and not a python-homework-support mailing list. > > Plus, the OP had already received various good answers specifically > helping them solve the problem along the lines of his proposed code, so > I guessed hinting to a standard library module which is interesting and > potentially relevant in this case might be useful to both the OP and > other people on the ML while enriching the discussion ;-) Somebody has already pointed out that some setting in Roger Christman's mail client(?) breaks discussion threads. Now either Lorenzo is also breaking threads… Or else something in Roger's post makes the next person (in this case Lorenzo) break the thread¿? -- https://mail.python.org/mailman/listinfo/python-list
Re: Answers to homework questions [WAS]: Re: Python homework
On Thursday, December 14, 2017 at 7:02:56 PM UTC+5:30, Rustom Mody wrote: > On Thursday, December 14, 2017 at 3:53:21 PM UTC+5:30, Lorenzo Sutton wrote: > > Hi Roger, > > > > On 13/12/17 23:31, ROGER GRAYDON CHRISTMAN wrote: > > > On Wed, Dec 13, 2017, Lorenzo Sutton wrote: > > >> > > > On 05/12/17 06:33, nick martinez2 via Python-list wrote: > > >>> I have a question on my homework. > > [...] > > >> For this kind of problem I think the collections module [1] can be very > > >> useful. In this case in particular have a look at the Counter package ;) > > [...] > > > > > > A nice answer at face value, and for general questions, but > > > perhaps not the best given the subject line and the first sentence > > > in the OP's note. > > > > > [...] > > > When I teach my course, I have no desire to have > > > all my students turn into cargo cultists. > > > > > > At least this particular student did post his intended solution, > > > instead of outright begging for code. And most of the responses > > > I see did attempt to work within the perceived constraints > > > regarding what language tools the student was expected to use. > > > > I see your point as a teacher, but after all this *is* a Python mailing > > list and not a python-homework-support mailing list. > > > > Plus, the OP had already received various good answers specifically > > helping them solve the problem along the lines of his proposed code, so > > I guessed hinting to a standard library module which is interesting and > > potentially relevant in this case might be useful to both the OP and > > other people on the ML while enriching the discussion ;-) > > Somebody has already pointed out that some setting in Roger Christman's > mail client(?) breaks discussion threads. > Now either Lorenzo is also breaking threads… > Or else something in Roger's post makes the next person (in this case Lorenzo) > break the thread¿? Didn't notice that Lorenzo had renamed the subject line Sorry for noise -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Learning
On Saturday, December 16, 2017 at 9:45:17 AM UTC+5:30, Bill wrote: > Chris Angelico wrote: > > On Sat, Dec 16, 2017 at 8:51 AM, Bill wrote: > >> Varun R wrote: > >>> Hi All, > >>> > >>> I'm new to programming, can anyone guide me, how to start learning python > >>> programming language,...plz suggest some books also. > >>> > >>> Thanks all > >> > >> Are you sure you want to learn Python first? > >> Python does enough things "behind the scene" > >> that it makes me question the wisdom of that. > >> Other points of view are welcome, of course. > >> Learning the primitives of C++ first, may make for an easier transition. > >> Surely this has been discussed before? > > On the contrary, that makes Python an *excellent* first language. We > > don't force people to learn about the chemistry of petrochemical > > combustion before letting them learn how to drive a car; we don't make > > people understand TCP/IP networking before they're allowed to type > > something into Google. And if you DO want people to start off with a > > lower-level language, why C++? Why not machine code (or at least > > assembly code), since that's what the CPU actually executes? > > Most decent introductions to C++ discuss machine language (it helps make > sense of compilation). > As you indirectly suggest, learning is something of a circular process, > so it really doesn't make that much difference where one starts, just > "Do It!". : ) Really¿? https://en.wikipedia.org/wiki/Principles_of_learning#Primacy -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Learning (Posting On Python-List Prohibited)
On Sunday, December 17, 2017 at 6:39:41 AM UTC+5:30, Lawrence D’Oliveiro wrote: > On Sunday, December 17, 2017 at 2:26:43 AM UTC+13, Marko Rauhamaa wrote: > > > Unfortunately, Python's indentation mechanism makes the REPL too > > frustrating an environment to type in even the simplest of function > > definitions, let alone a whole class. > > Let me suggest using a Jupyter notebook as an introductory program editor. Um… Well… At first I did not take jupyter seriously “browser is the universal OS” — Sounds like the usual empty fluff But now seeing things like this: http://www.leouieda.com/blog/scipy-on-android.html I guess I am going to be force -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Learning
In response to > Rustom Mody wrote: >> On Saturday, December 16, 2017 at 9:45:17 AM UTC+5:30, Bill wrote: >>> so it really doesn't make that much difference where one starts, just >>> "Do It!". : ) >> Really ¿? >> https://en.wikipedia.org/wiki/Principles_of_learning#Primacy On Sunday, December 17, 2017 Bill wrote: > You would give precedence to something written on a wikipedia page over > your experience? Bill also wrote: > …in college, the prerequisite of "at least co-enrolled in pre-calc", > turned out to be the right one (based upon quite a lot of teaching > experience). So… I dont understand where you are coming from: Is there such a thing as a “learning curve” or not? -- https://mail.python.org/mailman/listinfo/python-list
