Am 14.10.2011 00:30, schrieb Victor Stinner:
> Le jeudi 13 octobre 2011 03:34:00, Victor Stinner a écrit :
>> > We would need a new format for Py_BuildValue, e.g. 'a' for ASCII string.
>> > Later we can add new functions like _PyDict_GetASCII().
>>
>> The main difference between my new "const ASCI
On Thursday, October 13, 2011 04:02:27 PM Jeremy Kloth wrote:
> That said, I have been working on a drop-in replacement for the current
> bdist_wininst executable stub with the following features:
> - install to 32- or 64-bit Python installations from a single installer;
> currently one installer
Le jeudi 13 octobre 2011 03:34:00, Victor Stinner a écrit :
> > We would need a new format for Py_BuildValue, e.g. 'a' for ASCII string.
> > Later we can add new functions like _PyDict_GetASCII().
>
> The main difference between my new "const ASCII" string idea and
> PyIdentifier is the lifetime o
Martin v. Löwis wrote:
So I think it needs a prefix. If you don't like PyId_, let me know
what the prefix should be instead.
Instead of an explicit prefix, how about a macro, such as
Py_ID(__string__)?
--
Greg
___
Python-Dev mailing list
Python-Dev@p
On Thursday, October 13, 2011 01:42:13 PM Paul Moore wrote:
> Maybe the wininst and MSI installers should ultimately become simple
> UIs around a zipfile and an invocation of the packaging APIs? Not that
> I'm offering to do that work, I'm afraid...
The bdist_wininst/_msi installers cannot use any
On Tuesday, October 11, 2011 01:59:45 AM Vinay Sajip wrote:
> I looked at the dialog resources for wininst-x.y.exe and noticed that there
> is a "Find other ..." button which is hidden, and its handler (in
> PC\bdist_wininst\install.c) is commented out. However, the code called by
> the handler - G
On 13 October 2011 20:28, Tim Golden wrote:
> On 13/10/2011 19:36, Paul Moore wrote:
>>
>> I don't really understand the benefits of bdist_msi over
>> bdist_wininst
>
> Just commenting on this particular issue: in essence, the .MSI
> format is the Microsoft standard, something which is especially
Looking at a RECORD file installed by pysetup (on 3.3 trunk, on
Windows) all of the filenames seem to be absolute, even though the
package is pure-Python and so everything is under site-packages.
Looking at PEP 376, it looks like the paths should be relative to
site-packages. Two questions:
1. Am
On 13/10/2011 19:36, Paul Moore wrote:
I don't really understand the benefits of bdist_msi over
bdist_wininst
Just commenting on this particular issue: in essence, the .MSI
format is the Microsoft standard, something which is especially
important for corporate rollouts. We're not particularly b
On Oct 13, 2011, at 08:08 PM, Martin v. Löwis wrote:
>>> Py_CONST_STRING or Py_IDENTIFIER would be fine with me. Given that
>>> everything else uses "Id" in their name, Py_IDENTIFIER is probably better?
>>
>> I agree that either is fine, with a slight preference for Py_IDENTIFIER for
>> the same
On 13 October 2011 18:30, "Martin v. Löwis" wrote:
>> wininst and msi bdists can continue to be used as previously, for people
>> who want clicky installation to their system Python. With built-in
>> package management and virtual environments in 3.3+, we can just
>> recommend that people publish
On 13 October 2011 17:25, Éric Araujo wrote:
>> 1. By using setup.cfg technology, it would be easy enough to zip up a
>> binary build in a way that pysetup could unpack and install.
> Correct. I’m still pondering whether I find the idea of registering
> built files in setup.cfg as elegant or hack
Py_CONST_STRING or Py_IDENTIFIER would be fine with me. Given that
everything else uses "Id" in their name, Py_IDENTIFIER is probably better?
I agree that either is fine, with a slight preference for Py_IDENTIFIER for
the same reasons.
Ok, so it's Py_IDENTIFIER.
So I think it needs a prefix
On Thu, 13 Oct 2011 20:05:06 +0200
"Martin v. Löwis" wrote:
> > - In Modules/_json.c, line 1126, _Py_identifier(strict) is
> > declared but not used, and there are 5 other possible replacements.
>
> Antoine reverted this in 8ed6a627a834. I think I started doing them,
> then noticed that this is a
wininst and msi bdists can continue to be used as previously, for people
who want clicky installation to their system Python. With built-in
package management and virtual environments in 3.3+, we can just
recommend that people publish bdist_simple instead of wininst or eggs.
Pardon me for jumpi
On 13 October 2011 17:35, Éric Araujo wrote:
> Le 11/10/2011 03:29, Nick Coghlan a écrit :
>> On Mon, Oct 10, 2011 at 2:29 PM, Paul Moore wrote:
>>> Ideally bdist_wininst and bdist_msi would also integrate with pysetup
>>> and with virtual environments, but I imagine that could be pretty hard
>>>
Le 13/10/2011 18:25, Éric Araujo a écrit :
>>2c. There's a question over a GUI install followed by a pysetup
>> uninstall, which wouldn't remove the add/remove entry...
> I think we could require that a project installed with a clicky
> wininst_bdist has to be removed via the Add/Remove GUI. (
Hi Nick,
Le 11/10/2011 03:29, Nick Coghlan a écrit :
> On Mon, Oct 10, 2011 at 2:29 PM, Paul Moore wrote:
>> Ideally bdist_wininst and bdist_msi would also integrate with pysetup
>> and with virtual environments, but I imagine that could be pretty hard
>> to make work cleanly, as Windows doesn't
Le 09/10/2011 22:14, Paul Moore a écrit :
> On 9 October 2011 20:47, Tarek Ziadé wrote:
>> PEP 376 provide the installation format for the 'future' --
>> http://www.python.org/dev/peps/pep-0376/
> [...]
>> Now for a binary archive, that would get installed ala PEP 376, why
>> not ? I'd just be cur
Hi Philip,
> [...] In any case, it definitely wasn't the case that eggs or setuptools were
> rejected for 2.5; they were withdrawn for reasons that didn't have anything
> to do with the format itself.
Thanks for clarifying. I nonetheless remember strong opposition to
pulling the code unmodified,
Le 09/10/2011 13:54, Paul Moore a écrit :
> On 9 October 2011 08:15, Éric Araujo wrote:
>> Are there that many distributions with extension modules? sdists should
>> work well even on Windows for pure Python projects.
> [...]
> Looking at my installations, I see:
> - database drivers (cx_Oracle,
On Oct 13, 2011, at 03:23 PM, Antoine Pitrou wrote:
>Py_CONST_STRING or Py_IDENTIFIER would be fine with me. Given that
>everything else uses "Id" in their name, Py_IDENTIFIER is probably better?
I agree that either is fine, with a slight preference for Py_IDENTIFIER for
the same reasons.
>> Or
On Thu, 13 Oct 2011 14:00:38 +0200
"Martin v. Löwis" wrote:
> > I like this better too because of the all-caps macro name. Something about
> > seeing "Py_identifier" look like a function call and having it add the
> > magical
> > PyId_update local bugs me. It just looks wrong, whereas the all-c
An alternative I am fond of is to to avoid introducing a new type, and
simply initialize a PyObject * and register its address.
-1 on that, because of the lack of error checking.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http:/
I like this better too because of the all-caps macro name. Something about
seeing "Py_identifier" look like a function call and having it add the magical
PyId_update local bugs me. It just looks wrong, whereas the all-caps is more
of a cultural clue that something else is going on.
If people t
25 matches
Mail list logo
