Python 3 angst 2016 edition


  • Winner of the 2016 Presidential Election

    @Maciejasjmj said in Python 3 angst 2016 edition:

    @Gurth what the hell do you think you're using, QBASIC?

    Anyway, it's probably better to cut off the middleman and get a cart with an assembler on it. Coding for C64 is mostly peeking and poking at memmapped registers anyway.

    C64: The system for peepers and creepers (jeepers!)


  • Discourse touched me in a no-no place

    @Maciejasjmj said in Python 3 angst 2016 edition:

    Coding for C64 is mostly peeking and poking at memmapped registers anyway.

    Warcraft 3 Orc Quotes – [00:31..07:02] 07:02
    — SmurfingSmurfer



  • @Maciejasjmj said in Python 3 angst 2016 edition:

    @Gurth what the hell do you think you're using, QBASIC?

    Let’s just say that I discovered Commodore BASIC to be even more rudimentary than I remembered it from the C64s and C128s my school friends had.

    Anyway, it's probably better to cut off the middleman and get a cart with an assembler on it. Coding for C64 is mostly peeking and poking at memmapped registers anyway.

    That’s pretty much the conclusion I drew too. Just clearing the screen takes a measurable amount of time if you do it through BASIC.



  • @Gurth said in Python 3 angst 2016 edition:

    That’s pretty much the conclusion I drew too. Just clearing the screen takes a measurable amount of time if you do it through BASIC.

    I coded in BASIC for my CASIO calculator during math class. The interpreter ran at like 3 instructions per second. Rendering a (very low res) Mandelbrot set took 30 minutes. Also all the variables were single letter and globally shared between all programs.

    I never quite managed to get my Super Mario Bros clone working.


  • Winner of the 2016 Presidential Election



  • @Onyx But he pulled a "Heh, you fat nerds must have no lives because you're criticizing me. Guess what? I didn't care about your criticism and enjoyed my life instead, take that, nerds." To me personally, that signals maximum vitriol.



  • @cartman82 I really liked the way my high school teacher taught it, which was theory/syntax broken up by exercises on those theories/syntax. Then, on Fridays, we'd do a no-pressure "coding challenge" where he hands us all a sheet of exercises and we would try to solve them within 30 minutes. You wouldn't be marked down for being slower, it was really just supposed to be a practice exercise to help the students get ready for our state-wide competitive coding league that tripled as a fun activity and teaching tool. There was also a 15-minute written quiz on coding concepts and spotting errors that would be given (which was also supposed to prepare you for the league). Almost everyone in the class was engaged, even if they weren't very good at programming and just wanted an elective.


  • area_pol

    @CrazyEyes said in Python 3 angst 2016 edition:

    I didn't care about you're criticism and enjoyed my life instead

    He cared about the criticism enough to write the response, so his point is wrong by definition :)



  • @gordonjcp said in Python 3 angst 2016 edition:

    @ScholRLEA said in Python 3 angst 2016 edition:

    This also explains the reversed 'server' and 'client' terminology, where the display is the server and the computers actually running the programs are the clients

    Why do you think that's "reversed"? You've got a client app that needs stuff done (in this case, drawing things on a screen), and you pass that work off to a server (the X server, that draws stuff on a screen) and hand a result back to the client.

    It's no different to how for example a web browser works.

    It is not reversed in terms of the technical operations, as I have already acknowledged, but it doesn't match most users' expectations of the roles - if only because most users are focused on the what they see in front of them as 'local' and the system away from them as 'remote', even though they are actually using the remote console.

    As djls45 said, most people - including most programmers - are primarily familiar with things like file servers and web servers, and as a result tend to associate 'client' with 'right in front of me' and 'server' with 'somewhere far away, or at least in some other room'. The X arrangement follows the correct usage, but seems reversed to most people because that misunderstanding.

    The old Unix Haters' Handbook even got it wrong, bitching about how X got it backwards - which is all the funnier because, as I said earlier, X wasn't really a Unix thing originally, and actually had significant competition in Unix circles (from NeWS and Display PostScript, among others) at the time the book was written.


  • Discourse touched me in a no-no place

    @ScholRLEA said in Python 3 angst 2016 edition:

    As djls45 said, most people - including most programmers - are primarily familiar with things like file servers and web servers, and as a result tend to associate 'client' with 'right in front of me' and 'server' with 'somewhere far away, or at least in some other room'.

    It makes a good way to detect people who think of computers as something magical, rather than as technological systems that just do what they're programmed to.


  • Grade A Premium Asshole

    @ScholRLEA
    isn't always the master that's a client and commands something, and the slave that's a server and executes it/retrieves data?



  • @gordonjcp said in Python 3 angst 2016 edition:

    You've got a client app that needs stuff done (in this case, drawing things on a screen), and you pass that work off to a server

    Calling that "work" seems misleading. Generally, we consider drawing stuff on screen an easy, if not trivial, task, as opposed to the program logic which is the hard part.

    And regardless, the whole "using a network protocol for a basic system API" thing is confusing, because it's so inconsistent with how the rest of the system works. There is no USB device server, or OpenGL server, or PCIe server, or stdout server, so why a graphics server?


  • kills Dumbledore

    @anonymous234 said in Python 3 angst 2016 edition:

    There is no USB device server, or OpenGL server, or PCIe server, or stdout server, so why a graphics server?

    Because Unix is stuck in the 70s where anything more than showing text on a screen needed a room sized computer?


  • area_pol

    Now they are starting to call it "compositor" instead of "server".



  • @Adynathos said in Python 3 angst 2016 edition:

    Now they are starting to call it "compositor" instead of "server".

    Well, that's a looooot less confusing. </sarcasm>


  • area_pol

    @HardwareGeek said in Python 3 angst 2016 edition:

    Well, that's a looooot less confusing. </sarcasm>

    It seems perfectly clear. Compositor because it composes the screen view out of windows.


  • area_pol

    It is rare when someone recognizes and fixes their WTF, but in this case it happened indeed - Zed Shaw's Python tutorial now uses Python 3.

    The 4th Edition of Learn Python The Hard Way now uses Python 3.6



  • @Adynathos said in Python 3 angst 2016 edition:

    It is rare when someone recognizes and fixes their WTF, but in this case it happened indeed - Zed Shaw's Python tutorial now uses Python 3.

    The 4th Edition of Learn Python The Hard Way now uses Python 3.6

    It's a cold day in Hell.


  • Discourse touched me in a no-no place

    @Maciejasjmj said in Python 3 angst 2016 edition:

    It's a cold day in Hell.

    Isn't that somewhere in Norway?


  • area_pol

    @dkf said in Python 3 angst 2016 edition:

    @Maciejasjmj said in Python 3 angst 2016 edition:

    It's a cold day in Hell.

    Isn't that somewhere in Norway?

    Theres one in Poland, it is also cold.


  • FoxDev

    @Maciejasjmj said in Python 3 angst 2016 edition:

    It's a cold day in Hell.

    Wet too:
    0_1487947412935_upload-67407efa-416f-41af-9ecc-c08f2df3a3e5

    Yes, I can see it'll warm up later.



  • Couldn't find a good thread to post this in so here have this:

    New features planned for Python 4.0

    With the release of Python 3.8 coming soon, the core development team has asked me to summarize our latest discussions on the new features planned for Python 4.0, codename "ouroboros: the snake will eat itself". This will be an exciting release and a significant milestone, many thanks to the hard work of over 100 contributors.

    • After heated debate on the mailing list, the 79-character line limit prescribed by PEP8 will be updated. IDE users all over the world will now be able to take advantage of their 30" ultra-wide 4K monitors, as the recommended line length will be increased to 89.5 characters (this was a compromise with the 100-character lobby, the decision being to split the difference).
    • All new libraries and standard lib modules must include the phrase "for humans" somewhere in their title.
    • Finally, a new string-type for the masses, Python 4.0 will feature "z-strings": C-style NULL terminated bytestrings. Just prefix your string like so, z'my string' and Python will automatically ensure it is NULL-terminated. Note: the new z-strings cannot be used with any of the existing APIs that take string arguments - they must first be decoded to unicode strings or cast to bytes.
    • Type-hinting has been extended to provide even fewer tangible benefits. This new and "nerfed" type hinting will be called type whispering.
    • Fuck it we're going to just vendor libuv to provide the event loop for Twisted asyncio.
    • You can now use the async keyword before every single other keyword in the Python language, and we encourage you to async do so. There's nothing wrong with cargo-culting some magic keywords all over the place -- you want to go fast, don't you?
    • In addition to namedtuple and dataclasses (3.7), Python 4.0 will include several new thousand line decorator-hacks to implement simple struct types.
    • The GIL has been removed.
    • Just kidding! Instead we've been focusing all our effort on making it easier to juggle multiple interpreter data-structures within a single thread. No, no, you can thank us later!
    • The bytes-vs-str thing kept many of us employed as we had convinced our companies they needed to upgrade to Python 3. In the same spirit, we are excited to announce that there will now be two int types -- int will be a 32-bit signed integer, and long will be a 64-bit signed integer. But before you say, "hey, they did that in Python 2!", we'd like to add that you can no longer use int anywhere, and will need to convert them all to long.
    • Based on the overwhelming success of the 2to3 utility, we plan to release a 3to4 tool that will automatically convert your code to utilize these exciting new features.

    With much sadness, the following features did not make the cut:

    • After attempting to rewrite portions of the interpreter with Rust, nobody could figure out how to disable the borrow-checker, so we gave up.
    • No switch statement (and yes, yes, I know you can use a dict to do dispatching).
    • concurrent.Pasts and concurrent.Present will not be merged in time for this release, but hey, we've got futures, haven't we?
    • Since nobody understands how twisted asyncio works, we are unable to offer any improvements at this time. The PSF now recommends all new projects to use gevent.
    • Unfortunately we will not be able to offer any improvements to the packaging "situation".

    We look forward to this release, and will do everything in our power to ensure it takes us several minor versions before it is even remotely usable.

    Take heart! Remember the python motto:

    What is dead can never die

    I found it quite amusing, anyway.


Log in to reply