[Python-Dev] PEP 391 - Please Vote!
In October 2009 I created PEP 391 to propose a new method of configuring logging using dictionaries: http://www.python.org/dev/peps/pep-0391/ In November 2009 I posted to this list that the PEP was ready for review. I have had numerous helpful comments from some of you, and I have incorporated most of them into updates to the PEP. Though I have the feeling from community discussions that the PEP has been generally favourably received - well I would think that, wouldn't I? ;-) - I've not asked for a vote and so I don't know the state of community consensus regarding this PEP. So, can you please indicate your vote for or against incorporating PEP 391 into Python? It would be nice if I could incorporate the changes before 2.7a3 is released! Ideally, I would like to check in the changes unless there are objections to doing so. All those who think that logging is currently hard to configure will benefit from these changes, so here's the opportunity to pipe up and improve things. Thanks & regards, Vinay Sajip ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 391 - Please Vote!
On Thu, Jan 14, 2010 at 10:23 AM, Vinay Sajip wrote: [..] > So, can you please indicate your vote for or against incorporating PEP 391 > into Python? It would > be nice if I could incorporate the changes before 2.7a3 is released! Ideally, > I would like to check > in the changes unless there are objections to doing so. All those who think > that logging is currently > hard to configure will benefit from these changes, so here's the opportunity > to pipe up and > improve things. FWIW, I am +1. Thanks for your work Tarek ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 391 - Please Vote!
On Thu, Jan 14, 2010 at 11:23 AM, Vinay Sajip wrote: > So, can you please indicate your vote for or against incorporating PEP 391 > into Python? I think the dict configuration scheme will be a great addition to the logging module. :) Schiavo Simon ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 391 - Please Vote!
2010/1/14 Vinay Sajip : > So, can you please indicate your vote for or against incorporating PEP 391 > into Python? I've no immediate need for the feature, but it would be good to have something like this, so I'm +1. Paul. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 391 - Please Vote!
Paul Moore wrote: > 2010/1/14 Vinay Sajip : >> So, can you please indicate your vote for or against incorporating PEP 391 >> into Python? > > I've no immediate need for the feature, but it would be good to have > something like this, so I'm +1. I'm in the same boat as Paul, but PEP 291 provides a nice forward compatible configuration scheme that will work with any application configuration approach that can produce an appropriate Python dictionary. So +1 from me too - I think the PEP has now taken this as far as theorising can go, and the only way to learn anything further is to put it into practice. Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia --- ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 391 - Please Vote!
Vinay Sajip wrote: > In October 2009 I created PEP 391 to propose a new method of > configuring logging using dictionaries: > > http://www.python.org/dev/peps/pep-0391/ Although one minor comment: you can probably remove the note about the "ext://" and "cfg://" prefixes being provisional at this stage. Those names look fine to me, so I don't see any point inviting a late-breaking bikeshed discussion about them. Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia --- ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 391 - Please Vote!
On Thu, Jan 14, 2010 at 4:23 AM, Vinay Sajip wrote: > In October 2009 I created PEP 391 to propose a new method of configuring > logging using dictionaries: > > http://www.python.org/dev/peps/pep-0391/ > > In November 2009 I posted to this list that the PEP was ready for review. > > I have had numerous helpful comments from some of you, and I have > incorporated most of them into updates to the PEP. Though I have the feeling > from community discussions that the PEP has been generally favourably > received - well I would think that, wouldn't I? ;-) - I've not asked for a > vote and so I don't know the state of community consensus regarding this PEP. > > So, can you please indicate your vote for or against incorporating PEP 391 > into Python? It would be nice if I could incorporate the changes before 2.7a3 > is released! Ideally, I would like to check in the changes unless there are > objections to doing so. All those who think that logging is currently hard to > configure will benefit from these changes, so here's the opportunity to pipe > up and improve things. > > Thanks & regards, > > Vinay Sajip I'm generally +1 - but given I know that Django 1.2 is slated to implement something somewhat similar, I'm interested to hear how this proposal meshes with their plan(s). jesse ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 391 - Please Vote!
> From: Jesse Noller > I'm generally +1 - but given I know that Django 1.2 is slated to > implement something somewhat similar, I'm interested to hear how this > proposal meshes with their plan(s).. Django 1.2 will most likely not implement logging - they're now in feature freeze for big features. See Russ Magee's post: http://groups.google.com/group/django-developers/msg/4ef81a2160257221 They're waiting for a Python decision and (from Russ Magee's post) seem to be in favour of the changes proposed in PEP 391. If we get these changes into Python soon, then Django 1.3 may be able to make use of them in its logging (which encompasses not just configuring Django logging in a settings.py, but also using logging internally throughout Django where it makes sense to do so). Assuming PEP 391 gets the nod, then after implementing the changes into Python, I plan to work with the Django community to get improved logging support in Django for 1.3. Regards, Vinay Sajip ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 391 - Please Vote!
On Jan 14, 2010, at 9:08 AM, Vinay Sajip wrote: >> From: Jesse Noller > >> I'm generally +1 - but given I know that Django 1.2 is slated to >> implement something somewhat similar, I'm interested to hear how this >> proposal meshes with their plan(s).. > > Django 1.2 will most likely not implement logging - they're now in feature > freeze for big features. See Russ Magee's post: > > http://groups.google.com/group/django-developers/msg/4ef81a2160257221 > > They're waiting for a Python decision and (from Russ Magee's post) seem to be > in favour of the changes proposed in PEP 391. If we get these changes into > Python soon, then Django 1.3 may be able to make use of them in its logging > (which encompasses not just configuring Django logging in a settings.py, but > also using logging internally throughout Django where it makes sense to do > so). > > Assuming PEP 391 gets the nod, then after implementing the changes into > Python, I plan to work with the Django community to get improved logging > support in Django for 1.3. That puts a huge +1 on there for me. If we can get this approved and have Django's logging improved *and* avoid a whole pile of duplicate effort in Django that's a huge win. S ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 391 - Please Vote!
On Thu, Jan 14, 2010 at 9:08 AM, Vinay Sajip wrote: >> From: Jesse Noller > >> I'm generally +1 - but given I know that Django 1.2 is slated to >> implement something somewhat similar, I'm interested to hear how this >> proposal meshes with their plan(s).. > > Django 1.2 will most likely not implement logging - they're now in feature > freeze for big features. See Russ Magee's post: > > http://groups.google.com/group/django-developers/msg/4ef81a2160257221 > > They're waiting for a Python decision and (from Russ Magee's post) seem to be > in favour of the changes proposed in PEP 391. If we get these changes into > Python soon, then Django 1.3 may be able to make use of them in its logging > (which encompasses not just configuring Django logging in a settings.py, but > also using logging internally throughout Django where it makes sense to do > so). > > Assuming PEP 391 gets the nod, then after implementing the changes into > Python, I plan to work with the Django community to get improved logging > support in Django for 1.3. > > Regards, > > Vinay Sajip > Cool, +1 then :) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PYTHON3PATH
Nick Coghlan wrote: > Guido van Rossum wrote: >> On Wed, Jan 13, 2010 at 9:57 AM, [email protected] > Or, how about >> just removing the antiquated use of environment variables altogether >> from Python 3 and avoid the issue completely. >> >> -1. They have their use, but more in controlled situations. If you >> have "global" env vars that you only want to use with Python 2.x, >> write a wrapper for Python 3 that invokes it with -E. > > Perhaps a case can be made for Python 3 to assume -E by default, with a > -e option to enable reading of the environment variables? > > That way naive users could run Python3 without tripping over existing > Python2 environment variables, while other tools could readily set up a > different environment before launching Python3. Naive users won't have PYTHONPATH or any other Python environment variables setup. Really, if you know that you are going to run Python 3 instead of Python 2 or vice-versa it's easy enough to run . py3env.sh or . py2env.sh in order to setup your shell environment, much like you typically do when using virtual Python installations or work on different projects that require different setups. If you just want to separate Python 2 and 3 files, use the user site-packages dir which includes the Python version. More experienced users could also write their own environment switching sitecustomize.py or usercustomize.py. And then there's the hackery option for experts that love dirty tricks: add a .pth file which includes an "import mysetup" line to fix-up you path and other settings. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 14 2010) >>> Python/Zope Consulting and Support ...http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ ::: Try our new mxODBC.Connect Python Database Interface for free ! eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PYTHON3PATH
M.-A. Lemburg wrote: > Nick Coghlan wrote: >> Guido van Rossum wrote: >>> On Wed, Jan 13, 2010 at 9:57 AM, [email protected] > Or, how about >>> just removing the antiquated use of environment variables altogether >>> from Python 3 and avoid the issue completely. >>> >>> -1. They have their use, but more in controlled situations. If you >>> have "global" env vars that you only want to use with Python 2.x, >>> write a wrapper for Python 3 that invokes it with -E. >> Perhaps a case can be made for Python 3 to assume -E by default, with a >> -e option to enable reading of the environment variables? >> >> That way naive users could run Python3 without tripping over existing >> Python2 environment variables, while other tools could readily set up a >> different environment before launching Python3. > > Naive users won't have PYTHONPATH or any other Python environment > variables setup. I was actually thinking of the situation where the OS had a preinstalled Python 2 with a default PYTHONPATH setting and the user was playing with Python 3. However, I agree that that is a fairly unlikely scenario (since preinstalled Pythons tend not to rely on the environment variables and a user sophisticated enough to be playing with a new Python interpreter should be able to cope with a few environment variable conflicts anyway). Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia --- ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PYTHON3PATH
On 14/01/2010 21:02, Nick Coghlan wrote: However, I agree that that is a fairly unlikely scenario (since preinstalled Pythons tend not to rely on the e Well, on the other hand I think that during the next few years it will be increasingly common for developers (and possibly users) to have Python 2 and Python 3 installed side-by-side. Many libraries and applications may never make the jump to Python 3 and Python users may be using 'legacy' Python 2 code for many years to come. It will also become increasingly common for developers to be using Python 3 *primarily* and for Python 3 only libraries and applications to emerge. Whilst there are workarounds we *are* in a situation that Python 2 and Python 3 share environment variables for the location of libraries and executing code on startup, whilst at the same time they are largely incompatible and need separate library paths and startup code. Michael -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PYTHON3PATH
"M.-A. Lemburg" writes: > > Naive users won't have PYTHONPATH or any other Python environment > variables setup. > > Really, if you know that you are going to run Python 3 instead of > Python 2 or vice-versa it's easy enough to run You don't even know that you're going to run python. I have 40 python scripts in my /usr/bin directory. > > . py3env.sh > or > . py2env.sh > > in order to setup your shell environment, much like you typically > do when using virtual Python installations or work on different > projects that require different setups. No, thanks. I'd rather setup my shell environment in ~/.zshrc, once. > > If you just want to separate Python 2 and 3 files, use the > user site-packages dir which includes the Python version. Both the bzr and mercurial wiki recommend setting PYTHONPATH in order to install those programs in a user's home directory. There are still people running python <2.6. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PYTHON3PATH
Ralf Schmitt wrote: > "M.-A. Lemburg" writes: > >> >> Naive users won't have PYTHONPATH or any other Python environment >> variables setup. >> >> Really, if you know that you are going to run Python 3 instead of >> Python 2 or vice-versa it's easy enough to run > > You don't even know that you're going to run python. I have 40 python > scripts in my /usr/bin directory. > >> >> . py3env.sh >> or >> . py2env.sh >> >> in order to setup your shell environment, much like you typically >> do when using virtual Python installations or work on different >> projects that require different setups. > > No, thanks. I'd rather setup my shell environment in ~/.zshrc, once. > >> >> If you just want to separate Python 2 and 3 files, use the >> user site-packages dir which includes the Python version. > > Both the bzr and mercurial wiki recommend setting PYTHONPATH in order to > install those programs in a user's home directory. There are still > people running python <2.6. Note that you only need to have a different PYTHONPATH setups for Python 2.x/3.x if you plan to run code that: * is not installed in site-packages (most OS shipped code will be found in the resp. system site-packages/ dir) * is not installed in a user site-packages directory (user installed code will typically go there (*)) * uses modules/packages that come in two different versions (one for Python 2.x and one for 3.x) and use the same name for both versions * needs to work in both Python 2.x and 3.x (*) The method for installing code in user site-packages dir is running: python setup.py install --user instead of the standard python setup.py install which install to the system-wide site-packages. BTW: I guess the bzr and mercurial wikis will need to be updated accordingly - at least for users of Python >=2.6. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 14 2010) >>> Python/Zope Consulting and Support ...http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ ::: Try our new mxODBC.Connect Python Database Interface for free ! eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] [ANN] Python 2.5.5 Release Candidate 1.
On behalf of the Python development team and the Python community, I'm happy to announce the release candidate 1 of Python 2.5.5. This is a source-only release that only includes security fixes. The last full bug-fix release of Python 2.5 was Python 2.5.4. Users are encouraged to upgrade to the latest release of Python 2.6 (which is 2.6.4 at this point). This releases fixes issues with the logging and tarfile modules, and with thread-local variables. See the detailed release notes at the website (also available as Misc/NEWS in the source distribution) for details of bugs fixed. For more information on Python 2.5.5, including download links for various platforms, release notes, and known issues, please see: http://www.python.org/2.5.5 Highlights of the previous major Python releases are available from the Python 2.5 page, at http://www.python.org/2.5/highlights.html Enjoy this release, Martin Martin v. Loewis [email protected] Python Release Manager (on behalf of the entire python-dev team) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
