thon-2.5, but it a month and a half ago it was
applicable to the svn trunk with only a one-line offset.
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
> 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.
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
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
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
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
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
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
___
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
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
> I think we should not do this. We should use 4 space indents for new
> files, but existing files should not be reindented. If you reindent,
> much of the history of the file is essentially lost -- "svn blame"
> will blame whoever reindented the code, and it's a pain to go back.
I believe "svn bl
11 matches
Mail list logo
