Re: Python for beginners or not? [was Re: syntax difference]

To: Steven D'Aprano From: Rick Johnson On Monday, June 25, 2018 at 5:56:04 AM UTC-5, Steven D'Aprano wrote: > Nearly everybody misses the fact that the Zen is a joke, > not to be taken *too* seriously. A particularly subtle > joke, but still a joke. The Python Zen is not mere

Re: syntax difference

To: Steven D'Aprano From: "Rick Johnson" To: Steven D'Aprano From: Rick Johnson On Sunday, June 24, 2018 at 10:05:14 AM UTC-5, Steven D'Aprano wrote: [...] > Be fair. It's more like 50% of the time. Let's not dogpile > onto Bart. He asked a question, I answered it, we

Re: Anyone here on Python-Dev mailing list?

To: Steven D'Aprano From: Rick Johnson Steven D'Aprano wrote: [...] > I get spam bots trying to flush out suckers. I don't get > bots that send out random messages to random people. Why? Steven, my son, i suppose some questions just answer themselves... --- BBBS/Li6 v4.10 Toy-3 *

Re: syntax difference

To: Steven D'Aprano From: Rick Johnson On Sunday, June 24, 2018 at 10:05:14 AM UTC-5, Steven D'Aprano wrote: [...] > Be fair. It's more like 50% of the time. Let's not dogpile > onto Bart. He asked a question, I answered it, we don't all > need to sink the boot in as well. And why a

Re: "Data blocks" syntax specification draft

From: Rick Johnson On Sunday, May 20, 2018 at 5:29:11 PM UTC-5, Mikhail V wrote: > What against PDF? I'm not a big fan of PDF either. Adobe Reader is one the most bloated POS software i have ever had the misfortune of hosting on my computers, and i absolutely refuse to host that crapware

Re: syntax difference

On Tuesday, June 19, 2018 at 1:02:52 PM UTC-5, Ian wrote: > On Mon, Jun 18, 2018 at 2:57 PM Rick Johnson [...] > > The point is, from the POV of the interpreter and the > > programmer. comments are always going to be comments > > regardless of whether special pur

Re: syntax difference

On Tuesday, June 19, 2018 at 4:12:10 AM UTC-5, Steven D'Aprano wrote: [...] > People have been requesting static typing in Python virtually since Day > 1, "Day one"??? Really? "People"??? How many people? Contrary to to your fuzzy memories, Steven, we all know that Guido _purposely_

Re: syntax difference

Rhodri James wrote: [...] > It has little flea executioners running around with little flea axes > chopping off little flea heads? Hmm. And who knew that Python-list was really just a homicidal flea circus. Go figure! -- https://mail.python.org/mailman/listinfo/python-list

Re: syntax difference

On Tuesday, June 19, 2018 at 5:21:25 AM UTC-5, Chris Angelico wrote: > On Tue, Jun 19, 2018 at 8:12 PM, Steven D'Aprano > wrote: > > On Mon, 18 Jun 2018 11:34:40 -0700, Jim Lee wrote: > > > >> On 06/18/2018 11:18 AM, Chris Angelico wrote: > >>> What, fundamentally, is the difference between type

Re: syntax difference

On Monday, June 18, 2018 at 2:48:58 PM UTC-5, Ian wrote: > I would also note that none of this applies to type hinting > in any case. Type hints don't require the programmer to be > able to explain anything in natural language, nor are they > prone to becoming out-of-sync. > > Because if they do,

Re: syntax difference

Chris Angelico wrote: [...] > assert """ > , ", ";print('Will I print?');\ > "';print("Or will I?");\ > ';print("What about me?");'''\ > print("And me? Where endeth");"""\ > print('the assertion?');\ Chris, that's not code... That's a syntactical representation of some random flea

Re: syntax difference

On Monday, June 18, 2018 at 1:50:09 PM UTC-5, Chris Angelico wrote: [...] > I don't know what you mean by "syntactic meaning". Do you mean that > they create no executable bytecode, that they have no run-time > influence? Because that's not entirely true; they are stored, and can > be viewed at

Re: syntax difference

On Monday, June 18, 2018 at 1:02:18 PM UTC-5, Ian wrote: [...] > When PEP 3107 was written, it was anticipated that > annotations would find more uses than just type hinting. > Some of those proposed ideas (e.g. database query mapping) > depend on the annotation being readable at run-time, for >

