Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×
Python Programming

Python 3.6 Released (python.org) 187

On Friday, more than a year after Python 3.5, core developers Elvis Pranskevichus and Yury Selivanov announced the release of version 3.6. An anonymous reader writes: InfoWorld describes the changes as async in more places, speed and memory usage improvements, and pluggable support for JITs, tracers, and debuggers. "Python 3.6 also provides support for DTrace and SystemTap, brings a secrets module to the standard library [to generate authentication tokens], introduces new string and number formats, and adds type annotations for variables. It also gives us easier methods to customize the creation of subclasses."
You can read Slashdot's interview with Python creator Guido van Rossum from 2013. I also remember an interview this July where Perl creator Larry Wall called Python "a pretty okay first language, with a tendency towards style enforcement, monoculture, and group-think...more interested in giving you one adequate way to do something than it is in giving you a workshop that you, the programmer, get to choose the best tool from." Anyone want to share their thoughts today about the future of Python?
This discussion has been archived. No new comments can be posted.

Python 3.6 Released

Comments Filter:
  • by bill_mcgonigle ( 4333 ) * on Saturday December 24, 2016 @10:45AM (#53548025) Homepage Journal

    Perl is great for people who tend to be more "verbal". The total math geeks I know really prefer python, though.

    It's wonderful that we have such a joyful abundance of tools to choose from in the FLOSS world, and aren't stuck running VB.net or whatever the craptastic commercial product is these days. Be maximally productive and we can all be happy for that.

    Now let's work on getting these things coordinated so I can use a python module in perl6 and the ruby folks can use a perl6 module on rails. That was one of the great dreams of the perl6 project and it doesn't seem to be effective yet.

    • by phantomfive ( 622387 ) on Saturday December 24, 2016 @02:26PM (#53548987) Journal

      The total math geeks I know really prefer python, though.

      That's because of the good math libraries available, it has nothing to do with the language itself. Remember R is popular among mathematicians, and from a language viewpoint, it's a crap language. Sometimes it's the right tool for the job, though.

      • R is an... interesting... language. Definitely lots of crappy points, but I think it's the closest that any language with a mainstream C-style syntax has come to being Lisp. In fact, arguably, R has exceeded Lisp in some ways - by making function arguments lazy, and making it possible to get the underlying expression if desired, it did away with the need for macros as a separate facility - it's just functions all the way.

        And literally everything in R is a function call. Including things like conditionals an

  • by LocoBurger ( 18797 ) on Saturday December 24, 2016 @11:39AM (#53548185) Homepage

    That summary is pretty inflammatory. "New Python: Also, some people say Python sucks!"

    What Larry sees as a virtue of Perl, the fact that it gives you myriad tools to accomplish your tasks, many see as over-complicating the matter. You can certainly do whatever you need to get done in Python (duh), but the Python folks pride themselves on giving you a good way. It's just a different approach to language design.

    A (possibly) overwhelming everything-and-the-kitchen sink? Or tools crafted by experts? Personally, I love Perl, but there really doesn't need to be this counter-productive contention between the different approaches.

    • That summary is pretty inflammatory.

      That was the intent... to start a religious war. Sort of like quoting the Pope as saying "Protestantism is a pretty okay primitive religion, better than being Muslim I guess"

      • Considering that the muslimes comsider Islam an more 'evolved' version of judaism and catolizism this is a pretty tough statement :)

  • by scorp1us ( 235526 ) on Saturday December 24, 2016 @02:43PM (#53549071) Journal

    Python 3.5 got async, await key words and has had proper OOP for a decade, things JS is still trying to get into the language. The one downfall of python is JSON object literals aren't as easy as in JS.

    If more node devs found out about Python's Tornado, they'd probably pick Tornado.

    • Before the apologists say you can use Babel, admittedly, you can, but, using such a tool is an admission of defeat. To compile something that is not true JS to something that is JS I would argue is not the original language. It's like using macros in assembly. It may seem pedantic, but pragmatically, Python runs _everywhere_ that C runs*. (Meaning your platform has a C compiler). Comparatively, using JSLint as an example, in order for JSLint to support a particular feature, it must be in two runtimes and a

    • The one downfall of python is JSON object literals aren't as easy as in JS.

      Dunno I don't really like the idea of having my communication protocol interpreted as code.

      • JSON can't be a protocol. It is a data format.
        On the other hand: every protocoll is code. Code that tells the 'other sode' in which state my side is, what action I expect from 'the other side' and in what state I will switch afterwards.
        Considering that, you can ofc. implement/represent the messages for the protocol in JSON, and then: it is code, and no longer data.
        Hint: read about a simple protocoll, e.g SMTP.

        • With json in python I am going to go:

          import json
          my_data = json.loads(message_contents)
          do_something_with(my_data['part_of_data'])

          Which is better than passing message_contents directly into my own interpreter and assuming it doesn't do something it shouldn't be doing.

          • So you don't know what your interpret is doing with JSON, even after you wrote it yourself?
            And "do_something_with" is not an interpreter?

            Hm ...

            • So you don't know what your interpret is doing with JSON, even after you wrote it yourself?

              Its a message from Dr Evil.

              And "do_something_with" is not an interpreter?

              It might be print(my_data)

      • You mistake eval() for JSON.parse()

        Both JS and python can eval(). Yeah, it's really stupid to eval() code. And you can do it in JS and it will usually give you an object (the times it doesn't are very interesting indeed!) But JSON.parse() is not eval. JSON.parse decodes a string into an object, which is data only.

        Similarly json.loads() takes a string and converts it to a dict.

        What I was getting at is really a minor quibble but it comes up a lot. var o = { this:1 that: 2} is much more friendly to write tha

        • Then in python you want a namespace object. Yes, python makes you declare a class for that, maybe not as convenient but you can do a lot more with a class than just put data in it.

  • Time to dump Python 3.x resume development on the 2.x branch. The ridiculous lack of backwards compatibility hurts far more than it helps.
  • by Sarusa ( 104047 ) on Saturday December 24, 2016 @05:20PM (#53549625)

    First, I know Javascript is wildly more popular as the language that runs everywhere, but it's not what most people use when they're writing a system / glue script - though some people do, they've got a hammer.

    Python's the utility / glue scripting language of choice precisely because it's READABLE - it doesn't have nine different ways to do everything like Perl does which makes it less expressive but more comprehensible and maintainable. You can definitely bang stuff out faster in Perl, but you can come back to the Python four years later and easily figure out what it's doing (just did that recently, fixed a large four year old 2.x script for new requirements and features and upgraded it to Python 3.x in a day, most of that testing), or grab someone else's Python and maintain it with reasonable effort unless they were seriously defective. Terrible programmers can write Perl in Python, and great programmers can write very maintainable code in Perl, but the language heavily skews the odds.

    Remember when Ruby briefly seemed like a contender for Python? Well, it was neat, and decent enough (I used it), but it had too many perlisms (punctuation vomit syntax) which made it similarly not so readable, and then all the magpies flew away to the next hotness and I went back to Python as more maintainable - and more capable because of the strong library support. And now Ruby is just 'That language you use for Rails'.

    Similarly, people like to bitch about the whitespace, but it forces readability. Perl people considered cramming 5 or more lines worth of Python on a single line a bragging point, and it was when vertical space was limited, but it's hell for readability and maintainability and we've got big monitors now. And if you have any code skills at all the whitespace is not a problem - I do Python, C#, C++, bash, Haskell, ASM, and VHDL - all wildly different, and the biggest problem is remembering how each does '# of items in a collection' (Count? count? Count()? Length? length? sizeof()?) - whitespace is not even on the radar.

    A more valid complaint is that Python has relentlessly marched towards cleaning itself up even if that breaks compatibility - it is not afraid to clean up terrible mistakes it has made (usually on new features) rather than leaving them in forever for compatibility reasons like bash has to. I know that's a big sticking point - it can be jarring when old code breaks, but locking old code you don't have the time to maintain to a specific version has worked pretty well for us. Mostly that's just segregating things as 2.x or 3.x. Code we have kept up to latest version has improved as a result as the language improves.

    Biggest weakness - the lack of compile time checks due to strong but dynamic typing continues to be an Achilles heel for any large project. Python (and other scripting languages) just aren't suited for that and we don't use it for that. Use something with static compile-time checking like C# or C++ - yes, after all my kvetching about readability we still use C++ for some things because nothing else fills its niche.

Pascal is not a high-level language. -- Steven Feiner

Working...