PDA

View Full Version : Python 2.x or 3.x?



Gorbag
05-31-2012, 09:44 AM
Just an informal gathering of opinions. Nothing binding here.

Matt
05-31-2012, 12:18 PM
I honestly don't give a crap.

But also many people do 'give a crap'.


The C-SDK with C++ is still the most powerful option and the Python option will never beat it on speed and likely not on access either.

Python has as much access as the SDK actually.


lscript was never used for major projects!

Not true, there have been many huge LScript based projects.


PS. Opinions should be backed up by argument(s), not simply stated. Opinions hold no value if they are not shown to be based on some understanding.

Agreed, see above.

Chuck
05-31-2012, 12:28 PM
The off-topic and inappropriate post has been removed. Folks, stay on topic, and if you do not have an interest in Python scripting, your commentary here is not needed. There are other areas and other threads for your topics of interest, and you are welcome to participate in those and enjoy them.

probiner
05-31-2012, 01:02 PM
:foreheads

I actually got a silly question relating to python.

How strange/hard would it be to pick a simple Blender plugin, and transform it to LW?

Different commands and Coordinates only or a completely different thing?

djlithium
05-31-2012, 01:04 PM
I would love to learn python, but im not so much of a coding kind of kat - but I would like to try and learn it.

And whoever said Lscript was never used on major productions is greatly mis-informed and majorly missing out on how awesome Lscript really is. Luke, Alexx(EWJ), Petter all wrote and modified tools for use in lscript for Iron SKy worked great and used them constantly to make our lives easier.
I used a whole tonne of lscripts on wardevil and BSG, CArgo and just about every other show I've done including the one im on now.

Don't knock lscript! :)

evenflcw
05-31-2012, 03:25 PM
It was me! And I'd like to apologize for the attitude that my post clearly conveyed. Just one paragraph to clear things up, then I'll shut up about what was said.

Kat, I was not speaking of projects as in media productions, but projects as in software projects, specifically the size and complexity of most lscripts. Had I been quoted fully, you'd also have read "with few exceptions". Those exceptions including the likes of Janus, Maestro and Passport. Considering the total amount of lscripts, the likes of those are very rare, to my public eyes atleast. These major lscripts also only popped up quite late in the game. Most lscripts are a fraction of their size and complexity. But these are the types of tools I think we'll be seeing more of in Python (than we did in lscript) as it provides much easier and better handling of large data amounts. Not everyone has the coding stamina and ingenuity of Lernie et al to push lscript as far as they did.

For the record, my LW use, when I get the time (hobbyist), nowadays consist to 95% of scripting and coding tools. My tendency towards these things should be evident from my forum presence and many fogbugz, if not by the things I've made publicly available (also only a fraction).

Back on topic. I DO "give a crap" about about Python! Introducing a modern widespread scripting/programming language, in lieu of proprietary old lscript, was one of Cores best moves! What I meant was I couldn't see 2.x or 3.x making a great practical difference. I have used lscript in the past whenever the C/C++ route did not provide much of a speed advantage, to achieve platform independence with no effort and whenever I felt lscript would just be faster to write. Primarily what was needed to take Lightwave scripting to the next plateau was better data handling (structs/objects and pointer/references). This is achieved with Python 2.x and much much more! If I know I can achieve what I need with already available 2.x, I see no reason to hurry an implementation of 3.x (that I cannot help but assume will take time away from other things I might deem more crucial)! That is to say, I don't care which, as long as I have one of them. If we would get both(!) I'd honestly be very happy about that. Not because I would feel more empowered, but because it would mean I could practice 3.x coding LW tools! This is how I learned to programming in the first place - using lscript to write tools for my favourite 3d program - I could not think of a more motivating and fun way to start programming or to learn a new language (version)!

So, in short, if NT has the manpower and time, by all means, go ahead! I just don't believe it will make much of a difference as 2.x is already powerful enough (for me). One could draw parallels to the bloat in Modeler of very many similar tools, each working slightly differently, but none providing any clear advantage over the other.

I hope I did not come across as rude again.

Gorbag
05-31-2012, 04:09 PM
:foreheads

I actually got a silly question relating to python.

How strange/hard would it be to pick a simple Blender plugin, and transform it to LW?

Different commands and Coordinates only or a completely different thing?

The Python-specific language elements would probably be fairly easy. The main difference will likely be in the underlying SDK that the scripts use. This will probably manifest in two ways: First, how you get information or perform actions (the actual interface to the SDK); second, procedural things like "How do I load an object?" or "How do I write a plug-in for <blender/lightwave>?", which are the things the SDK itself provides (its "idiom").

For example, to create a plug-in for LightWave using LightWave's Python, you create a Python class that inherits from a pre-defined "interface" class specific to a LightWave plug-in architecture, and provide overrides for those inherited methods. I would imagine Blender does something similar (I'm not familiar with its plug-in API), but might do things in a slightly different fashion.

I don't imagine the task would be too difficult, especially if you are somewhat familiar with the approaches used in both applications.

BigHache
06-03-2012, 02:43 PM
A good question, and a tough one too I think. Celshader left a comment on one of my Python videos about LW's Python version that I think is very valid, being production houses are probably still using 2.x. While the idea of yay using Python 3.x is nice, does it make sense?

So to answer a question with a question before casting vote, would it be possible to support both via a version dropdown in the Console and a hashtag in .py files? Or would that just be crazy stupid silly?

I guess I have two questions then. Instead of looking forward to Python 3.x, would the hours better be spent fully implementing Python? Please correct me if I'm wrong but I don't think Python can access everything the C/C++ plug-ins can? If this is still correct, this part would be my vote personally.

evenflcw
06-03-2012, 03:04 PM
I'm assuming/hoping they could do something similar as in lscript were you just write the minimum version requirements (ie the version pragma; similar to a hashtag). If they simply swap one (2.x) for the other (3.x), that would not be as good, seeing as many know 2.x already.

PS. "foreseeable future" for me is about 1.5-2 years from now, which I assume will bring us well into LW 12 or 13.

BigHache
06-06-2012, 01:02 PM
Yes this what I'm thinking too.

Celshader
06-26-2012, 10:06 PM
A good question, and a tough one too I think. Celshader left a comment on one of my Python videos about LW's Python version that I think is very valid, being production houses are probably still using 2.x. While the idea of yay using Python 3.x is nice, does it make sense?

The only package I know off the top of my head that offers Python 3.x support at this time is Digital Fusion. All of the others I've used in production (RealFlow, Poser, Maya) are still on Python 2.x. I would not mind seeing Python 3.x support in addition to Python 2.x support, but it would be awkward to jump between packages in a pipeline if LightWave lost Python 2.x support.

If possible, I would like to see some built-in functions added to LightWave's Python that return lists and dictionaries of items and attributes. I'm used to this kind of workflow with other packages' Python implementations, and right now I have to roll my own (http://forums.newtek.com/showthread.php?t=127883).

I would also like to see more LightWave Python documentation and examples. What little I have written in LightWave Python so far has only been made possible with the assistance (http://forums.newtek.com/showthread.php?t=127194) of others on this forum and elsewhere. LightWave Python might be easy and intuitive for those already familiar with the LightWave SDK, but it's been an uphill battle for me.