101–110 of 392 posts
Earlier quoted context omitted.
What about not spending time and money and just keep using python 2 for software that already uses it. And only use python 3 for new code bases.
This is how you end up still running fixed-format Fortran code in 2016. If your software is being actively maintained, it's time to move to Python 3.
The worst thing about open source is that people can do stupid stuff with your software. If you're going to create this abomination, at least do us all a favour and DON'T call it Python. Call it Retardython or something. I don't want to imagine people coming into the official support channels and claiming they are using "Python 2.8", then other people lecturing them about what that software really is, etc. Sounds lik…
Very good points, but you should try to keep a more civil tone.
Earlier quoted context omitted.
Regarding tuple unpacking, instead of writing, say: def foo((birthname,surname)): ... you can write in Python 3: def foo(name): birthname, surname = name ... It's not less readable. I also missed it in the beginning, but it's not really a big deal. (I think they couldn't keep the feature because of how '*' is used, but I am not sure.) Edit: If you have problem with this in lambda expression, just create a named inner…
I wish I could downvote. I specifically said I hate the tuple unpacking syntax change in lambdas . That's where I used it so much to begin with, not in defs! I obviously can't put statements like that in lambdas, and until now I didn't need to do that to make my code readable. Now I have to name all of my lambdas just to make this syntax work, which is nonsense. It used to be there and it worked perfectly fine .
list(map(lambda (some, thing): some + thing, everything))
# better
list(some + thing for (some, thing) in everything)
# okish, "verbose lambda"
def compute(everything):
def magic(elem):
some, thing = elem
return some + thing
return list(map(magic, everything))
# probably better
def magic(some, thing):
return some + thing
def compute(everything):
return list(magic(some, thing) for (some, thing) in everything)Earlier quoted context omitted.
Regarding tuple unpacking, instead of writing, say: def foo((birthname,surname)): ... you can write in Python 3: def foo(name): birthname, surname = name ... It's not less readable. I also missed it in the beginning, but it's not really a big deal. (I think they couldn't keep the feature because of how '*' is used, but I am not sure.) Edit: If you have problem with this in lambda expression, just create a named inner…
I wish I could downvote. I specifically said I hate the tuple unpacking syntax change in lambdas . That's where I used it so much to begin with, not in defs! I obviously can't put statements like that in lambdas, and until now I didn't need to do that to make my code readable. Now I have to name all of my lambdas just to make this syntax work, which is nonsense. It used to be there and it worked perfectly fine .
In any case, I think I see your problem. You are not the sole user of Python language. There are features that other people like (such as using '*' in unpacking), and so features you like are weighted against their use cases, and a reasonable compromise is made.
And frankly, I think if you like to use lambdas that much, you really want to program in a language where everything is an expression, such as Lisp or Haskell.
I make software that people can write plugins for in Python. After months, years of struggle we finally dropped support for Python 2 because our small team could not bear the overhead of maintaining two bindings. We work a lot with researchers in signal processing domain and we have hard time as it is to get people to use Python 3. Please, do not put obsolete software on life support.
So scoff all you want, but Python 2.x isn't going away that soon.
Earlier quoted context omitted.
> Addendum: I think for standards like programming language semantics (which in case of Python is directly embodied in the C implementation), "obsolete" means there is a new standard by some official body (say, the developer of the old standard) that addresses shortcomings of the old standard. Really? So even if no one ever uses it, it still renders the old one obsolete?!
You should be aware that trying to badger people with strict adherence to an arbitrarily-chosen definition of a term as a way to avoid countering their arguments does not make you look intelligent, does not make you look well-qualified to argue the topic, and does not make you look like you're winning the argument. Resorting to technical haranguing about the definition of a term typically, in fact, gives the appearan…
Earlier quoted context omitted.
> Armin Ronacher, author of (among other software) the excellent Flask web framework, thinks that Python 2's system of codecs and byte streams is better in practice. Armin Ronacher works in a very specific context of having to deal with byte/text interfaces in pretty much all his projects, and while I can see where he comes from I work at a different level and at the level at which I work the P2 model is a giant pain…
> Also note that Armin has repeatedly praised Rust's text model, which is much more similar to P3's than P2's (except with static types and no messy legacy). That is incorrect. Rust's text model has (almost) free (and copyless) transmutes from bytes to strings. Python does not. The text model of rust is much closer to Python 2 than 3 in many ways.
Rust's text model strictly separates proper strings and bytestrings, defaults to proper strings and requires that strings be properly formed (so much so that it has additional completely separated platform-dependent types for dealing with OS-originated "stuff").
The one "difference" (which is more in the realm of implementation detail than language text model) is that Rust leverages its ownership system to make UTF8 "encoding" and "decoding" free (literally for the former, essentially for the former). The encoding and decoding are still there and explicit operations though.
> Rust's text model has (almost) free (and copyless) transmutes from bytes to strings.
Only for the specific case of input bytes already in the language's internal encoding (which granted will be common as most inputs would be ascii or utf-8) and with the same ownership constraints as the input, and that's mostly enabled by Rust's ownership model.
> Python does not.
Python doesn't generally do no-alloc/0-copy operations so that's not overly surprising.
> And the majority of Python code written does not run under any of the 3.x interpreters. This makes it harder for its users to be productive. What a load of bollocks. For new projects this only matters if libraries aren't ported, which they are for the most part. For old projects, either you're in a situation where you can spend time porting your code to Python 3, or you don't; but as TFA mentioned pep-404, the writ…
This! A thousand times! I love open source and free software. I absolutely love the fact that you can fork the code and adapt it to your needs. If you find others who like it great! But please, don't use the Python name! It will create more confusion than help. This fork with a different name is 100% fair in my opinion.
Earlier quoted context omitted.
I'd argue Python 2.7 counts as no longer produced. The 2.7.x releases with their bugfixes are akin to an electronics company still honoring the warranty of tape recorders and still repairing them. That doesn't mean tape recorders are not obsolete, especially since the company is not making them anymore. I consider the parallel 'making software' to be the process of feature proposal -> patch -> review -> merge
In your eyes is anything that isn't getting more and more features added every few months necessarily obsolete? Can't something just become mature and fulfill its goals at some point? Do you consider T-shirts to be obsolete too? If they kept adding more and more attachments ("features") to your clothes every few months to prevent them from becoming "obsolete" you'd be walking around in really heavy clothing...
You could still wear them today but you'd be working against today's "protocols".
Earlier quoted context omitted.
I wish I could downvote. I specifically said I hate the tuple unpacking syntax change in lambdas . That's where I used it so much to begin with, not in defs! I obviously can't put statements like that in lambdas, and until now I didn't need to do that to make my code readable. Now I have to name all of my lambdas just to make this syntax work, which is nonsense. It used to be there and it worked perfectly fine .
Why would you want to downvote somebody trying to help you? In any case, I think I see your problem. You are not the sole user of Python language. There are features that other people like (such as using '*' in unpacking), and so features you like are weighted against their use cases, and a reasonable compromise is made. And frankly, I think if you like to use lambdas that much, you really want to program in a langua…
Misreading comments is not helping.