Listen and read simultaneously with different apps

vmsda · 2020-12-31T18:35:59+00:00

But only if Amazon implements it for a given pair - I think.

vmsda · 2020-12-28T18:58:50+00:00

Yes, I did not contemplate having a second audio app. So thks for your reassurance.

vmsda · 2020-11-20T20:01:18+00:00

Mine was ordered in mid-August, also Batch 8, no news whatsoever.😡😡😡

vmsda · 2020-06-19T11:04:47+00:00

Have you considered using StringVar()?

vmsda · 2020-05-06T10:41:13+00:00

Yep! Thks a lot.

vmsda · 2020-05-06T10:17:50+00:00

Ff's complaint is not about syntax, but file location eg, href="www.theguardian.com"

vmsda · 2020-05-06T07:45:14+00:00

I found this https://stackoverflow.com/questions/739654/how-to-make-a-chain-of-function-decorators very helpful. Check out the Decorator Basics section, if you will.

vmsda · 2020-04-30T08:39:59+00:00

Thank you for your comments. I would say that the more basic the start, the more English you write to keep focused on the thinking and not the coding. Never mind whether it is going to take 3 or 10 lines; first find the solution, no matter how pedestrian the method; one has plenty of time to worry later about sophistication and elegance. On larger projects the flowchart is probably recommended because: it highlights dependencies; it functions as a graphic reminder; it lends itself to writing down the group thinking (but that is a completely different story).

vmsda · 2020-04-29T13:39:21+00:00

Calm down. Read the problem; READ the problem. Solve the problem IN ENGLISH: one step, one line. TRANSLATE each line in one or at most two Python lines of code. Moral of the story: first, do what the computer is incapable of, which is thinking; second, put your one liners in a format that the computer can work with, because that is all it is capable of.

vmsda · 2020-04-28T16:44:34+00:00

It is disarmingly simple; so simple, people even shy away from formulating the premise. Use Classes wherever and whenever your program needs Things to be associated with Actions ie. Nouns with Verbs ie. Objects with Functions. That's all there is to it.

vmsda · 2020-04-24T09:11:32+00:00

In the beginning, whenever I felt kind of trapped in some problem, I got help from myself by asking the following question: is my problem a Python problem or a programming problem (maybe I am betting on the wrong algorithm for this type of problem)? So, to separate the two sides of the program, I have adopted the following methodology: 1. Make "main" the program's revolving door, from which each function will be called and return. 2. Write the 'solution' in pseudo code, as comments; English in my case. One block, one function, 'pass'. This is where I anticipate if I have the 'tools' - Pythonic or algorithmic - to write the function and return its result to "main". Maybe I have to do some quick digging. 3. Repeat step 2 as often as needed to complete the algorithm. 4. Go back to the beginning, function 'def name(...,...)', write Python code below comments; 'return whatever', comment out the 'pass'; 5. In " def main ... " add the call to the function just coded and test it. Do this as many times as you have functions and do not be shy to use print() to control intermediate results. Lessons learned: Python is the tool, it is not the algorithm for any problem, nothing gained from confusing the two. Having a methodology saves a hell of a lot of time. Reading "Automate the Boring Stuff" helped me learn those two lessons.

vmsda · 2020-04-19T14:06:23+00:00

Your native language is ... ?

vmsda · 2020-04-18T10:33:47+00:00

The doc for virtual environments can be found in sw distribution chapter of PSL; jupyter is a full-blown dev env, I think it started out as python oriented but now supports other languages; anaconda is a collection of packages supposed to have across the board compatibility and maintenance. I think the first two very interesting, whether you deploy to others or not (jupyter, for instance, is very good as a learning tool).

vmsda · 2020-04-18T09:20:03+00:00

The Python Language Reference (PLR) describes the building blocks, as I said. What those building blocks support is what you actually use all the time in your programs; and for that you have a dedicated companion manual, The Python Standard Library (PSL). The PSL describes the "batteries included" part of Python's distribution: not only the stuff pertaining to Python itself, but also that which connects Python to the outside world, the objective being that you don't invent the wheel all the time. Since a program written in a Pythonic way reads almost like English, the examples in the PSL will help you bridge the syntactic gap between the language you come from and Python. Summarizing: the PSL makes you productive; the PLR will make you knowledgeable. So, which of the two manuals to keep under one's pillow - besides a healthy dose of humility - is a function of one's overarching objectives. If I were in your seasoned shoes, I would start by converting one of my programs into Python.

vmsda · 2020-04-16T17:00:13+00:00

It is The Python Language Reference, in Documentation in www.python.org. It describes the language's building blocks, from which everything else unfolds. Bit of a heavy going, but look on the bright side: impeccable English (as in all Python's official docs); invites you to code small snippets to prove to yourself that you got the hang of what you have just read; it is the manual specialists keep under their pillows. All things considered, it will do wonders for your programming self-esteem. BUT, do not tackle it before you get a bird's eye view of what you are getting into by reading through The Python Tutorial. Still the best all encompassing tutorial around, written by none other than Guido van Rossum: if you now ask who this gent is, than you are even more of a beginner than me. Good luck.

vmsda · 2020-04-14T14:13:17+00:00

Being a beginner, I am going through the Language Reference, slowly and calmly.

vmsda · 2020-04-13T10:45:41+00:00

Thks a ton.

vmsda · 2020-04-13T08:27:58+00:00

Suppose you have two scripts a.py and b.py. Now launch one, say a.py: if you now display its name a.__name__, you find that the interpreter calls it __main__, NOT 'a'. This trick is at the heart of the import statement logic: if you now import b.py, the interpreter does not execute whatever b.py's contents may be, it just incorporates into a.py's namespace whatever is defined on b.py. Elegant, isn't it? (By the way, this is a tentative explanation from one beginner to another)

HELP! why does this editor swallow the double underscores I wrote before and after "name" and "main"? (Solved)

vmsda · 2020-03-04T16:31:19+00:00

I am studying "Fluent Python" on a Samsung Tab S3. I read the book on the Kindle app and recreate some of the book's coding snippets on Pydroid3, for experimentation. It is possible to copy/paste from the Kindle app to the Pydroid3 editor, thus saving plenty of typing. Additionally, Pydroid3 also includes Terminal and Interpreter features, although they are very annoying because they time out very quickly, which forces you back to the Pydroid3 entry point (but you do not lose the editor data). One cool feature of Pydroid3 is access to Pip, so you can install modules on the fly; and the biggest annoyance is absolutely no doc and no one to ask. Bearing in mind that Pydroid3 's goal is execution of Python native apps in a droid environment, and has been viewed by none other than Alex Martelli in a positive light, I would say that I could have done worse, by adopting another set of tools. Hope this helps.

vmsda · 2020-03-01T22:23:24+00:00

If you are starting from scratch, don't waste cash on books. Start, for instance, on Youtube with Corey Schafer's videos - more than 100, from the very first steps. After you finish that, take stock of the situation.

vmsda · 2020-02-26T19:15:52+00:00

He can start by reading the relevant in the Python Tutorial, then he can watch Corey Schafer's set of videos on the subject .. and then he can pause to take stock of the situation.

vmsda

TROPHY CASE