 So I was saying that Python support, what it's doing today, shouldn't be broken by any of the center worker policy. I don't think it has to be changed for that. Everything has to be done in DHPAC from now on. Yes. That's the problem because it is broke. Maybe can we go back to Python? No, it has excuses to include non-parallel stuff into their workloads. Let's just make it depend on how it's changed. You can write that. I'm faster at writing the problem than DHPAC. Of course you're faster because if you start to work on that, I have to do more of this stuff. Okay, so basically that means that Python support will continue to exist. Nobody has to do any transitions as a result of that. Using that Python central, we're going to work on speccing out the actually added methods. So by Saturday, Python calls should be converted, we should be telling people to upload new stuff. Is that right? Okay, you're faster. Okay, so first let's from my point of view, let's just say that you're all for this good discussion. I think we made a nature set for that. And now the question is do we have other Python topics or have a bottom and a quarter hour of discussions here and after? Yeah. I think it's just enough. You're going to have more Python stuff that you want to discuss about, and this is very important. We have this white code. White code. Okay, white code. I don't get what you mean. By definition we can write speech. By definition we can write speech. Yes. By definition we can write speech. Is there an issue with Mathias? There was a discussion to not know how to optimize white code that was implemented by an example. So that I have a config file which just specifies which white code configuration should be done. Okay. Let's just currently maintain speech. No, do things. Right. That's done. So we have a bottom down installation. It's straight ahead. It needs to be cleaned up. Python itself adds PIC files anywhere it can. I do not think it's a real ideal situation actually. Obviously. Could you describe the problem? I don't think the problem. Are you objecting to the PIC files completely? Not completely because I recognize the need for some certain applications that can benefit the industry from it. But I think that the management of the files are not really optimal. And I mean there's a bottom down population for very few benefits and I think we should make it optional. And definitely make Python itself not add them at run time when you run something. But you're saying that Python when it runs and doesn't find one should be fixed so that it doesn't try to create one. Yes. Okay. That's the problem. It's important that you have different Python versions because if you have one application using one, one application using the other, they'll constantly create one for the other version. This is something that can be entirely done with Python support. It could make the bytecode creation optional and still keep the bytecode removed. So if some program creates the PIC file, it will still be removed. But he's saying that what we need is an interpreter fix so that Python, the program itself when you call it doesn't try to create the bytecode. And as far as the scope of what he has said, I just said what happened with installation is that you just put a package of the same link to different locations. And each interpreter could have his own bytecode file. Right. I think it's not a problem. What you're trying to do is right. Indeed, for us would use the PIC files in a separate directory or like a kind of file cache something. I think you may be misremembering that it's going to know PYO files. Because what happens with those is it tries to build those every time if you're running with optimization options turned on. But Python effectively today doesn't do any optimization. So what happens is it spends its time to optimize it, creates a file which is identical to the OIC that already has, and ends up running slower as a result of that than if it hadn't done it at all. Because it's got more start time. PYC files, I think what we're doing today is pretty good. I don't know. I don't understand the argument because if I stopped the class at the proper time, without minus O, by C toss opposite to O, by S toss opposite to O, minus O, by O toss opposite to O. Right. So let me say some time on package installation. Okay. That's not an un-starting package. So I keep all that. Yeah. I would like to add my support to the terminal change, so that in situations when you really don't want the compiler files, such as in an imperative file, this space is sort of difficult to get. It would be good to be able to have this. But certainly, by default, I think, we should compile Python, by first upon installation. And if Python support can have a compression file somewhere where we can remove this, then how very easy. Yes, very easy. Something that can be ideal. Well done. I haven't really looked to play some of PY205s because as Steve explained, they are not used, they are used, but they are not useful. So by not creating these files, we are affecting people who run Python minus O. But anyway, there's no point in using this option because there are no optimizations. If somebody wants to compile or compile by compile, it's Python fast with minus O. You can do it. That's why there are still people who see changes from PY205. Right. I think it would be great to have a user configurable when you want a BIC file. I mean, BIO, I think this issue is in these non-atticions and more. That's already solved with the BIC files. And well, if nobody else thinks they have lost us, I think that the general, the common case that we want to optimize for is that we do want the PYC files to be pre-compiled to save the start of time. That's the common case. And if I find support in that option, I'll let you skip writing those out as compacted install. Can we also get the small interpreter fix to not save the BIC file when the programmers are run normally? In case they ever have a root user who ever runs a Python program. Mattias, what do you think about it? The thing now is if somebody does go and remove the PYC files because they don't want them on their system, if somebody runs a Python program at root, the PYC files are free. Is that a change that can be made to Python that you would agree with? Does someone need to file a file? Well, if you do that change, well, I think it's... I don't see a little benefit. I don't want... If I have a situation like a very, very poor computer that I don't want the Python program and I don't want the classes to be changed, that doesn't mean I don't have programs. There's one very old patch which allows compilation or writing of the BIC files in another location. I'm not sure if that can be modified to not have all BIC files. I would prefer it if it's accepted upstream first and then take it over to the devian. Thank you. I think there's an argument to say it's good upstream first but such a change is reasonable. And should perhaps be smart to limit itself to only slash user the ifile because if an administrator or someone who tests in one other direction you probably want to maintain the default behavior to not divert too much from upstream and limit it to the devian packages itself the devian packages which have the option to have BIC files if the administrator wishes so via Python support. So that is configurable whether you want BIC files during installation time and that the Python interpreter will not create them anyway if you indicate that you do not want them but that the behavior is the same for non-packaged Python files. Now I have another question here. I can see a few people who are just about to get up and go out. My question is, do we need to discuss if this is full out so you see how to get over here? What's up? You okay? I think it will be in 5 minutes or something. Okay, I think we should give some people who want to get all the chance to do it before I said discontinue. Is there anything you would like to say about the work that you are doing? Well, one last thing is we would prefer to only have to support one packaging 8 so let's make it either Python support or either Python support. I don't think there are two things two implementations which do the same thing and well, I don't mind I just try to complete a simple implementation because I didn't see any progress with Python support implementation so I have no problems to drop Python Central but it should be a complete implementation so it sounds like I can support everything with Python I'm taking information from the control fields and central roles I don't have any concerns Python will reduce I think because everything is requested we can see models and we say we just have one solution one implementation so they are the version There is a need for supporting cc user Python support Yes but the provider at the DH Python developer so DH Python would have to generate a new Python provider although there is one thing Python support is missing is support from Python 2.x packages for example when Python 2.4 is installed for the first time it has a different for the first time it has to signal Python support that hey I'm here so you can build your modules for that new version the interpreter packages do not have hopes for Python so installing a new interpreter is not generating just a matter of coding update Python modules help any arguments in the post installation and post removal scripts you have to keep your own files that's ugly but we didn't talk about I think it's better we have some information and we should use that information in our packaging system which we have in our packaging system Does this come back to the part where we talked about using the package to query versions from inside to maintain a script yeah hey you need books okay so we are done we all agree that we can make Python 2.4 migration before implementing all of this because it will take some time sorry I know the things that can you show your work on people's what do you do yeah for my master I will try to my understanding it's a good idea to summarize this discussion again my understanding of what we discussed here is that we have a solution that is nice for the long term where Steve and Doku volunteer to maintain and then I volunteer to kick set to do to make sure that it exists in first so I am intended to make sure that we do it this week so if it happens this week and I don't think that it's a bad decision then we are fast enough and if not we can still reconcile it but my understanding is that we are near enough to make tweaks in some days so it could be quite fast is this understanding correct? it sounds like we have a pretty strong consensus on what the solution is supposed to be and then I would like to try to save the effort needed for an old-style Python 4.0 solution and if it doesn't work we can still reconcile what to do if it breaks but we have to do that anyways if we have some idea what we are going to do for the release schedule if it breaks what do we do now but the worst thing is we want to fix it are you saying that having the false change should be delayed if all we work on this to be more specific how about we say that we work on this this week then we will hope how we are and we don't review how far we are by the week after the death conference finished we start the 2.4 transition and if Python Central is not working we keep doing the current thing but Python Central shouldn't be working we should be able to do it in Python support if we can merge it too that's great if we have two separate things that work the same way then but but ok our vision is that we will do a sort of Python 4.0 solution with Python Central and if it doesn't work we will merge it all with something like that yes right but I don't think we have to forward I don't think we will do that well I hope that we can do it with Python Central so it's our so when will the Python defaults change actually because I don't want to get in a situation where we have lots of Python packages that have to be transitioned and know what was being done on them and convert them to Python support well let's go on Python let's upload to the repository so that package maintainer actually can start converting their packages so we have some more test cases and then well do the transition maybe not do the transition everyone's got a backup but Python Central I just want to make sure we don't have a realistic requirement that 80% of Python packages must be converted before we start the Python 2.4 transition because then it's like no the transition is happening the maintainer is going to get off their butts and get this done basically I understand that if packages have to be touched they would have been touched for an old style to 4th transition anyways so that's in the last little piece of work which is okay I think so we both see is there only a benefit to be switched on to 2.4 to 2.5 but maybe not now but that's okay because more of these packages will be able to move in the testing and we don't write a split package for transitioning before if we disentangle the transition so you may say that we both see it but Steve, H.A. and I will see it either way with the new Python model team we can always convert packages even when we have nothing special to do we don't even have a new Python version but I think we are done we have a lot of things to work this cast elsewhere thanks a lot for coming in for this good discussion