qquark

It seems like it tends to converge into infinite loops at some point. Example by directly inputting a repeated "What?", originally obtained with a different piece of initial text, and observed with other starts as well :) :

Prompt:

"What?"

"What?"

"What?"

"What?"

"What?"

"What?"

"What?"

Response:

Same

I suppose it's kind of GPT's game of life :)

A 180kW kettle ?! Great Scott !

This may be what you're looking form, to add a method to a single instance, although the syntax is clearly not as smooth: https://stackoverflow.com/questions/1887845/add-method-to-an...

OTOH, if your problem is slightly different, I find the syntax to add methods to any class very practical and powerful, with of course the caveat that you can produce a maintainability nightmare if overused:

  irb(main):001:0> a = 1
  => 1
  irb(main):002:0> class Integer
  irb(main):003:1>   def hello
  irb(main):004:2>     puts "world"
  irb(main):005:2>   end
  irb(main):006:1> end
  => :hello
  irb(main):007:0> a.hello
  world
  => nil

This is maybe not directly visible in the parent comment, and particularly not on the website, that is compatible with old versions of python also, but to me there's a huge difference in usability also in the ability to use variable names in the current scope without additional verbose crap by default. This seems secondary to a lot of people, but to me that changes everything:

  >>> x = 1
  >>> f"{x}"
  '1'

This is much more readable than:

  >>> "{x}".format(x=x)
  '1'

  >>> "{}".format(x)
  '1'

It makes the code immensely more readable than having to count parameters, especially for long strings with a lot of data in them. Counting is for computers, not programmers; I shouldn't have to count anything for such a trivial task.

So, thanks to f"", no need for what I find to be an ugly additional call to .format(...), that is just visual clutter for most cases.

The only reasons I could see for a call with a dedicated dict is data exfiltration from a user provided format string executed on python code they do not control, or renaming/subsetting of keywords for cleanliness. Both are special cases, and that's the effect the current implementation has, thankfully.

In case you didn't notice yet, it seems like the certificate of your website is expired (2019-04-10).

To be honest it just seems a bit like playing with words. Of course you can use "success" in sentences where it loses the meaning intended in the current context, but it seems clear to me that when someone writes "to be successful" there are implications that it means being successful on some measure that the author finds valuable or intends the reader to think valuable (in order to sell a book or something).

And of course people can argue all day about what is "being successful", since you could mostly put it as a matter of taste depending on what one finds satisfaction in, in life. It is indeed true that someone who doesn't have the same frame of reference for success as the author will have a harder time finding useful information in such a book/article, but that doesn't mean that because the measure of success can vary from person to person, it doesn't exist at all.

When such an article or book talks about that, there is a meaning behind those words that is conditioned by the cultural context in which it is used (as materialistic as it can be) and obviously this is pretty much never meant to be understood as "how to act as to be able to formulate statements that match 'I successfully did .*'", which is how this quote feels like to me...

When not too constrained by size and particularly for prototyping, I tend to use short descriptive names that are not too hard to decode. For example you could use Cby* for bypass capacitors, or maybe if you have a series of LEDs, then you could have Dr, Dg, Db* depending on their color, and similarly Rr, Rg, Rb* for their respective resistors, or Rpi* for I2C pull-up resistors, etc.

Sure you could have a look a the traces to find those out, but it's not always straightforward.

This makes a big difference when debugging boards IMO. For example now if you see that your blue LED is too bright again (as is usually the case ;)), you can just look for Rb* and fix it without the schematic.

I've been using enforce for this purpose (https://github.com/RussBaz/enforce). It provides decorators that enable type checking where wanted. This gives the advantage of migrating existing code to type checking at your own pace at least.

On a general note I've come across a few cases, when pushing python's type annotations to their limits, that force you to put the type names in string quotes, and that makes the whole thing feel like a hack. It's better than nothing for my use cases, but if I remember correctly both mypy and enforce have problems in common that are probably coming from the way python itself is built, such as self reference in a class definition.

> but it is very unclear how to do it with a distributed repository

Versioning through branching and tagging, while having some drawbacks - at least the fact that you have to DO an operation and that this is not automatic - seem to solve this problem, and are not, in my eyes, a form of monorepo. You globally get more flexibility at the cost of a bit more repo management work.

If the problem is retrieving the right version automatically, externals or submodules should be able to solve this problem. If A and B have no clear dependency direction, a top level repo might help.

Also being in France, I find that the most reliable and practical way to get something shipped is to use a "point relai" (when delivery at work is out of the picture because of company policies). Delivery services generally know better how to find them and deal with them, since other people use them too.

When your package is damaged, some will even offer to add a note to your delivery, without you asking, in case there's a problem later.

I order very regularly from Amazon, and I think I have never had a single problem receiving packages this way, and it's pretty easy to find one on your way from work or somewhere that suits you. Some of them are even open on Sunday, depending on what their main business is, very convenient ...

