Re: [Python-Dev] Patch 1644818: Allow importing built-in submodules
For me, the personal benefit of getting a patch applied would be so that I didn't have to keep re-applying it to new versions of Python, and that I could distribute code relying on the patch to others without requiring *them* to use a patched version of Python as well. What you describe is probably fairly common, but in this particular case, the patch is only needed if you are going to build a bespoke Python interpreter. This is a complicated enough process that the difficulty of having to apply a patch is probably insignificant. The potential savings of this patch lay mainly in avoiding the waste of time for people who will face the same problem and not understand why. As anecdotal evidence, just a couple of days after I had figured out what the problem was and had the patch ready, another guy found the same problem completely independently and posted some questions to the PyQt development list about it. Regards, Miguel ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Patch 1644818: Allow importing built-in submodules
Miguel Lobo wrote: > In fact I'm probably the person the > patch will benefit least, because I have already run into the problem > and know how to solve it. For me, the personal benefit of getting a patch applied would be so that I didn't have to keep re-applying it to new versions of Python, and that I could distribute code relying on the patch to others without requiring *them* to use a patched version of Python as well. -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Patch 1644818: Allow importing built-in submodules
Miguel Lobo schrieb:
> Perhaps one example would help to clarify what I mean. I see that there
> is an xml.parsers.expat module, with the following content:
>
>
>
> """Interface to the Expat non-validating XML parser."""
> __version__ = '$Revision: 17640 $'
>
> from pyexpat import *
>
>
>
> Then, there is a pyexpat.c module in Modules, which provides the
> contents for the aforementioned xml.parsers.expat.
>
> Wouldn't it be simpler and less invasive of the user's namespace if the
> Python module at xml.parsers.expat was removed, and pyexpat.c declared a
> module name of "xml.parsers.expat" instead?
It certainly wouldn't be simpler: it would break a lot of existing code,
which all assumes that pyexpat is a module that you can import. Also, it
would noticably complicate the build process, which now suddenly needs
to support submodules.
It wouldn't be less invasive, either: "pyexpat" is a name that is really
unlikely to clash ("expat" itself would already provide that guarantee).
As the former PyXML maintainer, I considered that several times, and
always concluded that it should be not be done.
Does distutils support this kind of setup? Modules/Setup?
IOW, I would expect that there are sooo many places where extension
modules in packages are not supported that it is just a tiny detail
that they don't work in builtin modules (which, as I said, only have
top-level modules, anyway).
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Patch 1644818: Allow importing built-in submodules
Normally, the builtin modules are the ones that are shipped in Python core. I know you can get a bigger builtins list through freeze, or through a custom Setup.local, but it is fairly uncommon to do that. Also, having extension modules in a namespace is something that I would normally not do. I couldn't tell off-hand whether having extension modules in a package would even work (but apparently, it does), Well, it quite doesn't, without the patch ;-) so I would make them global modules just to be safe. Also, they normally have a canonical naming: if they wrap a library called libfoo, the extension module would normally be called foo.so or foomodule.so (on a Unix system; foo.pyd on Windows). As DLLs don't have hierarchical names, extension modules don't need hierarchical names, either. Perhaps one example would help to clarify what I mean. I see that there is an xml.parsers.expat module, with the following content: """Interface to the Expat non-validating XML parser.""" __version__ = '$Revision: 17640 $' from pyexpat import * Then, there is a pyexpat.c module in Modules, which provides the contents for the aforementioned xml.parsers.expat. Wouldn't it be simpler and less invasive of the user's namespace if the Python module at xml.parsers.expat was removed, and pyexpat.c declared a module name of "xml.parsers.expat" instead? Regards, Miguel ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Patch 1644818: Allow importing built-in submodules
Miguel Lobo schrieb: > It won't benefit the Python core either, because we just don't use > builtin submodules. In fact, I find the notion of builtin submodules > somewhat strange. > > > Please excuse my curiosity, but why do you find it strange? Normally, the builtin modules are the ones that are shipped in Python core. I know you can get a bigger builtins list through freeze, or through a custom Setup.local, but it is fairly uncommon to do that. Also, having extension modules in a namespace is something that I would normally not do. I couldn't tell off-hand whether having extension modules in a package would even work (but apparently, it does), so I would make them global modules just to be safe. Also, they normally have a canonical naming: if they wrap a library called libfoo, the extension module would normally be called foo.so or foomodule.so (on a Unix system; foo.pyd on Windows). As DLLs don't have hierarchical names, extension modules don't need hierarchical names, either. Putting these two boundary cases (additional builtin modules, and modules in packages) is something that I find unlikely to run into. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python-3000 upgrade path
On 3/6/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > On 10:22 pm, [EMAIL PROTECTED] wrote: [snip] > >I'm hoping Collin will continue his excellent work on 2to3. Hopefully > >he'll get help from others in writing docs aimed at teaching the > >c.l.py crowd how to use it and what to expect. > > I'm sure he'll hear from me if anything goes wrong with it :). I've started work on "Capabilities" and "Limitations" sections for the 2to3 README: http://svn.python.org/view/sandbox/trunk/2to3/README?view=markup. I intend for them to provide a comprehensive look at what 2to3 can and can't do. Collin Winter ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fwd: Re: [Python-3000] Removing functions from the operator module
Hi Collin, On Mon, Mar 12, 2007 at 11:19:26AM -0500, Collin Winter wrote: > iter() is part of every syntactic construction that takes an iterator > argument (for, listcomps, gencomps, ...). Should it go in operator as > well? Historically, things that have a slot go in 'operator'. So that would mean that 'operator' is missing at least: getattr, setattr, delattr, next, repr, str, len, hash, hex, oct, divmod, int, float, long, descr_get, descr_set, descr_delete, getslice, setslice, delslice, call, init. Or else, things in 'operator' are the ones with a "syntactic equivalent". Then we should remove abs and index, and add list, tuple, dict, buildclass, new.function, ... Then there is stuff that doesn't fall in any category, like attrgetter, countOf, indexOf, ... Not-completely-useful'y-yours, Armin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fwd: Re: [Python-3000] Removing functions from the operator module
Yes. On 3/12/07, Collin Winter <[EMAIL PROTECTED]> wrote: > On 3/11/07, Armin Rigo <[EMAIL PROTECTED]> wrote: > > Hi Collin, > > > > On Wed, Mar 07, 2007 at 11:53:45PM -0600, Collin Winter wrote: > > > bool() and abs() aren't syntax, so I would never look in operator. > > > > abs() is not syntax but bool() is part of every syntactic construction > > that takes a truth value argument (if, while, and, ...) > > iter() is part of every syntactic construction that takes an iterator > argument (for, listcomps, gencomps, ...). Should it go in operator as > well? > > Collin Winter > ___ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/guido%40python.org > -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Patch 1644818: Allow importing built-in submodules
It won't benefit the Python core either, because we just don't use builtin submodules. In fact, I find the notion of builtin submodules somewhat strange. Please excuse my curiosity, but why do you find it strange? P.S. Thanks to all for the considerate responses. Regards, Miguel ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Import APIs
IMHO yes, for all occurences in the core code. Guido van Rossum schrieb: > what's the situation for Py3k? Should it always use absolute import there? > > On 3/10/07, Georg Brandl <[EMAIL PROTECTED]> wrote: >> Currently, all C code that needs to import a module uses >> PyImport_ImportModule which >> (1) calls __builtin__.__import__ >> (2) attempts relative imports >> >> Most of the time, though, at least (2) is wrong. >> If we want to keep (1), PyImport_ImportModuleLevel can't be >> used as a replacement. >> So there should be a new API, called PyImport_ImportAbsolute >> that gets a flag whether relative import should be allowed. >> >> Georg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Patch 1644818: Allow importing built-in submodules
Miguel Lobo schrieb: > I need to integrate the extra test file into a project file (probably > pythoncore). > > > The change to pythoncore.vcproj is already in the patch I posted. > Otherwise I wouldn't have been able to run my test under Windows. Ah, ok, I misremembered. It is the UNIX build process that is still lacking, then. > Yet, the same can be said for most other patches: they are all for the > benefit of users running into the same respective problems. > > > Agreed. What I mean is that this fasttrack system where the submitter > has to do some extra work seems to imply that accepting the patch > somehow benefits the submitter. That's true. If there is no benefit for the submitter, the submitter will likely not use that procedure. People have various motives for contributing: scratch-your-own-itch, gain reputation, ... For people that actually do have an interest in their patch being integrated, this offer (and it is just an offer) may be interesting. > In fact I'm probably the person the > patch will benefit least, because I have already run into the problem > and know how to solve it. It won't benefit the Python core either, because we just don't use builtin submodules. In fact, I find the notion of builtin submodules somewhat strange. > I feel responsible for defending the patch > since I've written it and I know the problem it fixes and my solution > better than anybody else, but I don't see how that responsibility > extends to having to do extra unrelated work to have the patch accepted. At this point, there is relatively little that you can do, as you cannot control the priority and the time that people are willing to review and integrate patches. So you either need to be patient until some reviewer picks it up, or you need to involve yourself further into Python. > I'm not complaining or anything, and no offence meant to anyone, just > explaining my point of view. I might still try to do the 5 patch review > thing, depending on how long it takes me. But if I choose not to do so, > leaving my patch to rot only harms CPython, not me. Understood. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Patch 1644818: Allow importing built-in submodules
On 3/12/07, Miguel Lobo <[EMAIL PROTECTED]> wrote: > > Yet, the same can be said for most other patches: they are all for the > > benefit of users running into the same respective problems. > > Agreed. What I mean is that this fasttrack system where the submitter has > to do some extra work seems to imply that accepting the patch somehow > benefits the submitter. In fact I'm probably the person the patch will > benefit least, because I have already run into the problem and know how to > solve it. I feel responsible for defending the patch since I've written it > and I know the problem it fixes and my solution better than anybody else, > but I don't see how that responsibility extends to having to do extra > unrelated work to have the patch accepted. It is certainly not your _responsibility_ to review additional patches to get your accepted; without doing so, it likely will be accepted, eventually (assuming it is correct). As far as I understand, Martin's offer is purely a personal one: there is a patch backlog, and if you help clear it out, he will help your patch get processed faster. cheers, -Mike ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python-3000 upgrade path
Absolutely right. I'll withdraw the lightweight version. It's done
enough damage.
On 3/11/07, Andrew McNamara <[EMAIL PROTECTED]> wrote:
> >I wrote two versions of the dict views refactoring. One that turns
> >d.keys() into list(d.keys()) and d.iterkeys() into iter(d.keys()).
> >This one is pretty robust except if you have classes that emulate
> >2.x-style dicts. But it generates ugly code. So I have a
> >"light-weight" version that leaves d.keys() alone, while turning
> >d.iterkeys() into d.keys(). This generates prettier code but more
> >buggy. I probably should have used the heavy-duty one instead.
>
> The ugliness is a virtue in this case as it stands out enough to motivate
> developers to review each case. The pretty/efficient version is tantamount
> to guessing, and effectively discards information in the transformation
> ("here be dragons").
>
> --
> Andrew McNamara, Senior Developer, Object Craft
> http://www.object-craft.com.au/
>
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Patch 1644818: Allow importing built-in submodules
On Mon, Mar 12, 2007 at 07:20:56PM +0100, Miguel Lobo wrote: >I'm not complaining or anything, and no offence meant to anyone, just >explaining my point of view. I might still try to do the 5 patch >review thing, depending on how long it takes me. But if I choose not >to do so, leaving my patch to rot only harms CPython, not me. Miguel, last week there was a lengthy conversation on this list on this exact topic. Your point of view, which I hold to be very common, came up a few times, but thanks for stating it so clearly! Dustin P.S. Please note I am *not* trying to re-open that conversation ;-) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Patch 1644818: Allow importing built-in submodules
I need to integrate the extra test file into a project file (probably pythoncore). The change to pythoncore.vcproj is already in the patch I posted. Otherwise I wouldn't have been able to run my test under Windows. Yet, the same can be said for most other patches: they are all for the benefit of users running into the same respective problems. Agreed. What I mean is that this fasttrack system where the submitter has to do some extra work seems to imply that accepting the patch somehow benefits the submitter. In fact I'm probably the person the patch will benefit least, because I have already run into the problem and know how to solve it. I feel responsible for defending the patch since I've written it and I know the problem it fixes and my solution better than anybody else, but I don't see how that responsibility extends to having to do extra unrelated work to have the patch accepted. I'm not complaining or anything, and no offence meant to anyone, just explaining my point of view. I might still try to do the 5 patch review thing, depending on how long it takes me. But if I choose not to do so, leaving my patch to rot only harms CPython, not me. Regards, Miguel ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Import APIs
what's the situation for Py3k? Should it always use absolute import there? On 3/10/07, Georg Brandl <[EMAIL PROTECTED]> wrote: > Currently, all C code that needs to import a module uses > PyImport_ImportModule which > (1) calls __builtin__.__import__ > (2) attempts relative imports > > Most of the time, though, at least (2) is wrong. > If we want to keep (1), PyImport_ImportModuleLevel can't be > used as a replacement. > So there should be a new API, called PyImport_ImportAbsolute > that gets a flag whether relative import should be allowed. > > Georg > > ___ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/guido%40python.org > -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Patch 1644818: Allow importing built-in submodules
Miguel Lobo schrieb: > My own patch does not include documentation. I assume documentation > would only be needed for patches that add new functionality (as opposed > to fixing problems)? Typically, yes. If the bug fix would also change the behavior of existing programs, that change should be documented through the \versionchanged markup. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fwd: Re: [Python-3000] Removing functions from the operator module
On 3/11/07, Armin Rigo <[EMAIL PROTECTED]> wrote: > Hi Collin, > > On Wed, Mar 07, 2007 at 11:53:45PM -0600, Collin Winter wrote: > > bool() and abs() aren't syntax, so I would never look in operator. > > abs() is not syntax but bool() is part of every syntactic construction > that takes a truth value argument (if, while, and, ...) iter() is part of every syntactic construction that takes an iterator argument (for, listcomps, gencomps, ...). Should it go in operator as well? Collin Winter ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] [ 1673007 ] urllib2 requests history + HEAD support
This patch was posted by "koder_ua". I think that Request must have a "request type" parameters, so people can send "HEAD" requests easily. But it seems to me that keeping a request history in the module is bad, because it can easily grow up to thousands and explode (a.k.a. consume too much memory). Fo example, I have a web service, running 7x24, and opening another web service, with around 10 requests per second. This means, keeping the history (around 50bytes each request), 1.2 GB of RAM in only a month! So, I'll close this patch as "Rejected", for this reason, if anyone raises objections. Regards, -- . Facundo . Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Patch 1644818: Allow importing built-in submodules
Miguel Lobo schrieb: > Personally, I can't apply it as-is right now, since a) I would have to > check that the test case conditionalization works fine, and b) I would > have to come up with a patch for the Windows build process. > > > Sorry, I couldn't understand the second point. Why would you have to > patch the Windows build process? I need to integrate the extra test file into a project file (probably pythoncore). > Well, it's not really my place to ask that this patch is prioritised > above others, since as I said if I'm asking for its inclusion it is in > order to benefit other Python users who may easily hit the same > problem. Yet, the same can be said for most other patches: they are all for the benefit of users running into the same respective problems. > Anyway, I'm intrigued about this "review 5 other patches" procedure you > suggest. What exactly would be involved in such a review? Please note > that I hadn't touched CPython code before I wrote my patch and I haven't > been following CPython development closely. There are a number of mostly mechanical steps that should be applied to any patch that hasn't seen these steps done yet: - is it clear what the objective of the patch is? If not, complain to the submitter that they should clarify what problem precisely they try to solve. - if so, does the patch actually achieve that objective? If not, complain to the submitter that the stated objective and the implemented change differ. To determine that, you can either * review the code, to see how it fixes the problem, or * run the code, to verify that it actually does change the problem for the cases tested In your review, state which of these approaches you've used. - As the result of the previous step, it may be that you find that the patch is out-of-date. If so, state that in the report. - Does the patch come with test suite changes, if it changes observable behavior? (irrelevant only for pure documentation changes) - Does the patch come with documentation changes (patches to the Doc directory)? These can be waived only for mere bug fixes (e.g. when the documented behavior already states what the patch achieves) - Does the patch include unnecessary changes, or combine multiple changes in a single one? That should normally not be done. When you have all this information collected, write a brief message into the report indicating what your conclusions are. Ideally, conclude with one of the following recommendations: - accept - reject - "conditional accept", i.e. needs more work, if so, state what that work would be. When you have dealt with 5 reports that way, post a summary message here what reports you've looked at, what your conclusion is, and what patch you want to see expedite processing for. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Patch 1644818: Allow importing built-in submodules
This is how we suck you in... ;) I see :-). Funny I didn't see this procedure mentioned in the patch submission guidelines ;-) You don't have to be an expert to review patches. The following procedure would qualify you: 1. Find a patch that it appears no one has ever touched (0 comments, assigned to nobody, etc.) 2. Pretty much every patch should include a unit test and documentation. If something is missing from the patch you're looking at, post a comment that says "Incomplete, no docs/tests". My own patch does not include documentation. I assume documentation would only be needed for patches that add new functionality (as opposed to fixing problems)? 3. Repeat until you've commented on five patches. If you find such clerical work beneath you, you can go further--build Python from source, apply patches, and verify that they work. It's not hard (google "python developer faq"). But it's not required. I might try to do this, as time permits. Regards, Miguel ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Patch 1644818: Allow importing built-in submodules
On 3/12/07, Miguel Lobo <[EMAIL PROTECTED]> wrote: > Anyway, I'm intrigued about this "review 5 other patches" procedure you > suggest. What exactly would be involved in such a review? Please note that > I hadn't touched CPython code before I wrote my patch and I haven't been > following CPython development closely. Hi Miguel, This is how we suck you in... ;) You don't have to be an expert to review patches. The following procedure would qualify you: 1. Find a patch that it appears no one has ever touched (0 comments, assigned to nobody, etc.) 2. Pretty much every patch should include a unit test and documentation. If something is missing from the patch you're looking at, post a comment that says "Incomplete, no docs/tests". 3. Repeat until you've commented on five patches. If you find such clerical work beneath you, you can go further--build Python from source, apply patches, and verify that they work. It's not hard (google "python developer faq"). But it's not required. -j ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Patch 1644818: Allow importing built-in submodules
Personally, I can't apply it as-is right now, since a) I would have to check that the test case conditionalization works fine, and b) I would have to come up with a patch for the Windows build process. Sorry, I couldn't understand the second point. Why would you have to patch the Windows build process? If you want to prioritize it over the other 300 patches, I can offer you a fast-track procedure if you in turn review 5 other patches. Well, it's not really my place to ask that this patch is prioritised above others, since as I said if I'm asking for its inclusion it is in order to benefit other Python users who may easily hit the same problem. As far as I'm concerned personally, I have no problem at all applying the patch manually. Anyway, I'm intrigued about this "review 5 other patches" procedure you suggest. What exactly would be involved in such a review? Please note that I hadn't touched CPython code before I wrote my patch and I haven't been following CPython development closely. Regards, Miguel ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Patch 1644818: Allow importing built-in submodules
Miguel Lobo schrieb: > Also, seeing that there are almost 400 open patches in the patch > tracker, I'm concerned that this patch will be forgotten and left to > rot, which would be a pity IMO. Of course, the submitters of the 300 other patches say the same. It is just too difficult to catch up, so yes, there is a high chance that it will rot for a while. Personally, I can't apply it as-is right now, since a) I would have to check that the test case conditionalization works fine, and b) I would have to come up with a patch for the Windows build process. This requires considerably more time than it requires to write this message. If you want to prioritize it over the other 300 patches, I can offer you a fast-track procedure if you in turn review 5 other patches. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Patch 1644818: Allow importing built-in submodules
No; basically, you just need to be patient now. Do you have an urgent need to get this patch included? Well, not personally, but I suspect that it is quite possible that other people will waste time trying to figure out why their imports don't work. Also, seeing that there are almost 400 open patches in the patch tracker, I'm concerned that this patch will be forgotten and left to rot, which would be a pity IMO. One issue is whether this patch should be backported to the 2.5 branch; as it is arguably a new feature, it probably should not. As 2.6 is still quite some time ahead, I can't see any urgency. I see this more as a fix rather than a new feature, as there is no reason or explanation in the documentation (that I've been able to find) to suggest that importing built-in submodules shouldn't work. The small changes to the code in the patch also "feel" more like a fix than like a new feature. So yes, ideally I would like to see this patch in 2.5.1, although I will of course defer to the people who are in charge of making that decision. Regards, Miguel ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Patch 1644818: Allow importing built-in submodules
> Sorry for the repetition, but since nobody has commented on patch > 1644818 for about a week I thought perhaps I should ask again. > > Is there anything I need to do before the patch is ready for inclusion? No; basically, you just need to be patient now. Do you have an urgent need to get this patch included? One issue is whether this patch should be backported to the 2.5 branch; as it is arguably a new feature, it probably should not. As 2.6 is still quite some time ahead, I can't see any urgency. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Patch 1644818: Allow importing built-in submodules
Hi list, Sorry for the repetition, but since nobody has commented on patch 1644818 for about a week I thought perhaps I should ask again. Is there anything I need to do before the patch is ready for inclusion? As a remainder, this patch (which can be seen at https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1644818&group_id=5470 ) fixes built-in submodules. At the moment importing built-in submodules does not work whether the parent submodule is itself built-in, a normal module or a frozen module. This small patch fixes all three cases and has been tested to work under Windows. This is useful for example with the PyQt project, which provides a package called PyQt4 containing a number of extension modules (PyQt4.QtCore, PyQt4.QtGui, etc). It should be possible to create a bespoke Python interpreter that has these extensions statically linked, but without this patch importing these extensions fails in such an interpreter. Regards, Miguel ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python version incorrect on website?
Rajstennaj Barrabas schrieb: > I have an application which runs on 2.4.4 and is known not to run on 2.4.1 or > 2.5, and I'm trying to install 2.4.4 from the website. > > Whenever I download and compile the 2.4.4 sources, the executable shows up as > 2.4.1 which will not work for my application. > > I've downloaded both the bzip and gzip versions, and checked the MD5 sums as > posted on the website, but the 2.4.4 system still shows 2.4.1 when run. The > local file "buildno" contains the number "1", and the command ./python -V > returns the string 2.4.1. > > (Linux 2.6.8-2-686, everything is apt-get "current". I'm downloading the > source > tar files because apt-get doesn't have the version I need.) > > Is there a mismatch on the python website? It would have helped if you had reported what the precise URL was that you downloaded, and what precise md5sum you got. I can confirm that the official URL for Python 2.4.4 is http://www.python.org/ftp/python/2.4.4/Python-2.4.4.tar.bz2 and the official md5sum of that is 0ba90c79175c017101100ebf5978e906 Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Backports of standard library modules
[EMAIL PROTECTED] schrieb: > This does raise an interesting question, though, since I'm about to get > into PEP authorship myself. Have I missed an official way to propose > alternatives or resurrect a languishing PEP? See PEP 1. The PEP champion is obliged to integrate feedback into the PEP, to avoid repeated discussions. If the PEP champion is unresponsive, I think that ownership should be transferred to a new champion, although PEP 1 doesn't explain how this should happen. Historically, champions who lost interest were always willing to transfer ownership. If the champion merely records negative feedback without actually changing the proposal, you can come up with a counter-proposal, as a separate PEP. For example, I wrote PEP 244 to counter PEP 236. Clearly, one of them will get rejected eventually in favor of the other. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Backports of standard library modules
Patrick Maupin schrieb: > Although it is often quite easy to find and download a module for use > with a prior version of Python, it would be really convenient if all > of these modules were bundled up together and available as a single > download, especially when it comes to Windows users and extension > modules. I don't know how precisely you imagine this to happen: there is clearly zero chance that a future 2.5.x release (say, 2.5.2) will include modules that are about to appear with 2.6 only. If you think of an independent release: who should produce it? I would not expect that any of the current release people are willing to take more load (I know that I wouldn't); so it clearly needs more volunteers. Given the past experience with such proposals (e.g. creation of a Jumbo distribution), I'm skeptical that volunteers will materialize (unless, of course, you are volunteering). If it is indeed you who would volunteer, I'd suggest that you don't have to go through a PEP process. Instead, just do it: bundle the modules that you want to see in earlier Python versions, and publish it. If you want to see it appear on python.org, that could certainly be arranged. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