Re: syntax difference

On Monday, June 18, 2018 at 12:46:36 PM UTC-5, Chris Angelico wrote: > What about assertions? Are they comments too? Should we > have, for instance: > > if x > 0: > ... > elif x < 0: > ... > else: > #assert: x == 0 > ... > > or is it better to use an 'assert' statement? After

Re: syntax difference

Ian wrote: > Uh, yes, they do. They're defined in PEP 484, and Mypy uses them for > type-checking Python 2 code, where the annotations don't exist. So when will the interleaved type-hints be removed from the language specification? -- https://mail.python.org/mailman/listinfo/python-list

Re: syntax difference

Steven D'Aprano wrote: > Moving the type-checking out of the core language into the > IDE or linter which can be used or not used according to > the desire of the programmer Except, what your poppycock commentary seems to glaze over is the fact that whilst a programmer can certainly decided to

Re: syntax difference

Steven D'Aprano said: > Python is not only alive and well, but actually growing in > popularity according to (as far as I can see) all the well- > known measures of language popularity. Steven *ALSO* said: > "Ever since I learned about confirmation bias, I've been > seeing it everywhere." Hmm?

Re: syntax difference

Steven D'Aprano wrote: [...] > particular at DropBox, which is (I believe) funding a lot of Guido's time > on this, because they need it. And now we get to the truth! Guido's new puppet master is the sole reason why this fine community -- of once free-roaming *STALLIONS*-- is now corralled

Re: syntax difference

Bart wrote: [...] > For example, comments that start with #T# (and in my case, > that begin at the start of a line). Such would be a _breeze_ to parse out. And i would argue (given a sufficiently unique tag) that arbitrary white space would not be any more error prone, either. Thus, your "tagged

Re: syntax difference

On Monday, June 18, 2018 at 6:43:36 AM UTC-5, Steven D'Aprano wrote: > The programmer can ignore [type-hints], just as they can > ignore any other form of documentation. Type-hints, as implemented, break all the rules of conventional documentation. In any programming language i have ever seen,

Re: syntax difference

On Monday, June 18, 2018 at 6:57:27 AM UTC-5, Steven D'Aprano wrote: > I still think that Python has been going nowhere but downhill ever since > extended slicing was added in version 1.4. Apples to oranges! -- https://mail.python.org/mailman/listinfo/python-list

Re: syntax difference

Chris Angelico wrote: > Bart wrote: [...] > > What will those look like? If copyright/license comments > > have their own specific syntax, then they just become > > another token which has to be recognized. > > If they have specific syntax, they're not comments, are they? Yes, they are. >From

Re: syntax difference

On Monday, June 18, 2018 at 5:45:28 AM UTC-5, Chris Angelico wrote: > So in both cases, you would probably end up with something > like 2to3. And there you have it! Just Like Python3000, the python devs have caused a major disruption by saddling us with the syntactic noise of type- hints.

Re: syntax difference

Jim Lee wrote: > Chris wrote: > > > > I said that you can't decry changes that were before > > your time (they're simply the way things are). > > Really? Wow. I'd hate to live in your world! Just > because something exists, it can't be challenged or > questioned. Got it! Chris is a good

Re: syntax difference

Chris Angelico wrote: [...] > What was the quote before that? > > > "Type-hint comments" would allow: > > (3) and those who utterly *HATE* them, to write a simpl[e] > > little function which will strip them from any and all > > source code they might be forced to maintain. > > Put up or

Re: syntax difference

On Sunday, June 17, 2018 at 9:22:57 PM UTC-5, Chris Angelico wrote: > First, No. You're not squirming your way out this one Chris. _You_ leveled the assertion that removing interleaved type- hints from the executable code would be easier than removing my proposed "type-hint comments". What

Re: syntax difference

Chris Angelico wrote: [...] > A. Isn't it cute, how he thinks that comments are easier to remove > than other elements equally well defined in the grammar? And may we see your code that will remove all instances of type-hints error free? Hmm? I look forward to scraping the internet for

Re: syntax difference

