blocks: hard to find 'str' ("Create text with") for a single string

[jaustin]

I'd like to be able to easily convert numbers to strings using blocks. Here's a simple example of a program where this would be useful

The 'create text with' block that exists currently has two inputs, and the hover text says "create text by joining together any number of items"

As the image of the block has two 'inputs' it is not clear that this block can also be used for a single item (although I agree 'any number of items' does clearly include one item!):

Using the 'gear' on the 'create text with' block you can achieve this

However, I think it would be much clearer to add another block, perhaps "Convert to text" and the "create text with" could be "Combine items into text" or similar?

@carlosperate thoughts?

[ntoll]

So the problem is this functionality is hard to find?

Playing devil's advocate here, if you know there's a difference between an integer and a string (and that you need to convert them) then you probably won't have much problem converting them with the block you yourself used (thus proving my point!). :-P

You could just do: for i in ['5', '4', '3', '2', '1'] which is far easier to express in blocks.

[jaustin]

Yea, the problem is exactly that it's hard to find, nothing else.

For your other point, see #40 ;)

FWIW - I actually initially said "bah, looks like I can't do this with blocks" and started filing that bug. Part way through filing when I went to generate a screenshot I found the 'create text with' and thought to try reducing it to one argument.

[ntoll]

Two things:

• The organisation is based upon Google Blockly's -- in that we're not deviating from the way they do it. They have done a huge amount of research and organised their blocks as a result of said research. To push back, I'd say it's simply because you're unfamiliar with the layout.

• It forced you to explore the blocks and you learned something new! That is a good thing and to be encouraged. ;-)

[jaustin]

I disagree on both points

1. in blockly you don't have such a need for stringifying things, as that happens implicitly: This program actually works... ...and the equivalent does on the micro:bit, but this doesn't:

2. I didn't have a good experience, I had a frustrating one, and I suspect I succeeded because I knew more than many kids.

I'm not sure if you're pushing back against change in general, or if you really think that adding a "convert to string" block is a problem.

To me, I see very little downside and a lot of upside to 'str' as a block. Other options would be to make 'scroll message' and 'say' not require 'str'

[ntoll]

Actually, that's a Python thing. The print function will display the result of a call to __repr__ if the __str__ magic method doesn't exist for the object. The solution would be to make display.scroll work in the same way. That means changing the API, but I believe this may be a helpful / useful thing to do.

tl;dr - make display.scroll work with __repr__.

[jaustin]

...if that's the right approach then I think it should apply to microbit.say() too.

However - do you really think adding a 'str' block is bad? Isn't 'str' a reasonably common and useful thing to be teaching people the existence of?

[ntoll]

WRT say... __repr__ is going to give you a text based representation of the object -- for a number it'll be something like "123", but for other things it'll be something unpronounceable such as "{'a': 1}". We need to flag this.

I'm not against a str block - I'm playing devil's advocate in that Blockly have already done a lot of research about how kids think about blocks and how best to present such blocks. The "create text with" block is the end result of such research.

I totally get your frustration though. But I believe the solution isn't perhaps to change the blocks, rather it's to change the scroll and say methods to work with __repr__ in the absence of __str__.

Does this make sense?

[jaustin]

Okay, I think we're on the same page.

Assuming (and I think it's a big assumption right now) __repr__ gets implemented for scroll and say, when else might people want to stringify? I still think just duplicating the existing "create text with" block and featuring a single input version as well as a dual input version would be a simple thing to try in a next round of feedback.

As to why that isn't there in 'plain' blockly: If you don't need a 'str' block (as you don't in Blockly) then seems reasonable that nobody will ever ask for one.

[ntoll]

Implementing __repr__ for scroll and say should be trivial. Perhaps radio.send is another candidate too.

If that covers all the functions that take strings then do we need the str block?

[ZanderBrown]

having to str() everything in a dynamic typed language has caused some confusion

[dpgeorge]

having to str() everything in a dynamic typed language has caused some confusion

Remember that Python is deliberately like this. Being dynamic means that it's better to be overly cautious with automatic casting, rather than casting at every possible opportunity. Just look at JavaScript for the alternative way to do it :)

That said, I think we had a discussion somewhere that display.scroll should act like the builtin print function. So it would make sense to operate with str/repr on the incoming argument to scroll.

But then note that display.show probably shouldn't have this behaviour because it already does lots of automatic casting on the intput arg: it could be a str (converted to iterable of chars), or Image (converted to an iterable of the single image), or general iterable.