M.-A. Lemburg wrote:
sys.userdirsuffix
-
sys.userdirsuffix is an implementation and platform specific string that
is used to construct the path for the user site directory as explained
in PEP 370. The string contains the implementation name as well as the
version number of
Nick Coghlan wrote:
M.-A. Lemburg wrote:
sys.userdirsuffix
-
sys.userdirsuffix is an implementation and platform specific string that
is used to construct the path for the user site directory as explained
in PEP 370. The string contains the implementation name as well as the
Martin v. Löwis wrote:
id (required):
lower case identifier, for example cpython, ironpython, jython,
pypy
Doing some bike-shedding: I'd like to not use cpython as the name of
the python.org implementation. This term, I believe, was coined around
JPython, somehow making the
Christian Heimes wrote:
sys.implementation
--
platform (required):
platform or language of the implementation, for example C, .NET,
Java
I'd call this attribute language. We already have sys.platform with
a different meaning.
Possible values would then be C, C#, Java,
Christian Heimes wrote:
id (required):
lower case identifier, for example cpython, ironpython, jython,
pypy
name (required):
mixed case name of the implementation, for example CPython,
IronPython, Jython, PyPy
Why both? Is it not true that the following is guaranteed?
Nick Coghlan wrote:
M.-A. Lemburg wrote:
Benjamin Peterson wrote:
I forgot to ask before: Does this deprecate
platform.python_implementation()?
No, platform.py is meant to be portable across multiple Python
versions and as such not really suitable for such deprecations.
It'll also take a
On Fri, Oct 9, 2009 at 8:42 PM, Martin v. Löwis mar...@v.loewis.de wrote:
I think it is important to confirm in advance that all the
implementations listed below agree to implement the PEP soonish after
it's adopted. Required sounds like a strong term - however, if an
implementation chooses
On Fri, Oct 9, 2009 at 8:34 PM, Martin v. Löwis mar...@v.loewis.de wrote:
Also, why is it the name of the JIT compiler, and not the name of the
source language compiler?
From the Jython side it is easier to get the VM name compared to the
source language compiler. Although there is a property
On Sun, Oct 11, 2009 at 4:31 PM, Frank Wierzbicki fwierzbi...@gmail.com wrote:
On Fri, Oct 9, 2009 at 8:42 PM, Martin v. Löwis mar...@v.loewis.de wrote:
So I propose that the python.org version is identified as python.
I'll add my voice to the group that likes cpython and CPython as
the
On Sat, Oct 10, 2009 at 1:29 AM, Christian Heimes li...@cheimes.de wrote:
I'm proposing two new attributes in the sys module: sys.implementation
and sys.userdirsuffix.
This seems like a good idea.
I'm not sure this idea will easily be accepted, but I'd like to see
the sys module eventually
Benjamin Peterson wrote:
I forgot to ask before: Does this deprecate platform.python_implementation()?
No, platform.py is meant to be portable across multiple Python
versions and as such not really suitable for such deprecations.
It'll also take a long while before all Python implementations
2009/10/10 Willem Broekema metaw...@gmail.com:
On Sat, Oct 10, 2009 at 1:29 AM, Christian Heimes li...@cheimes.de wrote:
I'm proposing two new attributes in the sys module: sys.implementation
and sys.userdirsuffix.
This seems like a good idea.
I'm not sure this idea will easily be accepted,
M.-A. Lemburg wrote:
Benjamin Peterson wrote:
I forgot to ask before: Does this deprecate platform.python_implementation()?
No, platform.py is meant to be portable across multiple Python
versions and as such not really suitable for such deprecations.
It'll also take a long while before
Martin v. Löwis wrote:
Doing some bike-shedding: I'd like to not use cpython as the name of
the python.org implementation. This term, I believe, was coined around
JPython, somehow making the implementation language the primary means
of distinction. However, there may be alternative
Christian Heimes wrote:
Fellow Python developers!
In the light of our recent discussion about implementation specific
information and user site directory I like to start a new PEP. Much to
my regret I wasn't able to contribute to Python core development over
the past months. I hope I can find
Michael Foord wrote:
Why not just sys.implementation as a string? Everything else can
trivially be deduced from that anyway. What is the use-case for the
extra information?
I think Christian's set of required attributes is much too large (I
would only have name as a required field), but I can
Fellow Python developers!
In the light of our recent discussion about implementation specific
information and user site directory I like to start a new PEP. Much to
my regret I wasn't able to contribute to Python core development over
the past months. I hope I can find some free time over the
Christian wrote:
sys.implementation is a PyStructSequence that contains various
information about the current implementation. Some fields are required
to be present on every implementation. Implementations may choose to
add
additional fields as they see fit. Some fields like compiler are
2009/10/9 Christian Heimes li...@cheimes.de:
Fellow Python developers!
In the light of our recent discussion about implementation specific
information and user site directory I like to start a new PEP. Much to
my regret I wasn't able to contribute to Python core development over
the past
Benjamin Peterson wrote:
sys.implementation is a PyStructSequence that contains various
information about the current implementation. Some fields are required
to be present on every implementation. Implementations may choose to add
additional fields as they see fit. Some fields like compiler
2009/10/9 Christian Heimes li...@cheimes.de:
Benjamin Peterson wrote:
sys.userdirsuffix
-
Why not site.userdirsuffix?
Because all implementations of Python like to use the same, unpatched
site module. The sys module is different for every implementation. It's
more
Given that this is all about establishing some common ground between
implementations I would propose not using a CPython specific term
here such as PyStructSequence :) The Python docs seem to use structseq
for sys.float_info.
Also, why does it have to be a sequence in the first place?
sys.implementation is a PyStructSequence that contains various
information about the current implementation. Some fields are required
to be present on every implementation.
I think it is important to confirm in advance that all the
implementations listed below agree to implement the PEP
Martin v. Löwis wrote:
Given that this is all about establishing some common ground between
implementations I would propose not using a CPython specific term
here such as PyStructSequence :) The Python docs seem to use structseq
for sys.float_info.
Also, why does it have to be a sequence
Martin v. Löwis wrote:
So I propose that the python.org version is identified as python.
But then we won't have a generic term for the language
itself, independent of any implementation.
The c in cpython doesn't necessarily have to refer
to the implementation language. Maybe it stands for
Martin v. Löwis wrote:
sys.implementation is a PyStructSequence that contains various
information about the current implementation. Some fields are required
to be present on every implementation.
I think it is important to confirm in advance that all the
implementations listed below agree
Dino Viehland wrote:
Given that this is all about establishing some common ground between
implementations I would propose not using a CPython specific term
here such as PyStructSequence :) The Python docs seem to use structseq
for sys.float_info.
You got me! :)
compiler (required):
Christian wrote:
Martin has already answered both points to my satisfaction. Do you
agree with him?
Sure, source level makes more sense - so we'd have csc or gmcs if
compiled with Mono (assuming there's some way to do that...).
___
Python-Dev
Benjamin Peterson wrote:
I think we should make a semi-private (public to the stdlib) module
like _sys or _implementation part of the Python VM API. Then, instead
of stuffing everything into sys, we can provide this information in
modules where it belongs.
That's an interesting counter
2009/10/9 Christian Heimes li...@cheimes.de:
Benjamin Peterson wrote:
I think we should make a semi-private (public to the stdlib) module
like _sys or _implementation part of the Python VM API. Then, instead
of stuffing everything into sys, we can provide this information in
modules where it
On Fri, Oct 9, 2009 at 18:14, Benjamin Peterson benja...@python.org wrote:
2009/10/9 Christian Heimes li...@cheimes.de:
Benjamin Peterson wrote:
I think we should make a semi-private (public to the stdlib) module
like _sys or _implementation part of the Python VM API. Then, instead
of
2009/10/9 Brett Cannon br...@python.org:
But I honestly don't see why this doesn't belong in sys; it has to do with
the system environment which is the interpreter. Yes, some things currently
in sys could possibly be put elsewhere (e.g. the exception stuff could be in
'exceptions'), but I
32 matches
Mail list logo
