v0.3.0?

[Tymewalk]

When do we want to release v0.3.0? And what do we want added before then?

[Tymewalk]

I know #42 is on the list, as well as resolving #49. Anything else I may have forgotten?

[Tymewalk]

Bumping this. Slither development has been dead for a while but I'm working on fixing that. See #58 for what I'm doing right now.

[Tymewalk]

So, #59 is having some problems that I'd like to fix by releasing 0.3.0.

Does anyone know of anything that should get done before then?

[skistaddy]

I believe #59 just got solved, so isn't 0.3.0 ready to release? Maybe add URL image support?

[Tymewalk]

I believe #59 just got solved, so isn't 0.3.0 ready to release?

Yeah, #59 was resolved, although that has nothing to do with making 0.3.0 ready to release (I originally wanted to release it so PyPi would stop complaining about the 0.2.x versions, but it's fine now.)

Maybe add URL image support?

What do you mean by that? Do you mean getting images from the web and adding them to a Slither project?

[skistaddy]

It would be the Same as adding a vector image, just through a URL.

[Tymewalk]

It would be the Same as adding a vector image, just through a URL.

I'm still confused. Do you want to get an image from a URL like "http://imagehost.com/blah"?

[skistaddy]

Yeah. So instead of using a file it uses a URL

[Tymewalk]

Yeah. So instead of using a file it uses a URL

Sounds cool, but couldn't that open up security vulnerabilites? I've heard of things being hidden in images and opening up every Slither script to something like that isn't good.

[skistaddy]

True. And Scratch doesn't support that either, so best not to add it.

[Tymewalk]

True. And Scratch doesn't support that either, so best not to add it.

I don't think that last part is true (although I'm not saying we should add this). Just because Scratch doesn't support something doesn't mean it shouldn't be added.

[skistaddy]

True. And Scratch doesn't support that either, so best not to add it.

I don't think that last part is true (although I'm not saying we should add this). Just because Scratch doesn't support something doesn't mean it shouldn't be added.

It is supposed to be a module for Scratch, yes?

[Tymewalk]

True. And Scratch doesn't support that either, so best not to add it.

I don't think that last part is true (although I'm not saying we should add this). Just because Scratch doesn't support something doesn't mean it shouldn't be added.

It is supposed to be a module for Scratch, yes?

Not really. It's supposed to bring Scratch-like features to Python. I also intend for it to make things in PyGame easier for beginners, and also take advantage of features in PyGame that don't exist in Scratch.

[skistaddy]

Aah. I see.

[Tymewalk]

Before 0.3.0 is ready we need some more features.

Mostly everything has already been added through 0.2.2 - collisions (#42, Pull: #61) are currently waiting approval.

I think that in 0.3.0 we need a few things.

Seeing which Scratch blocks to duplicate

Probably the biggest thing is making Scratch's functions available in Slither. The more of these we have, the easier it is to replicate Scratch projects in Slither.

I'm personally thinking about some form of click detection, keypresses (#60), and a "point towards" function.

Making it foolhardy(?)

Scratch has several checks to make sure programmers don't crash the program. All string fields are taken as just strings, text can't be entered in number areas, etc.

The problem is Python is a lot more vulnerable to these simple mistakes since we can't control things like that. I can write Sprite.direction = '90' without any form of warning whatsoever.

However, we also need to teach new programmers things like that in Python will break the program. So we need to discuss how we'll handle that. (Maybe an exception or warning like You tried to enter a string in an integer field?)

Convenience functions for PyGame

Cropping images, text printing (#62), etc.

Not much I can say here because this is something worked on only rather recently.

[BookOwl]

I think that a "point towards" function would be very useful. On making it foolhardy, we could change the descriptors to check the types of what's passed to it.

[Tymewalk]

@BookOwl Sounds good! But let's say this happens: Sprite.direction = '90'

What do we do then? I'd prefer to stay away from just simply converting to an int without saying anything, as this may mislead new users.

[BookOwl]

We can check if the argument is an int, and if not, we can throw a TypeError with a message like "str is an invalid type for direction, perhaps you meant to pass an int or a float?"

[BookOwl]

Also, I'm trying to get pygame working on my debian laptop now, so hopefully I can get some work done today.

[BookOwl]

42 was resolved with PR #61.

[Tymewalk]

60 was resolved with #64, and #65 was resolved with #66 (thanks, @BookOwl!)

[Tymewalk]

We can check if the argument is an int, and if not, we can throw a TypeError with a message like "str is an invalid type for direction, perhaps you meant to pass an int?"

Sounds good to me. This way Slither is more user-friendly when something goes wrong.

[skistaddy]

@Tymewalk for the sprite.Direction = '90' thing, couldn't you just convert the text automatically to an integer by using int()? Ik it would be good to give them an error, but stop the program?

[BookOwl]

Python in general doesn't do any automatic type conversions, I don't think that we should either.

[skistaddy]

M'kay.

[Tymewalk]

@BookOwl We'll still throw a warning/error, though, right?

[skistaddy]

Yeah. Probably stop the script too. (With sys.exit() I'm assuming.)

[Tymewalk]

@bjskistad Or something similar.

[skistaddy]

@Tymewalk Of course. :D You're the owner. I was making an assumption that that was what you were going to do. :D

[Tymewalk]

@bjskistad OK.

So here are a few examples.

Problem: Sprite.direction = '90' Solution: Sprite.direction only accepts int as input

Problem: Sprite.costumeName = 10 Solution: Sprite.costumeName only accepts strings as input, maybe you meant Sprite.costumeNumber?

Problem: Sprite.moveSteps(10, 29) (two arguments, not one) Solution: Sprite.moveSteps only accepts one argument, numSteps

What do you guys think?

[skistaddy]

Looks good!

[BookOwl]

@Tymewalk, your last example would already raise an error.

[Tymewalk]

@BookOwl Oh. I thought Python reported that differently.

Either way, I think this looks good. I'll create a separate issue for it soon.

[BookOwl]

Right now, the only two things that we have left before v0.3 is ready is #62 and #67. Is there anything else we want to add?

[Tymewalk]

@BookOwl Not that I can think of. In fact, 0.3 is actually closer than we think, since #67 has little to no effect on the actual code and #62 should be very simple.

[Tymewalk]

62 was resolved with #77 just now.

The only thing left would be #67, and even that doesn't really stop us.

Removing the "future" label as this is coming up very soon.

@bjskistad @BookOwl @Omegabyte @ethanhs @CosmicWebServices what do you guys think about releasing 0.3.0 soon?

[BookOwl]

I think that we just need to do #76 and we'll be ready! :shipit:

[Tymewalk]

Just fixed #76 in #78. Ready for release?

[BookOwl]

I think so!

[Tymewalk]

@BookOwl Wow, so many changes!

OK - I'm writing up the release now.

[Tymewalk]

It's done! All that's left is to release to PyPi.

[Tymewalk]

Released! Closing as this is done now. :grin: