111–120 of 264 posts
Open page. Nothing works. Enable their scripts. First slide shows but nothing works - except the link to the pdf version. Why not give a link to the pdf version in a element?
Please stop. Thanks.
Earlier quoted context omitted.
Of those, only the async I/O stuff seems compelling. But compelling it is, at least as used in Curio. It feels like this is still shaking out, with the standard library and Trio (?) alternatives, but it looks really cool.
If you work with international users full unicode support is very compelling.
Asyncio is the most important feature of 3.5+ imo. I'm not sure why this is buried at #8.
Earlier quoted context omitted.
Python 3 came about with a split in the community.
what is the split that has to do with 2vs3? Really it just seems like some devs are still griping about fairly minor backwards compatibility issues. the whole print vs print() is obviously a straw man. but the major one, strings, unicode, and bytes, changes for the good in py3. the fact that people have to go back and "un-hack" their code is time, effort, and more commits but it's for the best. i think the real split…
The split you mention is real, but it's existed even longer than the 2vs3 split. All the various alternate Python implementations that have come and gone or are still around with the exception of Numba were started pre-3k. I wouldn't even argue that upstream was necessarily wrong not to prioritize performance and more specific use cases (like certain production uses, or scientific uses (a lot of begging to finally get the @ operator)), it just didn't matter as much for a long time. But things are different now. There are many other very expressive and much faster (either dynamically typed or static) languages in competition that lessen Python's effectiveness at reducing dev time in exchange for more hardware. Without a more serious focus on performance, Python will be driven only by momentum. That can last a long time, and is essentially the end point anyway when performance is "good enough" compared to the close alternatives, but it's not a great look when there's still much that could be done.
I did not know you could append to a Path via "/", but that's really awesome! I also really love working with generators when I write Python. They are just such a simple idea that's very powerful and I miss them so much when I go back to javascript (I know javascript has them now, but I haven't written them, and they don't look as fluent as Python 3, where the large parts of the language design is based around them).
Overloading operators for cute purposes is usually a misfeature. There was a fad for this in the early C++ days. I once wrote a marshalling library which overloaded "||", so that you could write p = stream || rec.a || rec.b || rec.c; and get an object which, if written, marshalled the record, and if read, unmarshalled it. The marshalling order was only specified once. Cute, but in retrospect, bad. Python's classic ov…
Earlier quoted context omitted.
This piece barely scratches the surface, there's formatted string literals, type checking available, and compact ordered dicts by default in the latest. All awesomeness. I'm glad they did the "mediocre" fixes as well, they lead to a lot fewer encoding (and other) bugs, which were a real problem on nontrivial programs.
Type checking is given in the piece. Compact dicts are nice for memory performance, but I don't use Python for performance. Ordered dicts I only care about rarely and explicitly use one in such cases. Formatted string literals have not really been a "feature" but a concern. The original plan was to get rid of the % way of formatting and just use .format with __format__ (except now there are pitfalls and inconsistenci…
I've found ordered dicts useful on a lot of projects, more than I'd have predicted in advance however.
nonlocal is another overdue fix.
Earlier quoted context omitted.
This piece barely scratches the surface, there's formatted string literals, type checking available, and compact ordered dicts by default in the latest. All awesomeness. I'm glad they did the "mediocre" fixes as well, they lead to a lot fewer encoding (and other) bugs, which were a real problem on nontrivial programs.
Type checking is given in the piece. Compact dicts are nice for memory performance, but I don't use Python for performance. Ordered dicts I only care about rarely and explicitly use one in such cases. Formatted string literals have not really been a "feature" but a concern. The original plan was to get rid of the % way of formatting and just use .format with __format__ (except now there are pitfalls and inconsistenci…
Earlier quoted context omitted.
Overloading operators for cute purposes is usually a misfeature. There was a fad for this in the early C++ days. I once wrote a marshalling library which overloaded "||", so that you could write p = stream || rec.a || rec.b || rec.c; and get an object which, if written, marshalled the record, and if read, unmarshalled it. The marshalling order was only specified once. Cute, but in retrospect, bad. Python's classic ov…
Another approach taken in some programming languages is to dispense with operators entirely and just use functions, with fairly loose restrictions on function names. For example, in principle there's no reason a function couldn't be named "+" or "|". Obviously that can lead to readability problems.
How old is Python 3 now? I've always used Python for a "miscellaneous task" language, and still do... and even I find "...because you refuse to upgrade" a bit insulting. If I used it for something serious, even more so. The way 2.x -> 3.x was handled is/was/will is an absolute disaster. Upgrading simple scripts is a non-issue. Larger projects seem to always be a horrible pain.
From: http://www.asmeurer.com/python3-presentation/slides.html#55 ... why is this good: def dup(n): for i in range(n): yield i yield i ... but this one better? def dup(n): for i in range(n): yield from [i, i] ... it would seem you're needlessly creating (1): another level of generators, and (2) creating a real list
Compare these instead: for i in range(n): yield i yield from range(n)
Seems similar to the usual "list comprehensions vs. for loop" arguments; to which I always think "use whichever is readable for the given code".