Tarek Ziadé wrote:
I thought the plan was to stick with major.minor and ==, !=, in and
not in until PEP 386 was accepted, then switch over to having all versions
(including Python's) be some sort of Version object, at which point we can
have richer version comparisons, with all of the existing
On Sun, Oct 25, 2009 at 10:11:00PM -0400, Tres Seaver wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Floris Bruynooghe wrote:
On Tue, Oct 20, 2009 at 10:39:51AM +0200, Tarek Ziadé wrote:
PEP 345 is the PEP for the new metadata format, replacing PEP 314. I
have upgraded it, using
On Tue, Oct 20, 2009 at 10:39:51AM +0200, Tarek Ziadé wrote:
PEP 345 is the PEP for the new metadata format, replacing PEP 314. I
have upgraded it, using Tres's work from last year, and the next step
is to add the context marker presented in PEP 390.
I have also updated PEP 386 to link it to
On Wed, Oct 21, 2009 at 3:45 AM, David Cournapeau
da...@ar.media.kyoto-u.ac.jp wrote:
Tarek Ziadé wrote:
No, the architecture is given by platform.machine() so you have it already,
by combining a test with sys.platform.
But platform.machine() returns a 32 bits machine if you run 32 bits
Tarek Ziadé wrote:
There's something unclear for me here :
What is suppose to happen when you use Python 32bits on a 64bits machine,
for Python distributions that get build or installed ?
Do you end up in a mixed environment of 64bits distributions within a
32bits interpreter ?
Tarek Ziadé wrote:
On Tue, Oct 20, 2009 at 5:20 PM, M.-A. Lemburg m...@egenix.com wrote:
The micro-language should provide a limited number of
variables to use on the conditions:
python_version = sys.version
sys_platform = sys.platform
If we adopt such a micro-language (I'm reserving
On Wed, Oct 21, 2009 at 10:20 AM, David Cournapeau
da...@ar.media.kyoto-u.ac.jp wrote:
Tarek Ziadé wrote:
There's something unclear for me here :
What is suppose to happen when you use Python 32bits on a 64bits machine,
for Python distributions that get build or installed ?
Do you end up in
Tarek Ziadé wrote:
The micro-language, though, is about the metadata fields like requires
So do you have a use case where a Python distribution needs to use 64
bit (the machine)
Given the difficulty, I think such a field should only be added once
python itself has a method to reliably
On Wed, Oct 21, 2009 at 10:58 AM, David Cournapeau
da...@ar.media.kyoto-u.ac.jp wrote:
Tarek Ziadé wrote:
The micro-language, though, is about the metadata fields like requires
So do you have a use case where a Python distribution needs to use 64
bit (the machine)
Given the difficulty, I
On Wed, Oct 21, 2009 at 10:42 AM, M.-A. Lemburg m...@egenix.com wrote:
Tarek Ziadé wrote:
On Tue, Oct 20, 2009 at 5:20 PM, M.-A. Lemburg m...@egenix.com wrote:
The micro-language should provide a limited number of
variables to use on the conditions:
python_version = sys.version
sys_platform
Tarek Ziadé wrote:
On Wed, Oct 21, 2009 at 10:42 AM, M.-A. Lemburg m...@egenix.com wrote:
Tarek Ziadé wrote:
On Tue, Oct 20, 2009 at 5:20 PM, M.-A. Lemburg m...@egenix.com wrote:
The micro-language should provide a limited number of
variables to use on the conditions:
python_version =
Tarek Ziadé wrote:
We said earlier that we could use sys.hexversion to handle this, but
otherwise,
at least for the Python version, we can use the StrictVersion() class
from Distutils,
*But* we ended up thinking that it would be better for the first version to
keep
just ==, !=, in and
On Wed, 21 Oct 2009 10:48:00 +0200, Tarek Ziadé ziade.ta...@gmail.com
wrote:
So do you have a use case where a Python distribution needs to use 64
bit (the machine)
in order to provide a different requires ?
I wouldn't be too worried about this '64' bit issue.
Hypothetically, C library
Tarek Ziadé wrote:
On Wed, Oct 21, 2009 at 10:42 AM, M.-A. Lemburg m...@egenix.com wrote:
Tarek Ziadé wrote:
On Tue, Oct 20, 2009 at 5:20 PM, M.-A. Lemburg m...@egenix.com wrote:
The micro-language should provide a limited number of
variables to use on the conditions:
python_version =
On Wed, 21 Oct 2009 16:48:41 +0530, David Lyon david.l...@preisshare.net
wrote:
My original point was only that 'win32' constant from the stdlib sys
module
is an
inaccurate constant to describe windows now. The stdlib platform module
uses
'Windows' and that seems better.
+1
I suggest to
2009/10/21 Sridhar Ratnakumar sridh...@activestate.com:
[...]
I suggest to first have a standard library module/api that would give such
'friendly' names. This is what `platinfo` is heading towards:
http://code.google.com/p/platinfo/wiki/FutureWork .. to quote:
[...]
I think we should focus
On Wed, Oct 21, 2009 at 1:38 PM, Eric Smith e...@trueblade.com wrote:
Tarek Ziadé wrote:
On Wed, Oct 21, 2009 at 10:42 AM, M.-A. Lemburg m...@egenix.com wrote:
Tarek Ziadé wrote:
On Tue, Oct 20, 2009 at 5:20 PM, M.-A. Lemburg m...@egenix.com wrote:
The micro-language should provide a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
M.-A. Lemburg wrote:
Tarek Ziadé wrote:
On Wed, Oct 21, 2009 at 10:42 AM, M.-A. Lemburg m...@egenix.com wrote:
Tarek Ziadé wrote:
On Tue, Oct 20, 2009 at 5:20 PM, M.-A. Lemburg m...@egenix.com wrote:
The micro-language should provide a limited
Hi,
PEP 345 is the PEP for the new metadata format, replacing PEP 314. I
have upgraded it, using Tres's work from last year, and the next step
is to add the context marker presented in PEP 390.
I have also updated PEP 386 to link it to PEP 345.
= PEP 345 : Summary of Differences From PEP 314 =
Tarek Ziadé wrote:
Hi,
PEP 345 is the PEP for the new metadata format, replacing PEP 314. I
have upgraded it, using Tres's work from last year, and the next step
is to add the context marker presented in PEP 390.
I have also updated PEP 386 to link it to PEP 345.
= PEP 345 : Summary of
On Tue, Oct 20, 2009 at 7:37 AM, M.-A. Lemburg m...@egenix.com wrote:
Where's the benefit of renaming the above three fields ?
I don't see any benefit here either; if we want to add fields for
Python package or anything else, new (more explicit) field names can
be added, without ever requiring
On Tue, Oct 20, 2009 at 01:37:48PM +0200, M.-A. Lemburg wrote:
[...]
* Added fields:
[...]
- Requires-Dist
- Provides-Dist
- Obsoletes-Dist
* Deprecated fields:
- Requires (in favor of Requires-Dist)
- Provides (in favor of Provides-Dist)
- Obsoletes (in favor of
On Tue, Oct 20, 2009 at 9:33 PM, David Lyon david.l...@preisshare.net wrote:
On Tue, 20 Oct 2009 09:36:08 -0400, Fred Drake fdr...@gmail.com wrote:
If we adopt such a micro-language (I'm reserving judgment until I've
had more time to read the relevant PEPs carefully), I'd rather see the
names
On Tue, Oct 20, 2009 at 5:20 PM, M.-A. Lemburg m...@egenix.com wrote:
The micro-language should provide a limited number of
variables to use on the conditions:
python_version = sys.version
sys_platform = sys.platform
If we adopt such a micro-language (I'm reserving judgment until I've
had
Tarek Ziadé wrote:
but, notice that python_version here is: %s.%s %
sys.version_info[0], sys.version_info[1]
I think you mean:
{0[0]}.{0[1]}.format(sys.version_info)
or better:
{0.major}.{0.minor}.format(sys.version_info)
:)
On the odd occasion that .format is less verbose than %, I like
On Tue, Oct 20, 2009 at 10:20 PM, Eric Smith e...@trueblade.com wrote:
Tarek Ziadé wrote:
but, notice that python_version here is: %s.%s %
sys.version_info[0], sys.version_info[1]
I think you mean:
{0[0]}.{0[1]}.format(sys.version_info)
or better:
Tarek Ziadé wrote:
No, the architecture is given by platform.machine() so you have it already,
by combining a test with sys.platform.
But platform.machine() returns a 32 bits machine if you run 32 bits
python on 64 bits windows. AFAIK, the only reliable way is to use the
win32 API:
27 matches
Mail list logo
