> As quoted above, deprecation of the bytes version of the API sounds
> fine to me, but isn't this going to run into the usual objections from
> the "we need bytes for efficiency" crowd? It's OK with me to
> say "in this restricted area you must convert to Unicode", but is that
> going to fly with
On Sun, Oct 30, 2011 at 6:00 PM, "Martin v. Löwis" wrote:
>> As quoted above, deprecation of the bytes version of the API sounds
>> fine to me, but isn't this going to run into the usual objections from
>> the "we need bytes for efficiency" crowd? It's OK with me to
>> say "in this restricted are
Nick Coghlan gmail.com> writes:
> All the core committers can actually publish PEPs via the PEP hg repo,
> so Vinay could probably handle pushing the updates to python.org.
> Submission via the PEP editors is mainly there as a backstop for cases
> where there's no current core dev directly involv
Antoine Pitrou pitrou.net> writes:
> Why would that be a problem? Do you plan to install several versions of
> Python in a single VE?
No, but some packages might install headers in /include and others in
/include/pythonX.Y. I wasn't sure whether this would cause a problem with files
not being f
On Sun, 30 Oct 2011 12:10:18 + (UTC)
Vinay Sajip wrote:
>
> > We already have Unix shell scripts and BAT files in the source tree. Is
> > it really complicated to maintain these additional shell scripts? Is
> > there a lot of code in them?
>
> No, they're pretty small: wc -l gives
>
> 76 po
Antoine Pitrou pitrou.net> writes:
> We already have Unix shell scripts and BAT files in the source tree.
Do we have a blessed location in the stdlib for data files in general? Although
we're talking in this instance about scripts, they're just data as far as the
venv module is concerned. While
On Sun, 30 Oct 2011 12:35:20 + (UTC)
Vinay Sajip wrote:
> The other alternative would be to make venv a package with all its code
> in venv/__init__.py and a scripts.zip adjacent to that. Does that seem
> like a better solution?
Please don't make it a zip file. We want code to be easily track
I'd like to reopen the discussions on how the new packaging module
will handle/support binary distributions in Python 3.3. The previous
thread (see
http://mail.python.org/pipermail/python-dev/2011-October/113956.html)
included a lot of good information and discussion, but ultimately
didn't reach a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/30/2011 08:35 AM, Vinay Sajip wrote:
> Antoine Pitrou pitrou.net> writes:
>
>> We already have Unix shell scripts and BAT files in the source
>> tree.
>
> Do we have a blessed location in the stdlib for data files in
> general? Although we're
Antoine Pitrou pitrou.net> writes:
> Please don't make it a zip file. We want code to be easily trackable
> and editable.
Of course. I was thinking of a directory tree in the source, subject to our
normal revision control, but processed during make or installation to be
available as a zip file o
On Sun, 30 Oct 2011 13:38:35 +0100
petri.lehtinen wrote:
> http://hg.python.org/cpython/rev/f634102aca01
> changeset: 73204:f634102aca01
> parent: 73201:a5c4ae15b59d
> parent: 73203:b643458a0108
> user:Petri Lehtinen
> date:Sun Oct 30 14:35:39 2011 +0200
> summary:
>
On Sun, 30 Oct 2011 15:42:11 + (UTC)
Vinay Sajip wrote:
> Antoine Pitrou pitrou.net> writes:
>
> > Please don't make it a zip file. We want code to be easily trackable
> > and editable.
>
> Of course. I was thinking of a directory tree in the source, subject to our
> normal revision control
In article
,
Paul Moore wrote:
> I'd like to reopen the discussions on how the new packaging module
> will handle/support binary distributions in Python 3.3. The previous
> thread (see
> http://mail.python.org/pipermail/python-dev/2011-October/113956.html)
> included a lot of good information
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/30/2011 02:04 PM, Ned Deily wrote:
> In article
> ,
>
>
Paul Moore wrote:
>
>> I'd like to reopen the discussions on how the new packaging
>> module will handle/support binary distributions in Python 3.3.
>> The previous thread (see
>> http:
Le 30/10/2011 09:00, "Martin v. Löwis" a écrit :
As quoted above, deprecation of the bytes version of the API sounds
fine to me, but isn't this going to run into the usual objections from
the "we need bytes for efficiency" crowd? It's OK with me to
say "in this restricted area you must convert
Le 29/10/2011 07:47, Mark Hammond a écrit :
When previously discussing this issue, I was under the impression that
the problem was unencodable bytes passed from the Python code to Windows
- but the reverse is true - only the data coming back from Windows isn't
encodable.
The undecodable filenam
Antoine Pitrou pitrou.net> writes:
>
> It would be even simpler not to process it at all, but install the
> scripts as-is (without the execute bit) :)
>
Sure, but such an approach makes it difficult to provide a mechanism which is
easily extensible; for example, with the current approach, it i
On 30 October 2011 18:04, Ned Deily wrote:
> Has anyone analyzed the current packages on PyPI to see how many provide
> binary distributions and in what format?
A very quick and dirty check:
dmg: 5
rpm: 12
msi: 23
dumb: 132
wininst: 364
egg: 2570
That's number of packages with binary distributi
On Sun, 30 Oct 2011 22:47:13 + (UTC)
Vinay Sajip wrote:
> Antoine Pitrou pitrou.net> writes:
>
> >
> > It would be even simpler not to process it at all, but install the
> > scripts as-is (without the execute bit) :)
> >
>
> Sure, but such an approach makes it difficult to provide a mech
Paul Moore gmail.com> writes:
> The MSI format is a little more tricky, mainly because it is a more
> complex format and (as far as I can tell from a brief check) files are
> stored in the opaque CAB format, so the only way of getting data out
> is to do a temporary install somewhere. But I see n
I like binary distribution even under Linux.
I access some Linux machines using same Linux distribution and some of them
doesn't have "python-dev" package or even "build-essensials". (because they are
netbooting so have restricted rootfs size)
So I want build binary package by myself and distribu
On 30 October 2011 23:17, Vinay Sajip wrote:
> Paul Moore gmail.com> writes:
>
>> The MSI format is a little more tricky, mainly because it is a more
>> complex format and (as far as I can tell from a brief check) files are
>> stored in the opaque CAB format, so the only way of getting data out
>
On 31/10/2011 8:39 AM, Victor Stinner wrote:
Le 29/10/2011 07:47, Mark Hammond a écrit :
When previously discussing this issue, I was under the impression that
the problem was unencodable bytes passed from the Python code to Windows
- but the reverse is true - only the data coming back from Wind
On 10/30/2011 5:39 PM, Victor Stinner wrote:
Terry J. Reedy is also concerned about backward compatibility (3.2 ->
3.3). Emiting a warning, disabled by default, is a softer solution :-)
The fact that Mark, Martin, and someone else, I believe, agree with you
that the bytes api is not useful at
24 matches
Mail list logo
