Phillip J. Eby schrieb:
> At 11:50 PM 3/12/2007 +0100, Martin v. Löwis wrote:
>>Does distutils support this kind of setup? Modules/Setup?
>
> distutils does, and has from its inception, as far as I know.
>
>
>>IOW, I would expect that there are sooo many places where extension
>>modules in packa
At 11:50 PM 3/12/2007 +0100, Martin v. Löwis wrote:
>Does distutils support this kind of setup? Modules/Setup?
distutils does, and has from its inception, as far as I know.
>IOW, I would expect that there are sooo many places where extension
>modules in packages are not supported
The only thing
On Monday 12 March 2007 4:50:17 pm Martin v. Löwis wrote:
> Does distutils support this kind of setup?
Yes, and it has since its introduction. Just use the dotted name for the
extension name.
> IOW, I would expect that there are sooo many places where extension
> modules in packages are not sup
Martin v. Löwis wrote:
> I couldn't tell off-hand whether having
> extension modules in a package would even work
It's quite common for a third-party package to consist
of some Python code and some extension modules, with
the extension modules living inside the package
namespace. It works fine.
-
Hi Martin,
On Mon, Mar 12, 2007 at 11:50:17PM +0100, "Martin v. L?wis" wrote:
> Does distutils support this kind of setup? Modules/Setup?
distutils does, and I can find many projects which require a combination
of C and Python modules being organized as a single package with the
extension modules
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 pro
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, an
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 *
>
>
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
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
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
___
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 UNI
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 seem
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, le
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
benef
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 d
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. Wh
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
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
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 buil
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,
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
> 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
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/?fun
> As I am completely new to CPython development, perhaps this problem has
> already been discussed and/or fixed I may have done something
> incorrectly. Please let me know if that is the case.
I looked at it briefly. If I understand correctly, the proposed feature
is fine, but lacks a test case.
Miguel Lobo schrieb:
> As I am completely new to CPython development, perhaps this problem has
> already been discussed and/or fixed I may have done something
> incorrectly. Please let me know if that is the case.
I looked at it briefly. If I understand correctly, the proposed feature
is fine,
Hi list,
A month and a half ago, I submitted patch 1644818 to the CPython Patch
Tracker:
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1644818&group_id=5470
On several occassions I have been advised to mention the patch in this list,
so here it is:
The problem: Importing built-i
27 matches
Mail list logo