On Sunday, June 17, 2018 at 3:58:26 PM UTC-5, Dan Stromberg wrote: [...] > I actually really like Python's type hinting, which I've recently started > using. I've now used it on 10 projects, and I imagine I'll be using it in > many more. > > Don't like them? I guess you don't have to use them.

Re: syntax difference

On Sunday, June 17, 2018 at 4:17:33 PM UTC-5, Chris Angelico wrote: > On Mon, Jun 18, 2018 at 7:10 AM, Jim Lee wrote: > > > > > > On 06/17/2018 01:56 PM, Chris Angelico wrote: > >> > >> On Mon, Jun 18, 2018 at 6:50 AM, Jim Lee wrote: > >>> > >>> > >>> On 06/17/2018 01:35 PM, Chris Angelico

Re: syntax difference

On Sunday, June 17, 2018 at 2:07:40 PM UTC-5, Jim Lee wrote: > IMHO, trying to shoehorn static type checking on top of a dynamically > typed language shows that the wrong language was chosen for the job. Exactly. I'm not against the idea of Python growing a new feature. Features are great. My

Re: syntax difference

Steven D'Aprano wrote: > Bart Wrote: > > So what's a Type Hint associated with in Python? > Since it is a type *hint*, not a type *declaration*, the > interpreter can and does ignore it. But yet, the _programmer_ cannot ignore it. Does that make any sense to you, or anyone else with half a brain?

Re: syntax difference

