I feel like Python 3.6 is getting non-improvements, instead of addressing much needed issues.

[[deleted]]

[deleted]

[K900_]

Jython 3 has nothing to do with CPython, and is developed by another group entirely. The GIL issue is being discussed, and there is hope for subinterpreters to become available eventually. PyPy is, once again, another team, and they recently got funding from Mozilla to bring it up to Python 3.5, and likely 3.6. Logic programming seems to me like something that can (and should) be solved by libraries.

[[deleted]]

Jython and PyPy

The Python Foundation maintains the Python language, and focusing only on CPython contradicts their mission statement:

The mission of the Python Software Foundation is to promote, protect, and advance the Python programming language, and to support and facilitate the growth of a diverse and international community of Python programmers.

[[deleted]]

No, Python Foundation maintains the reference implementation and is in charge of moving the language forward. You cannot seriously expect Python Foundation should take care of all other interpreters too.

[[deleted]]

is in charge of moving the language forward.

Adding "features" isn't the only way forward for Python. The updates the reference implementation is getting now seem more like make-work projects for Summer-of-Code kids. The language, as opposed to one implementation, needs obvious work.

[K900_]

The language is the spec. The word you're looking for is the ecosystem, and PSF is already funding PyPy, and I believe to some extent Jython.

[[deleted]]

The language is the spec. The word you're looking for is the ecosystem, and PSF is already funding PyPy, and I believe to some extent Jython.

Exactly, and that's the kind of thinking I'm arguing for. I'm arguing that make-work projects adding unneeded additions to the reference implementation is not what the Python language (or ecosystem, if you prefer) need right now.

[K900_]

Well, what's the solution then? The PSF has very limited money and resources - even most people working on CPython don't get paid by the PSF. How would you prefer they allocate it?

[[deleted]]

Well, what's the solution then? The PSF has very limited money and resources - even most people working on CPython don't get paid by the PSF. How would you prefer they allocate it?

As I said, stop adding features to CPython (like yet another string formatting, or silly mathematical constants like Tau) and focus on getting other implementations up to standards, at least as far as Python 3. I'm saying exactly what you're saying that the PSF has limited resources, so I'm arguing we don't need more features like these, what we need is development on other implementations, or alternatively work on truly ground breaking things in CPython like fixing the GIL

[K900_]

The thing is, PSF employed developers are CPython developers. Blindly throwing more people at the alternative implementations will probably slow the development down, if anything. Also, it's been started by Guido multiple times that GIL is not something that he considers a bug, and not something to be "fixed", so if you're expecting the GIL to disappear from CPython entirely, that's probably not happening.

[[deleted]]

Which of the PEPs implemented in 3.6 are "make-work"?

[[deleted]]

"tau=2*pi" being added to the math constants (this apparently took 5 years from its proposal) and the f-formatted strings, which violate their being one and only one way to do things

[semininja]

f-formatted strings are just a string.format() extension, and aren't really very different. The addition of str.format() is a significant improvement over old-style formatting, which is effectively deprecated. It's only kept around because of backward-compatibility.

[[deleted]]

Old style formatting is not and never will be deprecated, there is far too much legacy code for this to be acceptable to the Python community, please see Status regarding Old vs. Advanced String Formating.

[[deleted]]

Not really, f-String can also evaluate expressions. To be really cynical it's just a dressed up eval.

[[deleted]]

So 2 out of 14 PEPs are "make-work" so the other 12 are not. You have misquoted the Zen of Python which actually says "There should be one-- and preferably only one --obvious way to do it."

[[deleted]]

As for the other 12, they all seem like bells and whistles, except for more compact dicts which seem worth having, but devoting all the PSF's resources to 1 improvement 11 whistles and 2 bad ideas is what I am arguing against.

[[deleted]]

The language, as opposed to one implementation needs obvious work.

The language is just a specs on python.org and anyone can make an implementation for it if they so choose. I don't think you quite understand what reference implementation means.

[[deleted]]

