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 mewink 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 mar...@v.loewis.de 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 mewink to
say in this
Nick Coghlan ncoghlan at 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
Antoine Pitrou solipsis at 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
On Sun, 30 Oct 2011 12:10:18 + (UTC)
Vinay Sajip vinay_sa...@yahoo.co.uk 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
Antoine Pitrou solipsis at 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
On Sun, 30 Oct 2011 12:35:20 + (UTC)
Vinay Sajip vinay_sa...@yahoo.co.uk 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
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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/30/2011 08:35 AM, Vinay Sajip wrote:
Antoine Pitrou solipsis at 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
Antoine Pitrou solipsis at 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
On Sun, 30 Oct 2011 13:38:35 +0100
petri.lehtinen python-check...@python.org wrote:
http://hg.python.org/cpython/rev/f634102aca01
changeset: 73204:f634102aca01
parent: 73201:a5c4ae15b59d
parent: 73203:b643458a0108
user:Petri Lehtinen pe...@digip.org
date:Sun Oct
On Sun, 30 Oct 2011 15:42:11 + (UTC)
Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
Antoine Pitrou solipsis at 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
In article
cacac1f-cmbkryagzrcawdndm7-vn4yjo99fbd9vvccmbhcv...@mail.gmail.com,
Paul Moore p.f.mo...@gmail.com 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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/30/2011 02:04 PM, Ned Deily wrote:
In article
cacac1f-cmbkryagzrcawdndm7-vn4yjo99fbd9vvccmbhcv...@mail.gmail.com,
Paul Moore p.f.mo...@gmail.com wrote:
I'd like to reopen the discussions on how the new packaging
module will
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 mewink 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
Antoine Pitrou solipsis at 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
On 30 October 2011 18:04, Ned Deily n...@acm.org 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
On Sun, 30 Oct 2011 22:47:13 + (UTC)
Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
Antoine Pitrou solipsis at 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
Paul Moore p.f.moore at 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 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 distribute
On 30 October 2011 23:17, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
Paul Moore p.f.moore at 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
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
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
