Concurrency:
It seems we're now happily out exploring here. I'm looking forward to benchmarks showing that PP or similar (or dissimilar!) solutions actually provide a performance gain. Another route I'd like to see explored is integrating one such solution into an existing web framework (or perhaps as WSGI middleware) so that web applications have an easy way out without redesigning their architecture.
Eggs and Easyinstall standardized:
From the response it's pretty clear why these particular solutions aren't standardized yet -- they are at best controversial. In any case this is a library issue and not tied to 3.0. I'm hoping someone improves upon Phillip Eby's work. I'll gladly accept something into the standard library but I don't have the time to write it myself: for several reasons I'm not in the primary audience for such a tool.
Better application deployment support:
Again, a library issue, I cannot do much about -- I don't have time to do it myself and I don't like telling other people what to do (nor do I like to be told what to do myself, as should be obvious by now).
Get rid of self:
I think this has been addressed in the responses; it's not as easy as you'd think, and there are important advantages to the uniform interpretation of methods as "just functions that get called in a funky way". In Ruby, everything is a method, or an anonymous block, and there are no "free functions". Python uses the complimentary approach, treating functions as first-class citizens. Both approaches are complete; they are however incompatible, and you can't easily morph one into the other. (Personally, I find that the criticm of explicit self has about as much merit as the criticism of Python's use of whitespace.)
Transparent connections to UI languages:
Again, a library issue. I agree that Tk is antiquated, but it still has a following, and IDLE is actively being supported. The alternatives that are readily available, like PyQt, PyGTK, or wxPython, all have their specific advantages and disadvantages, making it hard to pick one (plus, the political impact of putting one in the standard library could be damaging both to Python and to the alternatives that weren't picked). However, it looks like Bruce believes that these are all antiquated, and we should be looking forward to the next generation of solutions. But which one to pick? IMO it's way too early to know; these things are about to evolve dramatically, and some are likely to die.
That requires someone dedicated who is willing to put out a quick series of experimental releases, and a user base who are interested in living on the bleeding edge. It's not an appropriate project for Python 3000 -- despite the whimsical name, it is primarily a very conservative overhaul of the language, focused on fixing some of the moer tenacious warts that can only be fixed by breaking backwards compatibility. (Those warts that can be fixed without breaking compatibility are getting fixed in an evolutionary way, but some things just can't be changed that way.)
Library support ("smart libraries"):
This is a pretty rambling section that mostly just leaves me mystified. Never having to look up documentation again? That sounds like wishful thinking. There is no substitute for understanding what you are trying to do, and "smart" here seems to be synonymous with clairvoyance. However, Bruce guessed one thing right: I am encouraging people who want to explore such things to make the most of argument annotations, which are waiting to be used.
Component support:
I guess this section is referencing a context I'm unfamiliar with (not having used Java much) since the tie with event handling under this heading completely baffled me. I seem to recall that Java had several misguided attempts at supporting "heavy" components -- but maybe there's a consensus in that world now? I think it would be a useful experiment to try to create whatever it is you want as an add-on library, which I believe is mostly the status it has in Java.
Support for DSL creation:
This means different things to different people. Personally, I believe the Ruby folks are abusing the term. The gentleman who pointed out that Python has DS Libraries instead of DS Languages hit the nail exactly on the head IMO; this is another example of two different ways to solve the same problem that are complementary and won't easily converge.
Python 3000 is mostly the work of a handful of people, who mostly care about the core language (which is the hardest thing to evolve). Bruce's post (apart from the anti-self rant) is mostly about issues around the language, like libraries and components. These things can easily be added by motivated individuals. It's open source. What are you all waiting for?!
Thanks for being so politically open about Python 3000, Guido. I completely agree with you on your positioning, and I don't understand why people write "open letters" and "blog entries" targeted at you, while you are focused at the core language and not at the library.
Perhaps you should to point some fellow as the "library coordinator" who should be answering these and taking care of the directions the library development should take ? That way you could quit answering every post and just do your work, which I'm sure is more important then answering everyone who thinks to have a point. While I think it's great to have you so open about the language, I think people are focusing on you too much. Or perhaps you're just trying to answer everything too much :)
Let's just let Guido work, we'll we ?
Whoever have a language issue, Guido have been shown to be open and ansered everyone. But for library questions, let's leave him alone, or even better - do it.
Concerning concurrency, what if something like Parallel Python or Stackless Python performs just the same, but is just an easier model to work with (than threads, semaphores, etc.), which in the end produces stabler code?
I think that the problem with Bruce Eckel is the same as mine, that the standard library work for python 3.0 has not started, and that we would like to work there but don't know how. Maybe you should appoint someone to be the team leader for it, and open a new mailing list, so volunteers can start working on it now.
Besides that I liked all your answers and I specially think you are right about concurrency libraries, we need to test them on wsgi and other places to let them prove themselves on the wild.
> I think that the problem with Bruce Eckel is the same as > mine, that the standard library work for python 3.0 has > not started, and that we would like to work there but > don't know how. Maybe you should appoint someone to be the > team leader for it, and open a new mailing list, so > volunteers can start working on it now.
A team leader exists (Brett Cannon), a seed for a plan exists (PEP 3108) and the mailing list is python-3000@python.org. Don't be shy!!!
finally, there are many people that use this module so to use multiple cores effectively. I think it performs well, is stable enough and it is up to the person who is in charge to make it part of Python's distribution.
Just imagine this: With this solution in the STANDARD library, who will continue to fight for the GIL anymore ??
> ... I don't understand why people write "open letters" and > "blog entries" targeted at you, while you are focused at > the core language and not at the library.
You don't understand? I will try to explain then.
Guido in the past has expressed some good reasons why the GIL should stay. Obviously, his opinion carries a lot of weight in the Python community. On the other hand, whenever you hear about Python's inability to take advantage of multiple CPU cores, the GIL is mentioned as the prohibiter. In the Python 3000 FAQ, Guido says (about removing the GIL): "No. We're not changing the CPython implementation much..." This sentence indicates that he is in some way involved in the decision about keeping the GIL. Therefore, considering his opinion on the GIL, the fact that he is involved with it, and the fact that he is considered to be a person of great importance for Python and Python's future, I think it is quite obvious why this open letter was addressed to him.
Guido listed good technical reasons why the GIL should stay. But in my open letter I expressed a number of (hopefully good) reasons why proper multi-threading support would be a great benefit to Python as a language and people writing software with Python. I also tried to explain why the traditional response in the Python community ("use message passing", "use multi-processing", "use shared-nothing architecture") is not always going to cut it.
So, there. I hope you understand now why there was an open letter, and why it was addressed to Guido.
> Whoever have a language issue, Guido have been shown to be > open and ansered everyone. But for library questions, > let's leave him alone, or even better - do it.
Well, see, I don't know if something like this is really only a library question. Removal of the GIL (should it be considered) is certainly more than just something that's done in some library.
I don't know yet if multi-core support by means of a library is the way to go. There are different ideas batted around, and all of them have advantages and disadvantages. I think if there would be C/C++ or Java style multi-threading support, people would have the most flexibility with their architectures and also have this in a very platform independent manner. If a library is going to provide this functionality, I think that the API should be not only similar to the threading API (just my opinion), but that this solution also needs to support shared memory with the same performance and simplicity as true multi-threading does. If this is all possible with a library approach then I guess this would work well.
> So, there. I hope you understand now why there was an open > letter, and why it was addressed to Guido.
And I hope you also understand that I am not personally going out of my way to either get rid of the GIL or change the paradigm for parallel processing in Python, at least not until Python 3.0 has actually been released. AFIC it's a library issue.
I am still waiting for someone to post benchmark results for PP or another similar (or dissimilar!) module.
I guess it takes Bruce Eckel for Guido and I to appear to agree on a broad range of matters, and I think that Guido justifiably brushes aside the bikeshed-like issues convincingly: removing self, replacing Tk with something else, and the pervasive DSL fetish (which in Ruby seem to be the usual excuse of badly dressing up a programming language and pretending a lot).
Bruce does seem to get that other Python-like languages are out there - I had seen Converge before the developer of EasyExtend mentioned it in conversation, but it seems reasonable that such ideas are thrashed out in other places, and not in a language that people depend on heavily.
I assume we all want Python to be the next big language. The one that replaces Java. I can understand that you don't want to deal with all the library issues but what would Python be without a strong library? No language can be the next big thing without having a certain set of desired features that we all have come to expect to be available.
Now the standard library already meets many of these expectations but there are those holes that need to be addressed. Now you may not have the desire and/or time to work all these issues but I do believe that as BDFL it is your responsibility to sometimes make the tough choices. That just comes with the territory of being a leader.
Recently I brought up on the python3000 mailing list that you just need to select a UI framework to be the standard that ships with Python 3. I know you don't feel like your the right person to make the decision but I believe the Python community would be better served if you would just make a pronouncement. Yes you run the risk of not selecting the best framework. Yes you will make many people upset with you. But so what. In the end you will be respected for making a decision so that future development can be focused on one UI framework. Python will benefit from this decision in the long run.
If you don't want to make a decision yourself. How about making a statement that one UI framework will ship with Python 3 and it will be decided by the community during the next PyCon. This gives 6 months for the UI frameworks to battle it out and then another 6 months to make sure the selected framework is ready for the 3.0 release. You have the power to make this happen. All that you need to do to get this started is to make an announcement.
As far as Eggs and EasyInstall is concerned this might just be a matter of funding. I'm sure Phillip Eby is more than capable of doing a good job to get this done. We just need to motivate him. Maybe the PSF should offer him a grant.
On the concurrency issue. It's great to see some talk about PP and company but it's likely that the best long term answer to this issue will likely come from PyPy. Unfortunately PyPy has quite a ways to go before it can offer a realistic solution. Now that the EU funding has finished it's likely that further progress will be significantly slower unless some additional funding becomes available.
It would obviously take a considerable effort to raise funds for such an effort. I'm sure it would likely require raising $1-2 million. For now lets assume that the PSF was able to raise the money. Would you feel it would be wise to spend such a large amount on this effort or do you feel it would be wiser to spend it on other areas.
Now I'm sure there would be a significant number of developers and users of Python who would be more than willing to donate money for this effort and the PyPy team has proven itself that it is capable of using funding with responsibility. But I have no idea as to whether or not it would be feasible for the PSF to raise such a large amount so I started a wiki page at http://wiki.python.org/moin/PyPyDonations to take a poll of users willing to support such an effort.
I'm not a huge fan of DSLs but would use them occasionally if they were available in Python. I wonder if supporting such a feature could be a simple as supporting the following syntax and defining an interface to DSL parser objects.
dsl_name""" DSL code goes here ... more DSL code """
or if options need to be passed into the DSLParser
dsl_name"""(arg1=1, arg2=...) DSL code goes here """
where dsl_name would be the name of the DSLParser class. The local and global name spaces would also be made available to the DSL parser object. This is just some initial ideas and not sure if this simple syntax would adequately cover all DSL use cases.
> I don't understand why people write "open letters" and > "blog entries" targeted at you, while you are focused at > the core language and not at the library. > Simply because he's the "Benevolent Dictator" and the most public face of the Python ecosystem. When people think "who's related to Python", the most obvious answer is "Guido van Rossum", no matter the hard work of others.
Then they'll think of the other high-profile pythonistas, but the one person that symbolizes python is GvR.
John M Camara writes: "How about making a statement that one UI framework will ship with Python 3 and it will be decided by the community during the next PyCon. This gives 6 months for the UI frameworks to battle it out and then another 6 months to make sure the selected framework is ready for the 3.0 release."
I doubt that the developers of the most significant UI frameworks care about battling anything out: they get their work done regardless, and people use those frameworks to develop and deploy real applications. It seems to me that the only people who do tend to care about getting standard library approval in ways like this are those who want to fast-track their own, new solution (or perhaps their personal favourite) into a favourable position in the standard library in complete disregard of the availability of better, less political alternatives.
> John M Camara writes: "How about making a statement that > one UI framework will ship with Python 3 and it will be > decided by the community during the next PyCon. This gives > 6 months for the UI frameworks to battle it out and then > another 6 months to make sure the selected framework is > ready for the 3.0 release." > > I doubt that the developers of the most significant UI > frameworks care about battling anything out: they get > their work done regardless, and people use those > frameworks to develop and deploy real applications. It > seems to me that the only people who do tend to care about > getting standard library approval in ways like this are > those who want to fast-track their own, new solution (or > perhaps their personal favourite) into a favourable > position in the standard library in complete disregard of > the availability of better, less political alternatives.
Why would less political alternatives be overlooked if either Guido or the Python community as a whole makes a selection via a vote during PyCon? I'm sure if it's left up to the community to make a decision a debate will take place and all important issues will be discussed.
The real issue that needs to be addressed is that Python's image is hurt by not having support for a world class UI framework. Don't get me wrong there are reasonable good options available but none are as good as what is available for C# for instance.
Now at a personal level I could care less whether or not Python has a good standard UI framework as I rarely do any desktop GUI UIs and any of the available frameworks can meet my limited needs. But I do care about Python's future and I feel that Python's future would be brighter if it had a standard library that supports a world class UI framework.
Flat View: This topic has 32 replies
on 3 pages
[
123
|
»
]
Previous Topic