I think some answer might lie in the question of what the speaker is trying to accomplish by swearing.

If you think about it, why swearing instead of using standard words ? Putting aside "bad" habits (I put this into quotes because I don't think there is something inherently bad in swearing, it's just a subset of vocabulary data being transmitted to convey information ;) ), I would say that that goal is, subconsciously or not, to increase the emotional impact of what is being said. This will to increase the emotional impact can stem from the speaker's own emotional state, that needs to be expressed through speaking. This might be for lack of better words in one's vocabulary, "accessibility", perceived "style", etc.

The person is stating something, that might be originally emotionally weak or neutral, but by swearing, he emphasizes the emotion associated to those words or sentences, and thus has the opportunity to convey an additional specific type of information, in a specific way.

I would even say that swearing might be even difficult to replace in some cases where the intended effect is to be casual, or maybe to sound "cool" to a certain crowd while keeping this emotional effect. This might, in a way, be considered "manipulation" if done consciously.

And I think this logic applies very well to Trump particularly, because appealing to people emotions seems to be mostly what put him in office. Rather than trying to win by giving the population high logic on the reasons why he should be elected, he is going the other way: make them feel things that put him under the spotlight as a good contender for the position of president ...

A side note: a lot of "newer" HDDs (< 15 years I guess ?) now have ceramic/glass platters that break instead of bending, so be careful if trying this to avoid hurting yourself.

Interestingly enough, the function def (the exec part) does not work in 3.6, as one could expect, but in 2.7 even though the function definition works, you can make the call fail by generating actual parameters:

  >>> exec("def f(" + ",".join("f" + str(x) for x in range(300)) + "): print(f299)")
  >>> f(*range(300))
  299
  >>> exec("f(" + ", ".join(str(i) for i in range(300)) + ")")
  Traceback (most recent call last):
    File "<stdin>", line 1, in <module>
    File "<string>", line 1
  SyntaxError: more than 255 arguments

When reducing the number of parameters to be invalid for f, the following error is shown:

  >>> exec("f(" + ", ".join(str(i) for i in range(30)) + ")")
  Traceback (most recent call last):
    File "<stdin>", line 1, in <module>
    File "<string>", line 1, in <module>
  TypeError: f() takes exactly 300 arguments (30 given)

Which seems a bit paradoxical - "You need 300 arguments" - "No, wait, actually, you can't have more than 255" ... ;)

It looks like they either had changed the internals of python 3, making it fail at the definition as a side effect instead of when calling, or used the same underlying logic but purposely chose to issue the exception to potentially catch the problem earlier...

I see, I thought you meant the opposite because I had a hard time finding a good replacement myself. I think I tried the 3 others you mentioned and didn't find them suitable to my preferences at the time either.

> - reader -> feedbin. Yeah, as if I had a proper choice.

I don't know about feedbin, but if you're looking for an alternative to reader, inoreader works reasonably well, and doesn't feel like it is missing too many features.

You could argue, using the same logic, that when using {} languages, the computer can serve you by automatically doing the indentation anyway. This is the case in practice: I never have to worry about indenting my code in C, as support for that in most editors is great.

{} languages have the advantage of allowing you an immediate restyling of the code when the original author (who can be of varying skill level) wrote something you don't like looking at, or when you want to change the style of your own code for various reasons.

I find that Python-style blocks generally cause me more mild annoyances than {} blocks. A frequent thing that happens is copy-pasting/moving a line from some place to another with a different depth: In C, I paste and run my automatic indentation, while in python I have to specify manually by how much I want to indent my new code so that it can know within which block I want it. ... And it's not like you could do so automatically: if I want to paste something after the code of an "if ...:" block, the editor cannot know if I want it inside or outside the block.

On a more abstract level, I personally prefer a language where the end of a block is explicitly specified by the presence of a visible character rather than by the absence of an (arguably) invisible one, and where the form of the code does not affect its function in any way...

I'm not trying to argue that much against the python logic though, because the potential for disastrous style is indeed limited, it has its specific advantages, but I don't think delimiter-based languages can be qualified as more primitive just because of this.

... Which, despite what I imagine is an incredible amount of effort on their part, struggles to run acceptably not even half the software you throw at it ...

Wine is unfortunately not a reliable solution for a huge number of tasks mostly populated by windows-only software (e.g. professional CAD & PCB software - and no, open source "alternatives" in those domains are NOT able to compete, which is perfectly understandable IMO). Even when you get something running, you get locked out of updates because the next version of your software might not work anymore.

When you insist on running those on a Linux system, it becomes better just running a dedicated VM, but you can then kiss goodbye to performance on 3D rendering for example...

It seems obvious to me that running windows apps flawlessly on linux is something Microsoft absolutely does not want: The migration path to a Linux-only environment and native apps would become incredibly more simple, and they would probably lose market share overall... I definitely know I would eliminate it in a heartbeat if I could.