2009/10/9 Brett Cannon :
> 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 don't think sys i
On Fri, Oct 9, 2009 at 18:14, Benjamin Peterson wrote:
> 2009/10/9 Christian Heimes :
> > 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 s
2009/10/9 Christian Heimes :
> 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.
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 pr
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
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):
>>
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
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:
>> 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 s
> 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 "soo
> 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? Wou
2009/10/9 Christian Heimes :
> 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 convenient
> I know that the issue tracker for PyPI is (still) on SF, but
> development appear to happen elsewhere and I can't find any
> contact information on the PyPI web pages.
PyPI discussion takes place mostly on catalog-sig.
Regards,
Martin
___
Python-Dev m
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 com
2009/10/9 Christian Heimes :
> 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
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
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 next
>> That's absurd. There's a certain area where Guido can make
>> pronouncements, but third-party packages is not it. Even if they're
>> hosted on python.org infrastructure.
Guido> Right.
Now if you were the un-BDFL you could step in here. ;-)
This whole topic seems to have a l
Sorry, sent to wrong list! Please ignore.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Just received:
https://bugzilla.redhat.com/show_bug.cgi?id=528237
yum install libotf-devel.i586 libotf-devel.x86_64
yields:
Transaction Check Error:
file /usr/bin/libotf-config from install of libotf-devel-0.9.8-2.fc11.i586
conflicts with file from package libotf-devel-0.9.8-2.fc11.x86_64
fi
On Fri, Oct 09, 2009 at 01:56:42PM -0700, Guido van Rossum wrote:
> On Fri, Oct 9, 2009 at 1:50 PM, Georg Brandl wrote:
> > Chris Withers schrieb:
> >> Guido van Rossum wrote:
> >>> I'm saying that I don't expect setuptools 0.7 to appear before Tarek's
> >>> Distribute is mature and in widespread
On Fri, Oct 9, 2009 at 1:50 PM, Georg Brandl wrote:
> Chris Withers schrieb:
>> Guido van Rossum wrote:
>>> I'm saying that I don't expect setuptools 0.7 to appear before Tarek's
>>> Distribute is mature and in widespread use. IOW I support Tarek's fork
>>> and suggest nobody hold their breath wai
Chris Withers schrieb:
> Guido van Rossum wrote:
>> I'm saying that I don't expect setuptools 0.7 to appear before Tarek's
>> Distribute is mature and in widespread use. IOW I support Tarek's fork
>> and suggest nobody hold their breath waiting for setuptools 0.7.
>
> Well, if this was the BDFL pr
Chris Withers schrieb:
> Tarek Ziadé wrote:
>>> NB: There was no consensus on this "micro-language" on distutils-sig.
>>> While I suspect I don't care as none of my packages rely on anything other
>>> than other python packages, others did care, and I found the syntax Tarek
>>> was proposing pretty
On Fri, Oct 09, 2009 at 05:29:28PM +0100, Chris Withers wrote:
> Toshio Kuratomi wrote:
>> On Fri, Oct 09, 2009 at 04:51:00PM +0100, Chris Withers wrote:
>>> Tarek Ziadé wrote:
Virtualenv allows you to create an isolated environment to install
some distribution without polluting the
On Thu, Oct 8, 2009 at 7:17 AM, Christian Heimes wrote:
> CPython:
> ~/.local/lib/python2.6/site-packages
> %APPDATA%/Python/Python26
>
> IronPython:
> ~/.local/lib/ironpython2.6/site-packages
> %APPDATA%/Python/IronPython26
>
> Jython:
> ~/.local/lib/jython2.6/site-packages
> %APPDATA%/Pyth
On Fri, Oct 9, 2009 at 11:32, Michael Foord wrote:
> The *only* change in semantics I'm proposing is for users of IronPython 2.6
> which is not even at final release yet. CPython users would be unaffected.
>
>
Then why can't IronPython patch site.py to do what they want? I still feel
uncomfortable
The *only* change in semantics I'm proposing is for users of
IronPython 2.6 which is not even at final release yet. CPython users
would be unaffected.
Sorry for top-posting, mobile device.
Michael
--
http://www.ironpythoninaction.com
On 9 Oct 2009, at 19:00, Brett Cannon wrote:
On Fr
2009/10/9 Chris Withers :
> Why not get it into the core as distutils.entrypoints? That's where it
> belongs...
Well, one reason is that it can't be distributed separately under that
name, and hence not be tested separately or bugfixed separately.
Rule #1 for inclusion in the standard library is
On Fri, Oct 9, 2009 at 10:57, Antoine Pitrou wrote:
> Chris Withers simplistix.co.uk> writes:
> >
> > *sigh* I don't see it as hijacking, provided Guido is making a BDFL
> > pronouncement that you're maintaining this software
>
> Well, what you are proposing *is* hijacking. PJE is not paid or em
On Fri, Oct 9, 2009 at 04:53, Michael Foord wrote:
> Christian Heimes wrote:
>
>> Michael Foord wrote:
>>
>>
>>> I really like this scheme. The important thing for IronPython is that we
>>> can get it into Python 2.6 (along with other fixes to make distutils
>>> compatible with IronPython - like n
Chris Withers simplistix.co.uk> writes:
>
> *sigh* I don't see it as hijacking, provided Guido is making a BDFL
> pronouncement that you're maintaining this software
Well, what you are proposing *is* hijacking. PJE is not paid or employed by
Guido, he is the full author of setuptools. Forking i
Probably all these discussions are better on distutils-sig (just
copying python-dev to note the movement of the discussion)
On Fri, Oct 9, 2009 at 11:49 AM, Michael Foord
wrote:
>> Outside of binaries on Windows, I'm still unsure if installing eggs
>> serves a useful purpose. I'm not sure if egg
Ian Bicking wrote:
On Fri, Oct 9, 2009 at 7:32 AM, Paul Moore wrote:
2009/10/9 Antoine Pitrou :
Ian Bicking colorstudy.com> writes:
Someone mentioned that easy_install provided some things pip didn't;
outside of multi-versioned installs (which I'm not very enthusiastic
about)
Toshio Kuratomi wrote:
On Fri, Oct 09, 2009 at 04:51:00PM +0100, Chris Withers wrote:
Tarek Ziadé wrote:
Virtualenv allows you to create an isolated environment to install
some distribution without polluting the
main site-packages, a bit like a user site-packages.
...as does buildout, and these
I'm crossposting to continue on distutils.
Ian Bicking a écrit :
> On Fri, Oct 9, 2009 at 3:54 AM, kiorky wrote:
> Well, if multi-versioned installs were deprecated, it would not be
> necessary to use Setuptools' style of script generation. Instead you
> could simply dereference the entry point,
On Fri, Oct 9, 2009 at 7:32 AM, Paul Moore wrote:
> 2009/10/9 Antoine Pitrou :
>> Ian Bicking colorstudy.com> writes:
>>>
>>> Someone mentioned that easy_install provided some things pip didn't;
>>> outside of multi-versioned installs (which I'm not very enthusiastic
>>> about) I'm not sure what
On Fri, Oct 09, 2009 at 04:51:00PM +0100, Chris Withers wrote:
> Tarek Ziadé wrote:
>> Virtualenv allows you to create an isolated environment to install
>> some distribution without polluting the
>> main site-packages, a bit like a user site-packages.
>
> ...as does buildout, and these are the rig
Tarek Ziadé wrote:
At Python and PyPI level, 'Setuptools' is PJE's project and he's the
one that manages the list of users that have
extended rights on his project.
Indeed, if only he would see sense :-(
In Distribute, our setup.py script makes sure setuptools is not in the
way. It is explici
On Fri, Oct 9, 2009 at 3:54 AM, kiorky wrote:
>> If I had my way, buildout would use virtualenv and throw away its
>> funny script generation. If virtualenv had existed before buildout
>
> Which one, the one provided to generate scripts from entry points with the
> *.egg
> recipes or the bin/bui
Tarek Ziadé wrote:
NB: There was no consensus on this "micro-language" on distutils-sig.
While I suspect I don't care as none of my packages rely on anything other
than other python packages, others did care, and I found the syntax Tarek
was proposing pretty clumsy.
Please no bikeshedding again
On Fri, Oct 9, 2009 at 6:08 PM, Chris Withers wrote:
>
> Shame there hasn't been any discussion of this recently on distutils-sig...
We had many discussion on this already. I don't mind to have another
round, on the contrary,
but let's do it in Distutils-SIG
We are making a lot of noise now in P
Tarek Ziadé wrote:
This PyPI feature is pretty new. It's great to have the client command
on Distribute.
If its usage spreads it'll make it to Distutils.
If you want to see it included Distutils (I do too) help us promoting its usage
The only thing that discourages me from using the PyPI docs
On Fri, Oct 9, 2009 at 6:03 PM, Chris Withers wrote:
> Tarek Ziadé wrote:
>>>
>>> How about helping the author of that extension make it work with
>>> Distribute
>>> or just get that implementation into Distutils core instead?
>>
>> It's the case. The author is a Distribute commiter and *he* has a
Tarek Ziadé wrote:
- distribute.entrypoints: that's the old pkg_resources entry points
system, but on its own. it uses distribute.resources
Why not get it into the core as distutils.entrypoints? That's where it
belongs...
What do you call 'core' ? distutils.core ?
Sorry, mean stdlib. distu
ACTIVITY SUMMARY (10/02/09 - 10/09/09)
Python tracker at http://bugs.python.org/
To view or respond to any of the issues listed below, click on the issue
number. Do NOT respond to this message.
2444 open (+44) / 16471 closed (+14) / 18915 total (+58)
Open issues with patches: 976
Average
On Fri, Oct 9, 2009 at 5:42 PM, Chris Withers wrote:
> Tarek Ziadé wrote:
>>
>> - The code is splitted in many packages and might be distributed under
>> several distributions.
>>
>> - distribute.resources: that's the old pkg_resources...
> Why not just call it pkg_resources and/or merge it wit
Tarek Ziadé wrote:
How about helping the author of that extension make it work with Distribute
or just get that implementation into Distutils core instead?
It's the case. The author is a Distribute commiter and *he* has added
it in Distribute.
Great, but about just getting it into Distutils?
On Fri, Oct 9, 2009 at 5:37 PM, Chris Withers wrote:
> Tarek Ziadé wrote:
>>
>> Some new commands are added there, when they are helpful and don't
>> interact with the rest. I am thinking
>> about "upload_docs" that let you upload documentation to PyPI. The
>> goal is to move it to Distutils
>> at
Tarek Ziadé wrote:
= Virtualenv and the multiple version support in Distribute =
(I am not saying "We" here because this part was not discussed yet
with everyone)
Good, so maybe take this discussion to distutils-sig first?
Virtualenv allows you to create an isolated environment to install
so
On Fri, Oct 9, 2009 at 5:32 PM, Chris Withers wrote:
>
>> So I am adding this in Distutils for 2.7.
>
> NB: There was no consensus on this "micro-language" on distutils-sig.
> While I suspect I don't care as none of my packages rely on anything other
> than other python packages, others did care,
Tarek Ziadé wrote:
- The code is splitted in many packages and might be distributed under
several distributions.
- distribute.resources: that's the old pkg_resources, but
reorganized in clean, pep-8 modules. This package will
only contain the query APIs and will focus on being PEP 376
co
Tarek Ziadé wrote:
Some new commands are added there, when they are helpful and don't
interact with the rest. I am thinking
about "upload_docs" that let you upload documentation to PyPI. The
goal is to move it to Distutils
at some point, if the documentation feature of PyPI stays and starts to be
Chris Withers simplistix.co.uk> writes:
>
> Well, if this was the BDFL pronouncement that a lot of people have taken
> it to be, does that allow Martin von Lewis to give the keys to
> http://pypi.python.org/pypi/setuptools to the "distribute" developers,
> so we can get on and use the original
Tarek Ziadé wrote:
== The fate of setup.py, and static metadata ==
So we are going to separate the metadata description from setup.py, in
a static configuration file, that can be open and read by anyone
without
running any code.
So we've worked on that lately in Distutils-SIG and came up wi
On Fri, Oct 9, 2009 at 5:01 PM, Chris Withers wrote:
> Guido van Rossum wrote:
>>
>> I'm saying that I don't expect setuptools 0.7 to appear before Tarek's
>> Distribute is mature and in widespread use. IOW I support Tarek's fork
>> and suggest nobody hold their breath waiting for setuptools 0.7.
Guido van Rossum wrote:
I'm saying that I don't expect setuptools 0.7 to appear before Tarek's
Distribute is mature and in widespread use. IOW I support Tarek's fork
and suggest nobody hold their breath waiting for setuptools 0.7.
Well, if this was the BDFL pronouncement that a lot of people ha
On 5 Oct, 01:04 pm, ziade.ta...@gmail.com wrote:
On Mon, Oct 5, 2009 at 2:50 PM, wrote:
Ned> Due to a change in distutils released with Python 2.6.3,
packages
Ned> that use setuptools (version 0.6c9, as of this writing), or
the
� �Ned> easy_install command, to build C extension m
Paul Moore wrote:
2009/10/9 Antoine Pitrou :
Ian Bicking colorstudy.com> writes:
Someone mentioned that easy_install provided some things pip didn't;
outside of multi-versioned installs (which I'm not very enthusiastic
about) I'm not sure what this is?
http://pip.openplans.org/
2009/10/9 Antoine Pitrou :
> Ian Bicking colorstudy.com> writes:
>>
>> Someone mentioned that easy_install provided some things pip didn't;
>> outside of multi-versioned installs (which I'm not very enthusiastic
>> about) I'm not sure what this is?
>
> http://pip.openplans.org/#differences-from-ea
M.-A. Lemburg wrote:
Christian Heimes wrote:
Nick Coghlan wrote:
Importing yet-another-module for use in site.py doesn't sound like a
great idea, so it may make sense to migrate that information into the
sys module is this approach is taken. "sys.name" is a little generic
though - somet
Christian Heimes wrote:
Michael Foord wrote:
I really like this scheme. The important thing for IronPython is that we
can get it into Python 2.6 (along with other fixes to make distutils
compatible with IronPython - like not attempting to bytecode-compile
when sys.dont_write_bytecode is Tru
Christian Heimes wrote:
> Nick Coghlan wrote:
>> Importing yet-another-module for use in site.py doesn't sound like a
>> great idea, so it may make sense to migrate that information into the
>> sys module is this approach is taken. "sys.name" is a little generic
>> though - something more explicit
Michael Foord wrote:
> I really like this scheme. The important thing for IronPython is that we
> can get it into Python 2.6 (along with other fixes to make distutils
> compatible with IronPython - like not attempting to bytecode-compile
> when sys.dont_write_bytecode is True).
I don't think my
Antoine Pitrou wrote:
> `usersitesuffix` should probably be a separate sys attribute, since it doesn't
> depend on the VM only, but also on the platform and version.
I don't really care and I'm happy to follow the herd in this matter. :)
Christian
___
Tarek Ziadé wrote:
> I have a suggestion though, that completes Nick's answer.
>
> distutils/command/install.py already contains install schemes and
> imports USER_SITE and USER_BASE to builds user-specific install
> schemes. I think it wouldn't hurt for clarity to reunite all these
> schemes in a
Christian Heimes cheimes.de> writes:
>
> >>> sys.vm
> sys.vm(id='cpython', name='CPython', platform='C',
> usersitesuffix='python26') # on win32: Python2.6
>
> >>> sys.vm
> sys.vm(id='ironpython', name='IronPython', platform='.NET',
> usersitesuffix='ironpython26) # on win32: IronPython2.6
`use
Nick Coghlan wrote:
> Christian Heimes wrote:
>> The solution requires a new attribute in the sys module that contains
>> the name of the implementation. As an alternative we could use the first
>> field of sys.subversion but I prefer an explicit attribute. I'm
>> proposing "sys.name" with a value
Ian Bicking colorstudy.com> writes:
>
> Someone mentioned that easy_install provided some things pip didn't;
> outside of multi-versioned installs (which I'm not very enthusiastic
> about) I'm not sure what this is?
http://pip.openplans.org/#differences-from-easy-install
If it's obsolete the we
Tarek Ziadé wrote:
> On Fri, Oct 9, 2009 at 10:20 AM, M.-A. Lemburg wrote:
>>
>> I know that the issue tracker for PyPI is (still) on SF, but
>> development appear to happen elsewhere and I can't find any
>> contact information on the PyPI web pages.
>
> Everything is provided here:
>
> http://w
On Fri, Oct 9, 2009 at 10:20 AM, M.-A. Lemburg wrote:
>
> I know that the issue tracker for PyPI is (still) on SF, but
> development appear to happen elsewhere and I can't find any
> contact information on the PyPI web pages.
Everything is provided here:
http://wiki.python.org/moin/CheeseShopDev
On Fri, Oct 9, 2009 at 3:22 AM, Ian Bicking wrote:
> I'm coming in late and breaking threading, but wanted to reply to
> Tarek's original email:
>
>> - easy_install is going to be deprecated ! use Pip !
>
> Cool! I wouldn't have written pip if I didn't think it would improve
> substantially on ea
Ian Bicking a écrit :
> I'm coming in late and breaking threading, but wanted to reply to
> Tarek's original email:
>
> This is verifiable, stable, and to varying degrees concrete
> (virtualenv being more concrete than buildout, which tends more
> towards the declarative).
Is that a friday troll
David Lyon wrote:
> On Thu, 08 Oct 2009 09:35:57 +0200, "M.-A. Lemburg" wrote:
>>> One could say that much of the setuptools cloud came about because of
>>> the lack of the queryable download url. Setuptools does a lot of work
>>> here to 'work-around' the ommission on pypi of a package download u
74 matches
Mail list logo