Chris Angelico wrote: [...] > For the record, there's nothing at all wrong with printf-style > formatting; its flexibility and brevity make it extremely useful in > many situations. Except that it's old, not elegant, error prone, feature poor, and not Pythonic! But besides all _that_ (and

Re: Python list vs google group

On Friday, June 15, 2018 at 9:14:13 PM UTC-5, Richard Damon wrote: > if the Windows driver broke some specification but still sort > of worked [...] ...that's when the engineers in the Redmond, WA area know it's time to package and ship the product! --

Re: text mining

On Friday, June 15, 2018 at 8:00:36 AM UTC-5, Steven D'Aprano wrote: > Seriously, you are asking strangers to help you out of the goodness of > their heart. Stop lying Steven. Nobody here has a heart. This is Usenet, dammit. -- https://mail.python.org/mailman/listinfo/python-list

Re: PEP8 compliance

On Wednesday, June 13, 2018 at 10:47:40 AM UTC-5, Steven D'Aprano wrote: > I'm of two minds here... Obviously. > [...] So use your own judgement: if following PEP 8 becomes > a chore, or if you would rather follow your own style, > don't feel guilty about ignoring the style guide. IOWs:

Re: Splitting up large python module impact on performance?

On Wednesday, June 13, 2018 at 4:27:35 AM UTC-5, Chris Angelico wrote: > It's more his definition of "large" and "small" that I was > disagreeing with. You're absolutely right that a dense > global scope is a problem; but a "one class per file" rule > is a terrible idea. What if the "one class"

Re: Splitting up large python module impact on performance?

On Tuesday, June 12, 2018 at 10:35:47 PM UTC-5, Chris Angelico wrote: [...] > A few thousand lines in a file is only a problem if you're > using an editor that lacks a Find feature. Or if you use > bad function/class names that you can't search for. I'm unaware of any text editor that doesn't

Re: Splitting up large python module impact on performance?

Bill Deegan wrote: > I'm doing some refactoring on a fairly large python > codebase. Some of the files are > 4000 lines long and > contain many classes. I would argue that files of such size are a total pain to navigate and thus, edit. I prefer to place only one -- or only a handful of classes --

Re: Stefan's headers [was:Names and identifiers]

Gregory Ewing wrote: [...] > * Charging money for copies of software is not the only way > to make money from programming. You can charge for support > services. You can charge for writing custom one-off > software. There are people who make a good living from > doing these things. Microsoft

Re: Index of entity in List with a Condition

subhaba...@gmail.com wrote: > I have the following sentence, > > "Donald Trump is the president of United States of America". > > I am trying to extract the index 'of', not only for single but also > for its multi-occurance (if they occur), from the list of words of the > string, made by simply

Re: Stefan's headers [was:Names and identifiers]

On Monday, June 11, 2018 at 3:04:14 PM UTC-5, MRAB wrote: > On 2018-06-11 20:17, Rick Johnson wrote: [...] > > A dashboard is a horrible analogy. Software and hardware > > are connected at the _hip_. A more correct analogy to > > describe the relationship betw

Re: Stefan's headers [was:Names and identifiers]

On Monday, June 11, 2018 at 1:02:15 PM UTC-5, Chris Angelico wrote: > You're trying to argue against my hypothetical statements > about game publishing, and declaring that it's possible to > use software to encourage hardware sales. But my point was > that, absent copyright and the ability to

Re: user defined modules

Sharan Basappa wrote: > Is there a specific location where user defined modules > need to be kept? My advice is that any location is a good location so long as the location you chose is _not_ a part of the PythonXY directory tree. For example, on a windoze machine (and in Python2.x at least),

Re: Stefan's headers [was:Names and identifiers]

Gene Heskett wrote: > I rather like that idea. Unforch, who would be in charge of keeping the > books uptodate? The USTPO? Of course that would expand another guvmnt > agencies payroll x10, and its a waste of taxpayer dollars since Albert > retired anyway. What century are you trapped in pal?

Re: Stefan's headers [was:Names and identifiers]

On Friday, June 8, 2018 at 12:34:58 PM UTC-5, Marko Rauhamaa wrote: > PS IMO copyright laws should be abolished altogether. At > the very least one should pay for copyright protection. One > €1 for the first year, €2 for the second, €4 for the third > and so on exponentially. I like your idea of

Re: Why exception from os.path.exists()?

Marko Rauhamaa wrote: > Chris Angelico : > > > Marko Rauhamaa wrote: > >> > >> This surprising exception can even be a security issue: > >> > >>>>> os.path.exists("\0") > >>Traceback (most recent call last): > >> File "", line 1, in > >> File

Re: (no subject)

sagar daya wrote: > Couldn't install any module from pip > Plz help??? As with most actions, an algorithm is required. (shocking, i know!) What methodology have you implemented thus far to achieve your goal of "installing modules from PIP"? Please enumerate the steps you chose to take, and then

Re: Python Developer Survey: Python 3 usage overtakes Python 2 usage

Grant Edwards wrote: > Etienne Robillard wrote: > > > Do you understand that a modern mobile device typically > > require a Internet subscription and an additional > > subscription for the smart phone? > > Huh? What is "an internet subscription"? Why would you > need two of them if all you

Re: Python Developer Survey: Python 3 usage overtakes Python 2 usage

On Friday, March 30, 2018 at 8:59:16 PM UTC-5, Chris Angelico wrote: [...] > You can pooh-pooh any statistic. Yeah, except the ones supported by actual _facts_. > So far, though, you have provided NO statistics of your > own, just your own gut feeling. Uh huh. And what do you call drawing

Re: Python Developer Survey: Python 3 usage overtakes Python 2 usage

On Friday, March 30, 2018 at 7:44:40 PM UTC-5, Steven D'Aprano wrote: [...] > Reddit's /ruby subreddit: 40,571 subscribers. > > Reddit's /python subreddit: 230,858 subscribers. Those numbers mean nothing unless you can prove all two- hundred-thirty-odd thousand of them to be active, non- tolling,

Re: Python Developer Survey: Python 3 usage overtakes Python 2 usage

On Friday, March 30, 2018 at 10:45:35 AM UTC-5, Terry Reedy wrote: > https://www.jetbrains.com/research/python-developers-survey-2017/ > “Which version of Python do you use the most?” > 2014 80% 2.x, 20% 3.x > 2016 60% 2.x, 40% 3.x > 2017 25% 2.x, 75% 3.x > > This is a bigger jump than I

Re: Ruby parens-free function calls [was Re: Accessing parent objects]

On Wednesday, March 28, 2018 at 2:25:42 AM UTC-5, Gregory Ewing wrote: > Rick Johnson wrote: > > The only difference is when you want to make a call from a > > _reference_, which, as you and i well know, is not the > > most common way func/meths are called (these are rar

Re: Pep8 for long pattern

On Tuesday, March 27, 2018 at 9:37:14 PM UTC-5, Dan Stromberg wrote: > I can easily get 132+ columns of a font large enough for my > 52 year old eyes on a 15" laptop. Well, if you're comfortable with the long lines, fine. But be aware that long lines are poo-pooed in most professional

Re: Ruby parens-free function calls [was Re: Accessing parent objects]

On Tuesday, March 27, 2018 at 6:55:23 PM UTC-5, Steven D'Aprano wrote: > On Tue, 27 Mar 2018 09:28:34 -0700, Rick Johnson wrote: [...] > > Since when did utilizing a method to request a specific > > value become some sort of magic? > > Since it requires a special method

Re: Pep8 for long pattern

On Tuesday, March 27, 2018 at 4:02:37 PM UTC-5, Dan Stromberg wrote: > On Tue, Mar 27, 2018 at 8:18 AM, Michael Torrie wrote: > > But when it's exactly what you need, why do you need to > > shoehorn the expression into 79 characters? Seems > > pointless in a case like this.

Re: Ruby parens-free function calls [was Re: Accessing parent objects]

On Tuesday, March 27, 2018 at 4:47:05 PM UTC-5, Gregory Ewing wrote: > Rick Johnson wrote: > > rb> Object.method("print_name").call("Meathead") > > Yes, but the point is that you have to have to use a different > syntax to call it. This is

Re: Ruby parens-free function calls [was Re: Accessing parent objects]

On Tuesday, March 27, 2018 at 11:35:31 AM UTC-5, Chris Angelico wrote: > Why are you suggesting that this is magic? _You_ are the one who leveled the accusation that Ruby's methodology for fetching a function reference (a la): Object.method(meth-name-here) is "magic". I'm merely requesting

Re: Ruby parens-free function calls [was Re: Accessing parent objects]

On Tuesday, March 27, 2018 at 8:46:54 AM UTC-5, Chris Angelico wrote: [...] > Cool, so Greg was right: you can't get a reference to a > method or function. You need magic to simulate it. Since when did utilizing a method to request a specific value become some sort of magic? Do you consider this

Re: (no subject)

On Tuesday, March 27, 2018 at 7:19:53 AM UTC-5, kevon harris wrote: > Unable to pull up IDLE after downloading Python 3.6.4 > > Sent from Mail for Windows 10 What OS? On Windows running Python2.X, IDLE is located @ '/Python2X/Lib/idlelib/idle.pyw' --

Re: Ruby parens-free function calls [was Re: Accessing parent objects]

On Tuesday, March 27, 2018 at 3:24:48 AM UTC-5, Steven D'Aprano wrote: > On Mon, 26 Mar 2018 11:37:35 -0700, Rick Johnson wrote: > Printing a string and calling a function is obfuscated code? Deary me. When the programmer can't be bothered to invent names more descriptive than `a` and `b

Re: Ruby parens-free function calls [was Re: Accessing parent objects]

On Tuesday, March 27, 2018 at 1:55:01 AM UTC-5, Gregory Ewing wrote: > Chris Angelico wrote: > > Question: How do you get a reference to a Ruby function? Or are they > > not first-class objects? > > They're not first-class. So, you can't. If Chris means: "how do you get a reference to a Ruby

Re: Ruby parens-free function calls [was Re: Accessing parent objects]

On Monday, March 26, 2018 at 6:11:31 PM UTC-5, Python wrote: > On Mon, Mar 26, 2018 at 02:19:12PM -0700, Rick Johnson wrote: [...] > > Hmm. If "syntax parser rules" could prevent poorly > > formatted code, then there'd be no need for style guides. > > It may be t

Re: Ruby parens-free function calls [was Re: Accessing parent objects]

On Monday, March 26, 2018 at 3:09:38 PM UTC-5, Python wrote: > On Mon, Mar 26, 2018 at 11:37:35AM -0700, Rick Johnson wrote: [...] > > Ruby followed the rules. > > But you didn't. > > Nonsense... Your language's syntax parser is what defines > the rules. All of the expre

Re: Ruby parens-free function calls [was Re: Accessing parent objects]

On Monday, March 26, 2018 at 5:46:03 AM UTC-5, Steven D'Aprano wrote: > Rick, you're supposedly familiar with Ruby. And yet, you > didn't notice that your supposed "fix" didn't touch any > executable code, all it did was modify the strings being > printed. Because the goal was to *UN-OBFUSCATE*

Re: Ruby parens-free function calls [was Re: Accessing parent objects]

On Sunday, March 25, 2018 at 5:57:28 PM UTC-5, Steven D'Aprano wrote: > [supposed "fix" to the sample script snipped] > > You know Rick, every time I start to think that talking to > you like an adult might result in a productive and > intelligent conversation, you pull a stunt like this. Once >

Re: Accessing parent objects

On Sunday, March 25, 2018 at 9:52:30 AM UTC-5, Steven D'Aprano wrote: > On Sun, 25 Mar 2018 04:49:21 -0700, Rick Johnson wrote: [...] > But refusing to use super in modern, new-style classes that > don't have anything to do with tkinter is precisely the > sort of *foolish* consistency

Re: Accessing parent objects

On Sunday, March 25, 2018 at 10:02:20 AM UTC-5, Jugurtha Hadjar wrote: [...] > Furthermore, the only case I'd use a positional argument is > if I were 100% certain the code will not change, which I'm > not. And short of you possessing a crystal ball in good working order (mine's currently in the

Re: Ruby parens-free function calls [was Re: Accessing parent objects]

On Sunday, March 25, 2018 at 9:11:35 AM UTC-5, Steven D'Aprano wrote: > On Sun, 25 Mar 2018 04:49:21 -0700, Rick Johnson wrote: [...] > I never said anything about not allowing it. But since > you've gone on the defence about parens-free function > calls, how is this for "con

Re: Accessing parent objects

On Saturday, March 24, 2018 at 11:31:38 PM UTC-5, Steven D'Aprano wrote: > On Sat, 24 Mar 2018 20:08:47 -0700, Rick Johnson wrote: [...] > > > > the inconsistency of using super _outside_ of Tkinter code > > whilst simultaneously using explicit inheritance _inside_ >

Re: Accessing parent objects

On Saturday, March 24, 2018 at 9:29:02 PM UTC-5, Chris Angelico wrote: > So tell me, how do these other (beautifully intuitive) > languages handle multiple inheritance? I'm sure it's really > easy to make super() work when there's exactly one > superclass that you can lock in at compile time.

Re: Accessing parent objects

On Saturday, March 24, 2018 at 6:57:29 PM UTC-5, Steven D'Aprano wrote: > There's nothing wrong with super() in Python 2. You just > have to understand what you're doing. It's still the right > solution for doing inheritance the right way. The problem is, Python's super is not intuitive. And i'd

Re: Accessing parent objects

On Saturday, March 24, 2018 at 1:20:24 PM UTC-5, D'Arcy Cain wrote: > I'm not even sure how to describe what I am trying to do > which perhaps indicates that what I am trying to do is the > wrong solution to my problem in the first place but let me > give it a shot. Look at the following code. >

Re: Modules

On Wednesday, March 21, 2018 at 7:49:42 PM UTC-5, Jacques Bikoundou wrote: > It said: ImportError: no module named 'speedml' I see. And did you check the search path[1] to ensure that the modules you want to import are indeed located in a directory which python normally searches? As an academic

Re: Want to convert the msg file in html file so that i can read the tables emebedded in msg file using python

On Wednesday, March 21, 2018 at 5:15:47 AM UTC-5, gurpreet...@gmail.com wrote: > TITLE: "Want to convert the msg file in html file so that i > can read the tables emebedded in msg file using python" My guess that the OP meant to say: "msg file *INTO* html file" -- where "msg file" is a file

Re: Modules

Hmm, let's try a little interactive session, shall we? Did your error message look something like this? >>> import spam Traceback (most recent call last): File "", line 1, in import spam ImportError: No module named spam >>> import eggs Traceback

Re: [OT] Re: Thank you Python community!

On Tuesday, March 20, 2018 at 7:03:11 AM UTC-5, Adriaan Renting wrote: (on the subject of the opioid epidemic) > That sounds more like a conspiracy theory than a real > analysis of the problem. Looking at it from here in > Europe, most of the analysis I've been able to read and > watch about

Re: Style Q: Instance variables defined outside of __init__

On Tuesday, March 20, 2018 at 1:43:39 AM UTC-5, Terry Reedy wrote: [...] > > class Card(): > > > > BACK_OF_CARD_IMAGE = pygame.image.load('images/backOfCard.png') > > > > def __init__(self, window, name, suit, value): > > self.window = window > > self.suit = suit > >

Re: Style Q: Instance variables defined outside of __init__

On Tuesday, March 20, 2018 at 6:14:34 AM UTC-5, Alister wrote: > On Tue, 20 Mar 2018 08:52:29 +, Steven D'Aprano wrote: > > On Tue, 20 Mar 2018 02:43:13 -0400, Terry Reedy wrote: > > > > > I think a claim that in all programs all attributes > > > should be set *in* __init__, as opposed to

Re: Thank you Python community!

On Monday, March 19, 2018 at 6:37:21 PM UTC-5, Ben Finney wrote: > -- > \ "Success is going from one failure to the next without a loss | > `\ of enthusiasm." -- Winston Churchill | > _o__) | >

Re: RFC: Proposal: Deterministic Object Destruction

On Thursday, March 1, 2018 at 10:13:51 PM UTC-6, Steven D'Aprano wrote: [...] > And for the record, consider a tree of nodes, where each > node points back at the root of the tree, which is also a > node. So what does the root node point back at? Finally! A practical solution is offered that

Re: RFC: Proposal: Deterministic Object Destruction

On Thursday, March 1, 2018 at 6:10:45 PM UTC-6, Chris Angelico wrote: > On Fri, Mar 2, 2018 at 10:58 AM, Rick Johnson > <rantingrickjohn...@gmail.com> wrote: > > I don't buy into the religion that _all_ CRs are evil. Those > > who make such claims are dealing in absolu

Re: RFC: Proposal: Deterministic Object Destruction

On Thursday, March 1, 2018 at 1:54:40 AM UTC-6, Serhiy Storchaka wrote: [...] > Every global function (or method of global class) creates a > reference cycle. > > def f(): pass > > f.__globals__['f'] is f (Note: This is also a response to dieter) This is true, but it does not answer

Re: RFC: Proposal: Deterministic Object Destruction

On Wednesday, February 28, 2018 at 11:44:39 PM UTC-6, Paul Rubin wrote: > Rick Johnson <rantingrickjohn...@gmail.com> writes: > > Can you provide a real world example in which you need an > > object which circularly references _itself_? > > DOM trees are a classic e

Re: RFC: Proposal: Deterministic Object Destruction

On Wednesday, February 28, 2018 at 10:26:26 PM UTC-6, Steven D'Aprano wrote: > On Wed, 28 Feb 2018 18:46:05 -0800, Rick Johnson wrote: > > > On Wednesday, February 28, 2018 at 5:02:17 PM UTC-6, Chris Angelico > > wrote: > > > >> Here's one example: reference

Re: RFC: Proposal: Deterministic Object Destruction

On Wednesday, February 28, 2018 at 10:03:56 PM UTC-6, ROGER GRAYDON CHRISTMAN wrote: [...] > If you want something that looks like a real world example, > consider the very common doubly-linked list: > > [ 1 ] <---> [ 2 ] <---> [ 3 ] <--.--> [ N ] > > This is chock-full of reference

Re: RFC: Proposal: Deterministic Object Destruction

On Wednesday, February 28, 2018 at 9:00:37 PM UTC-6, Chris Angelico wrote: > On Thu, Mar 1, 2018 at 1:46 PM, Rick Johnson > <rantingrickjohn...@gmail.com> wrote: > > On Wednesday, February 28, 2018 at 5:02:17 PM UTC-6, Chris Angelico wrote: > > > >> Here's one e

Re: RFC: Proposal: Deterministic Object Destruction

On Wednesday, February 28, 2018 at 5:50:53 PM UTC-6, Steven D'Aprano wrote: > On Wed, 28 Feb 2018 14:51:09 -0800, ooomzay wrote: > > > > [...] > > > > Specification > > = > > > > When the last reference to an object goes out of scope the > > intepreter must synchronously, in the

Re: RFC: Proposal: Deterministic Object Destruction

On Wednesday, February 28, 2018 at 5:02:17 PM UTC-6, Chris Angelico wrote: > Here's one example: reference cycles. When do they get detected? > Taking a really simple situation: > > class Foo: > def __init__(self): > self.self = self *shudders* Can you provide a real world example

Re: Detection of ultrasonic side channels in mobile devices with Python?

On Wednesday, February 28, 2018 at 4:34:11 PM UTC-6, Etienne Robillard wrote: > A great number of studies have shown that ultrasonic > neuromodulation of the central nervous system can be > exploited via brain-computer interfaces... It is cutting > edge science however, and my knowledge on

Re: help me ?

On Tuesday, February 27, 2018 at 12:56:52 PM UTC-6, Grant Edwards wrote: [...] > The fun part is giving them a solution that's so obscure and "clever" > that it technically meets the stated requirement but is so far from > what the instructor wanted that they don't get credit for it (and > there's

Re: Are the critiques in "All the things I hate about Python" valid?

On Tuesday, February 20, 2018 at 5:45:36 PM UTC-6, Steven D'Aprano wrote: > On Tue, 20 Feb 2018 12:42:23 -0800, Rick Johnson wrote: > > > For instance, if the age is queried many times a second, > > it would be a much wiser design to set-up an event that > > will ad

Re: Is there are good DRY fix for this painful design pattern?

On Monday, February 26, 2018 at 5:44:18 PM UTC-6, MRAB wrote: [...] > Before using or'd-logic, you need to know whether the value > could be falsey, e.g. 0. True. However. Steven failed to provide any info that might help us determine the types of these parameters, and as such, i was forced to

Re: Is there are good DRY fix for this painful design pattern?

On Monday, February 26, 2018 at 8:44:14 AM UTC-6, Steven D'Aprano wrote: > I have a class with a large number of parameters (about > ten) assigned in `__init__`. The class then has a number of > methods which accept *optional* arguments with the same > names as the constructor/initialiser

Re: How to make Python run as fast (or faster) than Julia

On Monday, February 26, 2018 at 4:39:22 AM UTC-6, Steven D'Aprano wrote: > On Sun, 25 Feb 2018 19:26:12 -0800, Rick Johnson wrote: > > > On Friday, February 23, 2018 at 8:48:55 PM UTC-6, Steven D'Aprano wrote: > > [...] > > > Take the Fibonacci double-recursion benchmar

Re: How to make Python run as fast (or faster) than Julia

On Monday, February 26, 2018 at 3:59:40 AM UTC-6, Steven D'Aprano wrote: > On Sun, 25 Feb 2018 20:22:17 -0800, Rick Johnson wrote: > (We tried painting Go Faster stripes on the server, and it > didn't work.) Well of course the server won't work after you drip water- based paint

Re: How to make Python run as fast (or faster) than Julia

On Sunday, February 25, 2018 at 10:35:29 PM UTC-6, Steven D'Aprano wrote: [...] > Ah, you mean just like the way things were in Python 1.0 > through 2.1? Hands up anyone who has seen an integer > OverflowError in the last 10 years? Anyone? I think Python2.1 is much older than 10 years, so yeah,

Re: How to make Python run as fast (or faster) than Julia

On Sunday, February 25, 2018 at 8:45:56 PM UTC-6, Chris Angelico wrote: > On Mon, Feb 26, 2018 at 1:33 PM, Rick Johnson > <rantingrickjohn...@gmail.com> wrote: [...] > > A default "integer-diversity-and-inclusivity-doctrine" is > > all fine and dandy by me, (H

Re: How to make Python run as fast (or faster) than Julia

On Sunday, February 25, 2018 at 8:45:56 PM UTC-6, Chris Angelico wrote: > On Mon, Feb 26, 2018 at 1:33 PM, Rick Johnson [...] > > but i do wish we pythonistas had a method to turn off this > > (and other) cycle burning "features" -- you know -- in the > > 9

Re: How to make Python run as fast (or faster) than Julia

On Friday, February 23, 2018 at 8:48:55 PM UTC-6, Steven D'Aprano wrote: [...] > Take the Fibonacci double-recursion benchmark. Okay, it > tests how well your language does at making millions of > function calls. Why? Because making "millons of function calls" is what software *DOES*! Granted,

Re: How to make Python run as fast (or faster) than Julia

On Friday, February 23, 2018 at 10:41:45 AM UTC-6, Steven D'Aprano wrote: [...] > There are dozens of languages that have made the design > choice to limit their default integers to 16- 32- or 64-bit > fixed size, and let the user worry about overflow. Bart, > why does it upset you so that Python

  1   2   3   4   5   6   7   8   9   10   >