On Wed, Feb 2, 2011 at 10:36 AM, "Martin v. Löwis" 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 question why Pyt
> 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 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/
__
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 is
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 f
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 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 cour
Am 01.02.2011 16:51, schrieb anatoly techtonik:
> On Tue, Feb 1, 2011 at 1:38 AM, Nick Coghlan wrote:
>> On Tue, Feb 1, 2011 at 7:58 AM, anatoly techtonik
>> wrote:
>>> To me polluting tracker with the
>>> issues that are neither bugs nor feature requests only makes bug
>>> triaging process and
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/
___
Pyt
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 valua
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 an
On Tue, Feb 1, 2011 at 09:51, anatoly techtonik wrote:
> On Tue, Feb 1, 2011 at 1:38 AM, Nick Coghlan wrote:
> > On Tue, Feb 1, 2011 at 7:58 AM, anatoly techtonik
> wrote:
> >> To me polluting tracker with the
> >> issues that are neither bugs nor feature requests only makes bug
> >> triaging p
2011/2/1 anatoly techtonik :
> 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
change the developmen
On Tue, Feb 1, 2011 at 1:38 AM, Nick Coghlan wrote:
> On Tue, Feb 1, 2011 at 7:58 AM, anatoly techtonik 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
On Tue, Feb 1, 2011 at 01:35, anatoly techtonik wrote:
> On Tue, Feb 1, 2011 at 12:59 AM, Benjamin Peterson
> 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 revie
On Tue, Feb 1, 2011 at 5:35 PM, anatoly techtonik 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.
While I've occasi
Am 31.01.2011 23:05, schrieb anatoly techtonik:
> On Mon, Jan 31, 2011 at 10:58 PM, Georg Brandl 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
Am 31.01.2011 22:58, schrieb anatoly techtonik:
> On Mon, Jan 31, 2011 at 11:09 PM, Ethan Furman 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 sys
On Tue, Feb 1, 2011 at 12:59 AM, Benjamin Peterson 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
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:
http:/
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
http://mail.
On Tue, Feb 1, 2011 at 7:58 AM, anatoly techtonik 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
*your* way of doing t
2011/1/31 anatoly techtonik :
> On Mon, Jan 31, 2011 at 11:09 PM, Ethan Furman 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 bett
On Mon, Jan 31, 2011 at 10:58 PM, Georg Brandl 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 reason
On Mon, Jan 31, 2011 at 11:09 PM, Ethan Furman 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 are
speakin
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
http://mail.python.org/mailman/listi
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
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 instea
On Mon, Jan 31, 2011 at 14:45, 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
> more beneficial
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 fr
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:
http://mail.python.org/mailman/options/python-dev/archiv
Hi,
2011/1/31 :
> 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
Python-Dev@python.org
http://mai
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)
+++ Tools/msi/ms
33 matches
Mail list logo
