It is a surprise to find builtin msilib. Why isn't it used?
Originally, because Python needs to be packaged with an older
release (in particular one that isn't itself maintained anymore).
Today, the problem is that the msilib package doesn't support
merge modules (and if such support was added,
On Wed, Feb 2, 2011 at 10:36 AM, Martin v. Löwis mar...@v.loewis.de wrote:
It is a surprise to find builtin msilib. Why isn't it used?
Originally, because Python needs to be packaged with an older
release (in particular one that isn't itself maintained anymore).
That doesn't answer the
On Tue, Feb 1, 2011 at 5:35 PM, anatoly techtonik techto...@gmail.com wrote:
Because code cleanup patches pave road for more complex pieces of
work. Clean code makes patches easier to review. It saves developer's
time and as a result useful patches are integrated into codebase more
quickly.
On Tue, Feb 1, 2011 at 01:35, anatoly techtonik techto...@gmail.com wrote:
On Tue, Feb 1, 2011 at 12:59 AM, Benjamin Peterson benja...@python.org
wrote:
I see no reason for b.p.o bureaucracy.
It provides a place for discussion, and makes it easier to coordinate
multiple efforts.
On Tue, Feb 1, 2011 at 1:38 AM, Nick Coghlan ncogh...@gmail.com wrote:
On Tue, Feb 1, 2011 at 7:58 AM, anatoly techtonik techto...@gmail.com wrote:
To me polluting tracker with the
issues that are neither bugs nor feature requests only makes bug
triaging process and search more cumbersome.
2011/2/1 anatoly techtonik techto...@gmail.com:
we can definitely
find a lot of ways to improve Python development process for general
public
Definitely. And the future migration to Mercurial will certainly help as well.
But this thread started with a patch review, not with a proposal to
On Tue, Feb 1, 2011 at 09:51, anatoly techtonik techto...@gmail.com wrote:
On Tue, Feb 1, 2011 at 1:38 AM, Nick Coghlan ncogh...@gmail.com wrote:
On Tue, Feb 1, 2011 at 7:58 AM, anatoly techtonik techto...@gmail.com
wrote:
To me polluting tracker with the
issues that are neither bugs nor
On 2011-02-01, at 4:51 PM, anatoly techtonik wrote:
I'll abandon my efforts when you prove me that current documented
process is a top-notch way for all interested parties to do a quality
contributions to make Python better. So that the process is open,
straightforward, transparent and
anatoly techtonik writes:
I'll abandon my efforts when you prove me that current documented
process is a top-notch way for all interested parties to do a quality
contributions to make Python better.
I think the product of the process speaks very well for the process.
The most valuable
On 2011/02/01 07:22:57, techtonik wrote:
It removes the dependency from msi.py making it easier to do the rest
in
subsequent patches.
What rest specifically? Why are the msilib changes needed for that?
http://codereview.appspot.com/4080047/
___
Am 01.02.2011 16:51, schrieb anatoly techtonik:
On Tue, Feb 1, 2011 at 1:38 AM, Nick Coghlan ncogh...@gmail.com wrote:
On Tue, Feb 1, 2011 at 7:58 AM, anatoly techtonik techto...@gmail.com
wrote:
To me polluting tracker with the
issues that are neither bugs nor feature requests only makes
On 02/01/2011 09:51 AM, anatoly techtonik wrote:
So far only Georg explained what patches sent to mailing list will not
be reviewed, because there is too much volume. But bugtracker is not a
patch tracker. It doesn't allow to monitor incoming patches by module,
its search is very poor. Of
On 2011/02/01 19:50:23, Martin v. Löwis wrote:
On 2011/02/01 07:22:57, techtonik wrote:
It removes the dependency from msi.py making it easier to do the
rest in
subsequent patches.
What rest specifically? Why are the msilib changes needed for that?
The rest is to use ctypes, so that no
On 2011/02/02 07:14:17, techtonik wrote:
On 2011/02/01 19:50:23, Martin v. Löwis wrote:
On 2011/02/01 07:22:57, techtonik wrote:
It removes the dependency from msi.py making it easier to do the
rest in
subsequent patches.
What rest specifically? Why are the msilib changes needed for
On 2011/02/02 07:18:33, Martin v. Löwis wrote:
Ah. That shouldn't be done. If anything is to be done, the builtin
msilib can be
considered, instead. Given the choice of using either ctypes or an
external
package, I prefer the external package.
It is a surprise to find builtin msilib. Why
On 2011/02/02 07:32:02, techtonik wrote:
[...]
Can you PLEASE take this off python-dev and move to an issue at
bugs.python.org? At least remove python-dev from the CC, or we'll
have to temporarily block messages from codereview.
http://codereview.appspot.com/4080047/
Reviewers: ,
Please review this at http://codereview.appspot.com/4080047/
Affected files:
M Tools/msi/msi.py
M Tools/msi/msilib.py
Index: Tools/msi/msi.py
===
--- Tools/msi/msi.py(revision 88279)
+++
Hi,
2011/1/31 techto...@gmail.com:
Reviewers: ,
Please review this at http://codereview.appspot.com/4080047/
[...]
It looks good, but did you create an item in the issue tracker?
--
Amaury Forgeot d'Arc
___
Python-Dev mailing list
Is there a bugs.python.org issue for this?
http://codereview.appspot.com/4080047/
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
There is no b.p.o issue as it's not a bug, but a tiny copy/paste patch
to clean up the code a bit while I am trying to understand how to add
Python to the PATH.
I see no reason for b.p.o bureaucracy. Mercurial-style workflow [1] is
more beneficial to development as it doesn't require switching
On Mon, Jan 31, 2011 at 14:45, techto...@gmail.com wrote:
There is no b.p.o issue as it's not a bug, but a tiny copy/paste patch
to clean up the code a bit while I am trying to understand how to add
Python to the PATH.
I see no reason for b.p.o bureaucracy. Mercurial-style workflow [1] is
On Mon, 31 Jan 2011 20:45:45 +
techto...@gmail.com wrote:
I see no reason for b.p.o bureaucracy. Mercurial-style workflow [1] is
more beneficial to development as it doesn't require switching from
console to browser for submitting changes.
Ok, why don't you contribute to Mercurial instead?
Am 31.01.2011 21:45, schrieb techto...@gmail.com:
There is no b.p.o issue as it's not a bug, but a tiny copy/paste patch
to clean up the code a bit while I am trying to understand how to add
Python to the PATH.
I see no reason for b.p.o bureaucracy. Mercurial-style workflow [1] is
more
techto...@gmail.com wrote:
I see no reason for b.p.o bureaucracy.
It provides a place for discussion, and makes it easier to coordinate
multiple efforts.
~Ethan~
___
Python-Dev mailing list
Python-Dev@python.org
On Mon, Jan 31, 2011 at 11:09 PM, Ethan Furman et...@stoneleaf.us wrote:
techto...@gmail.com wrote:
I see no reason for b.p.o bureaucracy.
It provides a place for discussion, and makes it easier to coordinate
multiple efforts.
Code review system provides a better space for discussion if we
On Mon, Jan 31, 2011 at 10:58 PM, Georg Brandl g.bra...@gmx.net wrote:
Am 31.01.2011 21:45, schrieb techto...@gmail.com:
There is no b.p.o issue as it's not a bug, but a tiny copy/paste patch
to clean up the code a bit while I am trying to understand how to add
Python to the PATH.
I see no
2011/1/31 anatoly techtonik techto...@gmail.com:
On Mon, Jan 31, 2011 at 11:09 PM, Ethan Furman et...@stoneleaf.us wrote:
techto...@gmail.com wrote:
I see no reason for b.p.o bureaucracy.
It provides a place for discussion, and makes it easier to coordinate
multiple efforts.
Code review
On Tue, Feb 1, 2011 at 7:58 AM, anatoly techtonik techto...@gmail.com wrote:
To me polluting tracker with the
issues that are neither bugs nor feature requests only makes bug
triaging process and search more cumbersome.
Anatoly, your constant efforts to try to force python-dev to adapt to
What's the rationale of this change? It certainly doesn't remove the
dependency from win32com.client (i.e. the code continues to depend on
win32com).
http://codereview.appspot.com/4080047/
___
Python-Dev mailing list
Python-Dev@python.org
It removes the dependency from msi.py making it easier to do the rest in
subsequent patches.
http://codereview.appspot.com/4080047/
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
On Tue, Feb 1, 2011 at 12:59 AM, Benjamin Peterson benja...@python.org wrote:
I see no reason for b.p.o bureaucracy.
It provides a place for discussion, and makes it easier to coordinate
multiple efforts.
Code review system provides a better space for discussion if we are
speaking about
Am 31.01.2011 22:58, schrieb anatoly techtonik:
On Mon, Jan 31, 2011 at 11:09 PM, Ethan Furman et...@stoneleaf.us wrote:
techto...@gmail.com wrote:
I see no reason for b.p.o bureaucracy.
It provides a place for discussion, and makes it easier to coordinate
multiple efforts.
Code review
Am 31.01.2011 23:05, schrieb anatoly techtonik:
On Mon, Jan 31, 2011 at 10:58 PM, Georg Brandl g.bra...@gmx.net wrote:
Am 31.01.2011 21:45, schrieb techto...@gmail.com:
There is no b.p.o issue as it's not a bug, but a tiny copy/paste patch
to clean up the code a bit while I am trying to
33 matches
Mail list logo
