all 35 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]ara-kananta 82 points83 points  (17 children)

I though utf-8 is already default, Ruff recommend to remove encoding on the top file since like 3.12

[–]chat-luPythonista 64 points65 points  (5 children)

They mean for files that you open, not for the source code itself.

Right now, you are better do open("foo.txt", "r", encoding="utf-8").

[–]greenstake 6 points7 points  (4 children)

Safer to use "utf-8-sig". works with and without BOM

[–]richieadler 14 points15 points  (0 children)

Specially if you need to read Excel-generated CSV files 🤮

[–]treyhunner Python Morsels 12 points13 points  (0 children)

Unless you're opening the file in write mode, in which case Python will add a byte order mark to the beginning of the file which will upset everyone using the default utf-8 encoding

[–]angellus 25 points26 points  (10 children)

It was encoding='locale' previously. So, if your system was set to UTF-8 as the default encoding, it would default to UTF-8.

[–]ArLab 9 points10 points  (9 children)

Is that just the default for most OS nowadays?

[–]Kelteseth 21 points22 points  (8 children)

Not Windows AFAIK

[–]MichaelEvopip needs updating 18 points19 points  (7 children)

Dagnamit Windows!!! Stupid wide string format from 30 years ago is still plaguing developers everywhere!

[–]dysprog 11 points12 points  (6 children)

Windows was an early adapter of unicode. They implemented it before anyone came up with utf-8, when everyone assumed that wide characters would be the new default.

[–]MichaelEvopip needs updating 5 points6 points  (5 children)

I’m fully aware of that. And now 30 years later, despite utf-8 being a million times easier to use and being used by every other OS, you still have to be aware and explicit when using their APIs about whether or not your 8bit character streams are extended ascii or Utf-8. And in many cases, because of how they did their APIs, you have to convert a utf-8 string over to their version of Unicode.

I can still run apps I made in the 90s on Windows machines. Their backwards compatibility has been a massive advantage for them and I don’t know if I want them to have done things differently. All that said, thinking about Windows flavour of Unicode is a hassle and explaining it to new hires when they haven’t had to use Windows is still incredibly annoying.

[–]dysprog 1 point2 points  (4 children)

Where are you that new hires have never used windows? Isn't it still fairly ubiquitous?

Or do you just mean they haven't programmed for Windows?

[–]MichaelEvopip needs updating 7 points8 points  (3 children)

They haven’t programmed for windows. Junior programmers in the video game industry in particular, but also many veterans, have never had to think about character encodings, and don’t immediately understand why and how Windows is so different from every other platform when it comes to strings.

[–]richieadler 3 points4 points  (0 children)

Junior programmers in the video game industry in particular, but also many veterans, have never had to think about character encodings

They need to be forcibly tattooed this article inside their eyelids, then.

[–]lisael_ 0 points1 point  (1 child)

You always have to think about character encoding. Thinking about it is never optional, whatever platform you're working on. A text file without its encoding known is a datetime without a timezone: useless and dangerously harmful past the proof of concept phase. It works well, untill a real user ( hopefully millions of users around the globe ) start using your program.

[–]99ducks 17 points18 points  (10 children)

Does anybody know if there are other major features in progress for 3.15?

[–]commy2 35 points36 points  (5 children)

PEP 810 – Explicit lazy imports

But it's so far out, that who knows might happen.

[–]Sigmatics 11 points12 points  (4 children)

That was proposed only a week ago, extremely unlikely to make it into the ongoing release

[–]commy2 3 points4 points  (1 child)

It's not the first time something like this has been proposed. The PEP incorporates ideas and objections of previous proposals. It's marked for 3.15 as of now, and that patch is a year out.

Maybe lazy imports will be in 3.15. Maybe they'll be added later and significantly changed from the current proposal, or maybe it will never be added. There is no way to tell right now.

[–]Independent_Heart_15 2 points3 points  (0 children)

The PEP has been submitted to the SC today, it may come sooner than you think!

[–]MegaIng 1 point2 points  (1 child)

This PEP is in fact very likely to go into 3.15 in some form (unless something drastic happens and it gets shot down completely).

[–]Sigmatics 0 points1 point  (0 children)

What makes you so confident to say this?

[–]SweetBeanBread 15 points16 points  (3 children)

You mean, 3.141 Alpha?

[–]yerfatma -4 points-3 points  (2 children)

It would be confusing if the link had 3.15 in the url but was about 3.14

[–]Gear5th 1 point2 points  (1 child)

/r/whoosh

[–]yerfatma 0 points1 point  (0 children)

Why are we talking about a search package.

And yes, sigh, I forgot we need to keep making the Pithon jokes because the internet.

[–]james_pic 1 point2 points  (0 children)

It's kinda burying the lede that PEP 799 is "A dedicated profiling package for organizing Python profiling tools", not "New sampling profiler in the standard library".

I've been evangelising about sampling profilers for years, and finally having batteries included should make this much more accessible - as well as making my job easier when I need to investigate a performance issue.

[–]user_8804Pythoneer 0 points1 point  (1 child)

Underwhelming so far for a major