371–380 of 390 posts
Earlier quoted context omitted.
I actually think that migrating from Qt4 to Qt5 has a lot of similarity with python 2 to python 3. Not sure why there aren't more people doing the comparison.
pyqt is a robust enough wrapper to avoid the migration issues, so in a python thread you won't have anybody who suffered through that mess.
Earlier quoted context omitted.
It's a bit verbose. A lambda with a single one letter param takes ten characters to write: `lambda x: `. In JS, it's 5: `x => `. Ruby blocks take sevenish: `{|x| }`. Six in haskell.
Also, still no support for multi-line lambdas is there?
Earlier quoted context omitted.
Also, still no support for multi-line lambdas is there?
Multi-line lambdas will never happen. Lambdas are expressions. "Multi-line" means statements. There is no sane way you could embed statements into an expression with whitespace-based block syntax.
> There is no sane way you could embed statements into an expression with whitespace-based block syntax.
Ruby does it. Of course, Ruby has a limitation that a function call may only have one "block", but still - Ruby blocks are statements embedded into an expression in a whitespace-based syntax.
Earlier quoted context omitted.
Perl6 is incompatible with Perl5, so they're also going through a similarly painful transition. Everyone waxes lyrical about how Python 2.x was "good enough and why would you change it", but there were several things in Python 2.x that were objectively awful (unicode was broken, iterator variables can leak to the outer scope, division of integers producing integers, xrange, raw_input, mixed indentation "working", etc…
Perl6 has nothing to do with perl5, it's a completely different language. I would call the transition fatal, not painful.
It's really sad. In retrospect they certainly should have named it something different. The Perl 5 community could have progressed, maybe even made a Perl 6, while the NGPerl skunkworks project continued independently for 15 years.
Earlier quoted context omitted.
>For the good of any computer language, old versions need to eventually die off. I would say instead: for any good computer language, new versions need to retain compatibility with old versions. Every single system I run has python 2.7 (including my brand new Macbook running latest OS X). Luckily I don't need numpy, and I can probably do without python at all if I have to. Compare to perl: I can run old perl scripts…
Perl6 is incompatible with Perl5, so they're also going through a similarly painful transition. Everyone waxes lyrical about how Python 2.x was "good enough and why would you change it", but there were several things in Python 2.x that were objectively awful (unicode was broken, iterator variables can leak to the outer scope, division of integers producing integers, xrange, raw_input, mixed indentation "working", etc…
I get that for people with no knowledge of programming whatsoever it can be confusing, but it's standard behavior in nearly every typed language.
In C/C++, you divide an Int and you get an Int. If you want floating point division, you divide by a float. Problem Solved.
Almost EVERYTHING else could have been done with slow migration, or simply documenting the odd or quirky behavior.
Iterator variable leaking is just a result of poor programming.
Raw_input vs input could have been solved by slowly deprecating input. Or just left as is.
xrange is the same story.
It all seems like someone just decided to throw their hands up in a fit, throw their toys on the ground, and make a new Python. I enthusiastically jumped at Python 3 in the begining, then ran into problems, and crawled back to my 2.7 and decided I could let others fight the stupid cult war that was coming over 2 vs 3. I'd rather use a tool that works than change all my code over someone's idea that newer is better.
Earlier quoted context omitted.
Perl6 is incompatible with Perl5, so they're also going through a similarly painful transition. Everyone waxes lyrical about how Python 2.x was "good enough and why would you change it", but there were several things in Python 2.x that were objectively awful (unicode was broken, iterator variables can leak to the outer scope, division of integers producing integers, xrange, raw_input, mixed indentation "working", etc…
I never quite understood why the division of integers resulting in integers was a problem. I get that for people with no knowledge of programming whatsoever it can be confusing, but it's standard behavior in nearly every typed language. In C/C++, you divide an Int and you get an Int. If you want floating point division, you divide by a float. Problem Solved. Almost EVERYTHING else could have been done with slow migra…
And hence why it's a problem in Python. If you have a function like
def foo(a, b):
return a / b
> Iterator variable leaking is just a result of poor programming.
I think it's a language bug. Why? Imagine if you could do this in C:
for (int a = 1; i # a is not defined
if something:
a = 1
else:
a = 2
print(a)
> raw_input vs input could have been solved by slowly deprecating input. Or just left as is. xrange is the same story.
And this is how PHP ended up having three different string escaping functions for SQL statements. The first one (escape_string) was broken, so they added real_escape_string, and then they needed to handle connection-specific quirks so they added mysqli_real_escape_string.
Some people still use escape_string even though it's broken -- and the language devs cannot fix it because "that would break users".
Earlier quoted context omitted.
It's a bit verbose. A lambda with a single one letter param takes ten characters to write: `lambda x: `. In JS, it's 5: `x => `. Ruby blocks take sevenish: `{|x| }`. Six in haskell.
How did you get six for Haskell? I get five if you require a space at the end \x->
Earlier quoted context omitted.
I don't think I am. In this thread you're repeatedly making the point that 2.7 supported Unicode and the difference is mostly technical details of things like internal representation and/or a matter of prefixes or whatnot. This just isn't true. The fundamental change is - in Python 2, strings are bags of bytes and in Python 3 strings are collections of Unicode codepoints and you need to go through an encoding to conv…
What I said: 1. BOTH Python 2 and Python 3 come with built-in support for BOTH bytestring and unicode (contrary to OP's claims I responded to) 2. That mixing bytestrings and unicode will fail with an explicit error since 3.0+ (a good idea IMO) 3. Unicode has a more efficient internal storage since Python 3.3+ (a neat technical detail) 4. It's good practice to be explicit about the type of literals, and write b"" and…
The person you replied to didn't claim Python 2 doesn't support unicode. 'Bytestrings' has what is wrong with Python 2 neatly summarized in a single word (and this, incidentally, is a term the Python documentation avoids these days because it's bad). 3 is true but not really related to the topic at hand. 4 is, I think, outright wrong. As to 5, I'm not sure why you would even want to defend that. It's not what the poster said and even if they had said it, they'd be just wrong - it's not 'FUD'. That is just you being grumpy and rude.
Earlier quoted context omitted.
> UTF-8 as the guaranteed default encoding, instead of trying to infer anything from stupid locale shit. This is already the case for source code, right? And I don't see where else it could apply. If you mean stdin/out, then those have to use locale to be compatible with other text-processing software (so that you can pipe things etc).
Locales are not a real way of specifying an encoding for standard in and out. They were not designed for a world with Unicode and UTF-8 in it; they were designed for a world with limited character sets where your text data would probably not be sent outside of your country. Here are some reasons not to try to get your locale to tell you about UTF-8: - There is no standard for this. - Locale suffixes ".utf8" and ".UTF…
I do want my Python code to work, yes. But I assure you that if my locale says ru_RU.KOI8-R, when I say "work", I don't mean "dump garbled stuff on my screen, because you output UTF-8 when I specifically asked you to use KOI8-R".
I also don't see why the UTF-8 encoding specifier in locale is a "hack". UTF-8 is just that, an encoding. Locales are a generic mechanism for dealing with encodings. What makes UTF-8 special in that regard, and why is an UTF-8 locale a hack?
> The locale "C" does not really mean you want your program to explode when it sees a non-ASCII byte. What Python does here does not promote compatibility in any way.
That's true for any locale, if a character comes up in the output that cannot be encoded in it - it should just use some reasonable substitution. And if you're actually dealing with binary data, then you should be reading and writing bytes objects, not printing strings, and then the whole question of encoding is moot.
> BSD has no UTF-8 locales and has never pretended that locales work with Unicode.
That would be a surprise to my FreeBSD installation, which is running with en_US.UTF-8. Do you mean that the locales don't come generated by default? I'm not sure why it's a big deal ... I mean, Arch doesn't come with any locales generated by default, but I don't think anyone would claim that it doesn't support UTF-8.
One other thing BSD does, is that it doesn't guarantee that wchar_t is Unicode in all locales (Linux/glibc does). But that's a different and orthogonal issue.
> Windows' equivalent of locales is extremely deprecated and never actually supported UTF-8. The modern Windows APIs that deal with standard in and out correspond to Python's Unicode string type, not its bytes type; encoding the Unicode I/O into bytes is not Python's responsibility.
Win32 doesn't have any string-based I/O functions, except for console. So if you're printing directly to the screen (and ignoring / not supporting redirection!), then yes, you can just invoke WriteConsole, give it a UTF-16 string, and be done with it. But if you're printing to a file, or to stdin/out as a handle, then you only have ReadFile/WriteFile, which require a byte array; you're expected to do your own encoding.
By the way, and speaking of proper Unicode handling APIs - because of this disparity, and the desire to avoid a conversion unnecessarily (due to the lack of UTF-8 locale making it lossy) so as to allow printing out Unicode, Python actually has to resort to hacks to do this on Win32. Specifically, it has a special class - _io._Win32ConsoleIO - that is implemented using ReadConsole/WriteConsole. If output is a Win32 console, then that class is used, and Unicode is fully supported in the output. If output is redirected, then the standard implementation (that does encoding + Read/WriteFile) is used instead.
> Really every operating system but Linux has this figured out, and in practice, Linux users want UTF-8 regardless of what their locale says.
I strongly disagree. The users who want it but don't know how to configure it, are already using a distro that says that it should be UTF-8. The users who are using something that doesn't, either do it for a reason, or are knowledgeable enough to know what's going on and why, and deal with it accordingly. Either way, no harm is done by just using the locale setting. On Ubuntu etc, it will just be UTF-8, and everyone will be happy.
Earlier quoted context omitted.
> UTF-8 as the guaranteed default encoding, instead of trying to infer anything from stupid locale shit. This is already the case for source code, right? And I don't see where else it could apply. If you mean stdin/out, then those have to use locale to be compatible with other text-processing software (so that you can pipe things etc).
Reading and writing files. This catches people out, because on most Linux and Mac systems it defaults to UTF-8, so people assume UTF-8 is the default. But it's based on the locale, so one day someone runs your code on Windows, or on Linux with the basic ANSI C locale, and suddenly writing text to a file blows up. This is the number one thing I'd change if I were in charge of Python. ;-)
That said, .NET has been defaulting to UTF-8 for text files since 1.0, and it seems to be working well in practice, so maybe it is a reasonable default after all.