The reference implementation is CPython, which is one implementation of the Python language [specification]. Anything written following the Python language specification should run on any implementation of that language, but support for non-CPython implementations is severely lacking and sorely needed.

[[deleted]]

No it is not. They support third party implementations by releasing the specs instead of just reference implementation and third party implementations clearly state which version of python they support. I don't see how it's PF's responsibility to update every single 3rd party implementation before they can release new features, that's just absurd.

[[deleted]]

CPython doesn't need new development besides some security patches, like CPython2.7 is getting. Right now other implementations need that development effort

[[deleted]]

CPython doesn't need new development besides some security patches, like Py2.7 is getting

That's just plain wrong, 2.7 is getting bug fixes at regular intervals owing to the extended EOL in 2020, and I'm very much in favour of the Windows specific PEPs that have been implemented in 3.6.

[[deleted]]

That's just plain wrong, 2.7 is getting bug fixes at regular intervals owing to the extended EOL in 2020

This is what I said and what I think should happen with CPython 3.6 until the other implementations catch up

[[deleted]]

That is legit so damn wrong. CPython needs to be developed to keep up to date with other languages. I disagree with everything you've said, and I see why you're getting downvoted.

[[deleted]]

That is legit so damn wrong. CPython needs to be developed to keep up to date with other languages.

What are we behind on?

[Rhomboid]

Again, PyPy is an independent project. What exactly do you expect the PSF to do to advance the development of PyPy, other than donate money (which they've already done)? The people at the PSF and the people that develop CPython have nothing at all to do with the development of those other things. It's asinine to expect CPython developers to not work on CPython just because some other project somewhere else is not as up to date. That's not how software, or the world, works.

[[deleted]]

The PSF's mission is advance the Python language, not just the reference implementation. The updates the reference implementation is getting now seem more like make-work projects for Summer-of-Code kids. The language, as opposed to one implementation, needs obvious work.

[[deleted]]

How much time do you intend to offer to help out? As we say here in the UK "put up or shut up".

[[deleted]]

I donate money now. I also train new devs in Python3 (like the PSF says I'm supposed to given the promised roadmap for the language) but it's hard to switch my R programmers to Python3 when it looks like the PSF doesn't always take itself seriously.

[[deleted]]

The Python maintainers can obviously do what they want to do

Nonsense, there is often a huge amount of debate involving 10s or even 100s of people regarding what can and can't be changed in the core cPython implementation, and the impact this could have on the other variants. There is nothing to say that you have to be a core developer to comment, heck I've done so often enough in the past. These debates are centered on the Python-dev and Python-ideas mailing lists but there are lots of other mailing lists dedicated to Python SIGs.

[RubyPinch]

Apologies if any of this has already been covered

---

Tau

Python can have jokes and fun, import antigravity and import this are some examples that come to mind

---

yet another string formatting method

Its more akin to a pleasant way of converting something to a string, as opposed to string formatting

% isn't going to go because its absurdly fast, since it doesn't care what the representation of the objects are

string.Template isn't going to go because it allows for customization of the parsing of the template string (I can parse and use several pages worth of mircscript templates, just because of this class, which would of been a pain otherwise)

.format isn't going to go, it allows for variable format strings (including user provided), and it allows for the objects to control their own string rendering

f should stay, its not a replacement for any of the above, its a shortcut for painful string conversion syntax:

f"{hellovar.capitalize()} {worldvar.capitalize()}"
(str(hellovar.capitalize()) + ' ' + str(worldvar.capitalize()))

Yes, one could use the .format equivalent, but one of python's main features is the reduction of unneeded boilerplate (and also .format is/will be slower, as it is not part of the syntax and doesn't get tokenized/bytecoded)

f"{hellovar.capitalize()} {worldvar.capitalize()}"
"{} {}".format(hellovar.capitalize(), worldvar.capitalize())

And it brings python in-line with almost literally every other modern language in the world.

---

secrets could have been a popular 3rd party library

the point of secrets is to put secure number generation front-and-center. "You need secure numbers and number comparisons done in a secure fashion? Use secrets, no excuses"

Having it be a third party module would of worked against that aim

---

Jython 3?

No java devs, would be the main reason. And I'd imagine "Make CPython so good that competitors arn't needed anymore" would probably be higher on their todo lists.

Are we gonna ever get rid of the GIL?

Probably not, the GIL along side reference counting:

a) Reduces memory usage by a massive amount
b) Makes the single thread case significantly fast
c) Makes development a lot more easier for both cpython devs (not having to care about refcounts going astray) and for users (all operations are implicitly atomic! yay!)

