Would you like to see a SAMP Python tutorial?
#1

Hi everyone,

I'm using the excellent Python plugin by Fabsch which I modified slightly to be compatible with recent versions of SAMP and some other stuff.

Would you guys be interested if I write a SAMP Python tutorial? It would also show some interesting Python things like SQLAlchemy for user database management, requests to view and manipulate APIs, potentially some Flask as well to make an example API and possibly a small leaderboard or something?

If you have ideas, feel free to post them below, I'd like this to be about things that you want to learn and not things that I want to teach

Thanks in advance!

PS: If you say "No.", please post a message saying why, thanks in advance
Reply
#2

Please state the benefits (other than learning the language).
Reply
#3

Sure. The main ideas are to easily get access to a lot of powerful libraries such as the ones I mentioned, being able to use readily-available development tools more easily as Pawn is a rather unknown programming language, ease development and debugging by using a faster to read/write language and its built-in reloading features to see your code edits in real time, and so much more.

In general, it kind of goes the other way around from what your interesting response suggests: the idea is that people either don't know programming at all and would have an easier time learning Python, or they already know programming in which case Python is easier to pick up - assuming they don't know it already - than having to deal with all of the intricacies, limits or even outright built-in flaws of the pawn language and VM in everyday development.

Oh, and one major difference with Python is that it can ACTUALLY land you a job in real life. (I know it, because it's my job...)

In any case, Python is far more powerful than pawn - you can do extremely complex things with only a few clear lines of code. For example, Python's ConfigParser is more powerful than dIni or even y_ini ever could be ; its JSON stdlib is extremely easy to use and allows much more flexibility than ini ever would.

That's not even mentioning the extremely powerful libraries I mentioned above such as requests, which is way easier to use than trying to do HTTP using pawn - also more reliable, and supports HTTPS. Still not convinced? See it for yourself.

EDIT: Also, IMHO doing that "just to learn the language" would be a waste of time, it's really at the bottom of my list of priorities. I'm just trying to make everyone's lives easier.

EDIT2: If you're still not convinced, here's a little excerpt from my code for loading a given vehicle from SQL:
Код:
def load_vehicle(car_id):
    car = session.query(Car).get(car_id)
    if not car:
        return
    vehicle_id = CreateVehicle(
        car.model,
        car.pos_x,
        car.pos_y,
        car.pos_z,
        car.rotation,
        car.color_1,
        car.color_2,
        -1,
    )
    vehicle_paintjobs[vehicle_id] = paintjob = car.paintjob
    ChangeVehiclePaintjob(vehicle_id, paintjob)
Notice the much easier syntax, and the very low amount of lines. Notice the dictionary structure that is being used to store the paintjob (could be an array for this specific case, but the point stands). Also notice the double assignation, which can't be done in pawn. This is only a few of the many features that makes your life easier and your development faster in Python.

And here is how I load all vehicles when the Python script starts:

Код:
def OnPyInit():
    for car in session.query(Car):
        load_vehicle(car.id)
For reference, in normal pawn + MySQL, you'd have to type "select id, model, pos_x, pos_y, pos_z, ... from cars" and then the whole mysql_store_result() thingy and mysql_fetch_row() etc etc... So much work for nothing.

Notice the use of a real iterator over the SQL results, which is a feature pawn doesn't have.

In any case, please keep in mind that I'm not here to argue about what makes Python good, but rather trying to see if the current community cares enough that it's worthwhile for me to make a tutorial.

EDIT3: You might want to go see the original plugin page and especially the "command processing" part. Notice how it's even easier than zcmd or ycmd.

EDIT4: TL ; DR: Python makes your life easier. Yes, there are MANY benefits, but you asked for it!
Reply
#4

Also one thing I'm now adding in the OP: please specify your reasons if you say "No."

(I'm looking at you Vince - you do great tutorials about MySQL, why wouldn't you want people to have access to a full ORM instead)
Reply
#5

Why use a slower language? Python is already slow by itself, calling functions from it will be even slower.
Yeah, maybe Python is more powerful and easier to code, but I'd rather use samp.js for async or Gamer_Z's EXE or something he implemented in C to write code for SAMP.

I wouldn't actually encourage people to write code for samp in Python, nevertheless, the plugin didn't see a post since 2012, is it even still working?

Bugs might occur and I'm afraid that no one will be able to fix them if Python ever became a thing on samp
Reply
#6

Python is actually at least as fast as pawn, since it also runs off bytecode on top of an interpreter. Calling pawn natives from Python doesn't actually cost more than the sheer overhead of a Python function call, which is rather cheap compared to all the optimizations you can do in Python and not in pawn (like, when people create an enum with 60 or 70 parameters and then fill a MAX_PLAYERS-sized array of this enum with zeroes? :P).

Also, it's worth noting what actually matters is code read/write speed, not execution: your time as a programmer is much more valuable than a few CPU cycles, especially as servers (physical or virtual) keep getting faster and faster. If you spend half the time debugging faulty code, then you can write twice as many features in the same timeframe, it's as simple as that.

Writing JS for SAMP could be interesting but it's not my focus - although if it works, all the better for people who would use it!

Writing C for SAMP would be a major PITA compared to Python - that's the reason the language exists in the first place, to abstract away memory management and other burdens.

About maintaining the plugin - well, I'm using it and maintaining it, already patched some of the missing natives for more recent SAMP versions, and now working on double-checking the threading code to make sure there is no race condition. If people think this tutorial would be useful, it goes without saying that I would immediately publish the modified Python plugin I'm using on GitHub, where anyone could fork the project if they please.

About bugs, I found none so far, and a major part of my production codebase is now using Python (and I'm actually migrating more and more of it every day). If any would arise, I am confident that I could find it and fix it, as I am already familiar with the plugin's C codebase.

Frankly, Fabsch did a fantastic work on this plugin, the code is extremely clear and well documented, the fact that his plugin still works in 2017 is already a clear proof that the quality of his code doesn't need to be questioned. One of the main reasons why I'm doing this poll is that I wouldn't want to see such great work go to waste, as it seems his original plugin went mostly unnoticed.

In any case, thanks for your honest opinion and constructive criticism - I hope I at least partly debunked the idea that it would be slower.
Reply
#7

Why not? I mean it's always nice to see something new. Sure.
Reply
#8

I see your point, I still would rather stick with JS if it was developed.

I'm afraid that the tutorial might be actually a waste of time, it might just be a small hub for post farmers temporarily until it sinks into history.


samphp, samp.js, samp shoebill, samp.NET
were all attempts to port the code, many of them the development discontinued.

I'm personally, although I support a lot js, would be afraid to port any of my code into it or any other language simply because I'm afraid that one day I'd have to face that the plugin doesn't work anymore and support for it doesn't exist.
(On the bright side, SAMP gets updates every few years, so it would take some time)

Besides that, many people have huge chunks of code already written in PAWN, rewriting it into other programming language is time consuming, and from the same reason people don't move on from Java, unless anyone is enthusiastic about Python or has spare time, people won't bother to rewrite logic and switch it into a new, simpler one.


One thing that you can do, is re-release the modified plugin and see if it gains support / (stars/forks) on github.
Reply
#9

Oh wow, an answer from ******, I am honored! (and a bit sad to see you vote no, TBH!)

Well to be honest, not only would the motivation boost have been nice, but I honestly wouldn't want to invest so much time and effort if people just won't use it. I expect there is a real reason why the original plugin didn't interest so many people, and if that reason still exists I might want to know about it before committing to this tutorial - or more accurately tutorial series, because as you noticed there might be a bunch of topics involved.

The code is under GPL, so yeah, I would have released it one day or another - but once again the tutorial is a good way to force my own hand instead of procrastinating my way out of this.

Okay, double assignments in Pawn are possible, noted. Frankly, with the language not being OO and usually needing several statements to get anything done, I rarely would have needed it so far. The sarcasm wasn't necessary however: not only did I already read through the implementer's guide as I experienced some weird issues back in the day, I'm mostly making a point about Python being good, not Pawn being bad.

Well, I didn't like ORMs myself, so I'm no exception to the rule. But then I discovered SQLAlchemy and my life changed forever. Rather than typing a TL; DR block of text explaining how it's good, I can only recommend you check it out yourself - I use it for work quite often, in all sorts of (sometimes extreme) situations, and it never failed me. In particular, I never had to type a single line of SQL that I couldn't make SQLAlchemy type for me instead.
The simple reason for that is that it started as a generic SQL abstraction library, and became an ORM later. Its ecosystem is wide, supports migrations through Alembic for production DBs so that you don't even type a single line of SQL when your database format evolves - in short, it's really great for actual work, when most SA-MP tools feel a bit clunky and incomplete.

To interface with the natives, I simply get them at startup in the AMX part of the plugin using the SDK's amx_FindNative function and keep a reference to each, and then I call them from the CPython part of the plugin? I don't see how that would be expensive. And even then, as mentioned, it's not a few nanoseconds that weight a lot in face of 2 hours of scratching head because of a stack/heap collision, or other fun stuff in pawn.

Quote:
Originally Posted by ******
That's just bad coding - bad coders will write bad code in any language.
Well that's the thing, there's the languages that encourage good coding, and the languages that don't. Python is a doer.

Python was simpler than pawn for me from the get-go. I had been coding pawn long before I picked up Python, and even longer before I made Python a job. I initially was a C/C++ openGL/ogre3D programmer, so people would think that I would be more naturally inclined to use a language that has a similar syntax... But no. Saving human time is just too important.

Quote:

You said you were debugging multi-threaded code, hows that GIL working out for you?

Hahaha, still not GIL-sectomized yet but be reassured, the interaction with the Python VM is threaded. I'm just making sure daemonized threads don't crash the VM or do other nasty stuff, and more generally doing a fuzz testing of the codebase to prevent surprises. Wouldn't want my DB socket thread to be killed before it's done emitting data, would I?

And also... sure, no concurrency for Python, but pawn doesn't even have threads or multiprocessing built-in, so...
Reply
#10

(Sorry for the double post, different recipient and long messages...)

@Kaperstone that's totally understandable, and I'm quite biased as not only I got familiar with the C codebase immediately to start tweaking it (missing PVars, can you imagine it's that old!) so I don't feel scared of the bugs, but also as ****** pointed I'm rather familiar with Python.

Also, I'm not suggesting people port their legacy codebase, that would indeed be a behemoth of a task. More of an easy way out when you don't have a way to do something in pawn and could easily do it in Python: someone wanted HTTPS with the native HTTP handler recently, and I was sad to tell him that it wouldn't work, when really in Python it would have been quite easy to do (and developing a C plugin just for this sounds silly).

That whole Java/Python debate is a different story really, and one that I'd really love to keep outside of this thread - but we can certainly discuss it more in-depth through PM if you want! Basically, Java has unbeatable corporate advantages that only .NET could (and is trying very hard) to match, for example when you're outsourcing development.

I will re-release the plugin at one point anyway, but the reason for this thread is simply for me to see if it's worth documenting it properly or not beforehand - otherwise, it would have been a quiet release without even a notice on the SA-MP forums, which BTW was the original plan before I just "came back".

EDIT: Thinking about it, it would also help that someone with a working Windows toolchain could compile the updated version of the plugin before I start writing anything, I don't feel like most people would be happy to do that themselves.
Reply
#11

Get cracking then!!!
Reply
#12

I would love a Python tutorial for scripting in samp, I personally am very experienced with Python but not so pawno so it'd help me get started using it for my server which just puts me in my paradise!
Reply
#13

Quote:
Originally Posted by lucius99
Посмотреть сообщение
I would love a Python tutorial for scripting in samp, I personally am very experienced with Python but not so pawno so it'd help me get started using it for my server which just puts me in my paradise!
Start by calling it PAWN!
Reply
#14

Isn't python a snake?

If you want to create it, then create it but if you get no satisfaction out of it, then don't.
Reply
#15

Quote:
Originally Posted by Hansrutger
Посмотреть сообщение
Isn't python a snake?

If you want to create it, then create it but if you get no satisfaction out of it, then don't.
haha really a creative answer!
Reply
#16

Yes yes yes yes!!!!!

Python got lot of built-in modules and it's awesome at data handling (Strings, Lists....)

also mind sending it to me? (The updated plugin)
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)