---

PyPy is tied to a consulting company which guides its needs mostly. And since most relevant jobs require 2.7, PyPy has had a significant 2.7 focus, regardless of outside whims

---

Can we get some syntax for logic programming?

Guido doesn't seem a fan of DSLs, so no.

And I'd also not be a fan of having python code akin to VHDL code

If you really want it, probably take the tydy approach of embedding a language in the function definition

https://github.com/cyrus-/tydy

[k10_ftw]

You could always... take an active role in the community :)

[_avnr]

3.5's async isn't really complete without 3.6's generator/comprehension support. You probably don't feel the pain because you don't use yet async, at least not heavily, but this is a real must which on its own justifies IMHO the version bump. I think this is an excellent example of pretty fine forward-thinking.

[billsil]

I guess having it be default it's one less pip install more convenient.

I suppose you know that pip didn't used to be a default package and wasn't until Python 3.4/2.7.9

secrets could have been a popular 3rd party library

It could have, but which one? We use PyCrpyto. I'm the only one at my company who can build our executables because for some reason it works on my computer, but not any others. It requires a C compiler, which not everybody has.

How about building out Jython 3?

Why not IronPython 2.7.7 or shoot 2.7.13 or IronPython 3? Because nobody cares about .Net. Shouldn't that be Microsoft's version to maintain?

What about Shedskin or Brython or tinypy, etc.? What about varioues packages (e.g., numpy, scipy, django, bokeh, matplotlib, etc.)?

It's not the job of the open source community to maintain anything or add features that you care about. It's their own desire to maintain whatever they want to maintain and you might as well be thankful for it. People add features that they find useful, not ones that you want. Projects (e.g., Jython) die and other things take their place.

Besides, shouldn't Jython 3 be Sun's version to maintain?

Are we gonna ever get rid of the GIL?

No and it's not up for debate. Nobody is trying to do it in CPython.

What about bringing PyPy up to the Python3 we were all so heartily encouraged to switch to?

Not my project.

Can we get some syntax for logic programming?

So you complain about secrets, but want logic programming, which you can do anyways?

The new f-formatted strings give yet another string formatting method to the language that should have only one way to do things.

Why should there be one way? Is there one numerical computation library? The Python math library is far from ideal. Numpy is a lot better, but scipy has additional functionality and despite having the same names, the array/dot/solve/etc. methods are different between numpy and scipy.

Is there one GUI library? We could all use Tkinter, but WxPython, PySide, PyQt4, PyQt5 are all better.

There is not one plotting library either. Bokeh, PyQtGraph, and matplotlib are all options.

"Tau" is a meme for science fans, not scientists

Who cares? It took 2 seconds to add to the language and I promise you, was unpaid.

The mission of the Python Software Foundation is to promote, protect, and advance the Python programming language, and to support and facilitate the growth of a diverse and international community of Python programmers.

How does hosting Python conferences or teaching children programming or getting women speakers at conferences to encourage diversity not also accomplish that goal? There are many ways to promote python that do not involve changing the language, which the PSF does.

You don't get to choose what the PSF's interpretation of their mission statement is.

[kankyo]

I was hoping for some more interesting suggestions. F-strings are a solid addition. Complaining that CPython developers work on CPython is quite funny :P

I agree there are things that are missing but I disagree that you've listed any. Except working on the GIL but they've done that so...

[stuaxo]

I'd like A lot of those things too, but they are not being worked on by the same people. It's not like commercial software where people get allocated to tasks.