I have noticed that deprecated stuff is still being used in the standard
Python library. When using modules that contain deprecated stuff you
get a warning, and as a mere user there isn't much you can do about that.
As a general rule, the Python standard library should not use deprecated
-On [20100219 08:37], Simon Cross (hodgestar+python...@gmail.com) wrote:
We need someone to maintain the copy of ElementTree in the Python
repository. Ideally this means pulling upgrades and bugfixes from
Fredrik's repository every now and then.
Which will give you nothing as that tree hasn't
Isn't mhlib itself deprecated? (It's gone in Py3k.)
On Fri, Feb 19, 2010 at 4:33 AM, Sjoerd Mullender sjo...@acm.org wrote:
I have noticed that deprecated stuff is still being used in the standard
Python library. When using modules that contain deprecated stuff you
get a warning, and as a
All, I hope that Fredrik himself has time to chime in at least
briefly, but he told me off-line that he sees nothing controversial in
the currently proposed set of changes.
On Fri, Feb 19, 2010 at 5:04 AM, Jeroen Ruigrok van der Werven
asmo...@in-nomine.org wrote:
-On [20100219 08:37], Simon
On 2010-02-19 14:10, Guido van Rossum wrote:
Isn't mhlib itself deprecated? (It's gone in Py3k.)
I wouldn't like that, but it is beside my point. If a module is
deprecated, then it should not be used in released code.
If mhlib is deprecated, it doesn't tell you about it. mhlib uses
multifile
Sjoerd Mullender wrote:
On 2010-02-19 14:10, Guido van Rossum wrote:
Isn't mhlib itself deprecated? (It's gone in Py3k.)
I wouldn't like that, but it is beside my point. If a module is
deprecated, then it should not be used in released code.
If mhlib is deprecated, it doesn't tell you about
On Fri, Feb 19, 2010 at 08:40, Sjoerd Mullender sjo...@acm.org wrote:
On 2010-02-19 14:10, Guido van Rossum wrote:
Isn't mhlib itself deprecated? (It's gone in Py3k.)
I wouldn't like that, but it is beside my point. If a module is
deprecated, then it should not be used in released code.
Eric Smith eric at trueblade.com writes:
This is because no one has gotten around to it. Create a bug report for
it, and preferably attach a patch with tests.
Eric.
Actually, it gives py3k warning about mhlib + 2 others warnings:
./python/release26-maint/ $ ./python -Wd -3 -c import
On 2010-02-19 14:45, Eric Smith wrote:
Sjoerd Mullender wrote:
On 2010-02-19 14:10, Guido van Rossum wrote:
Isn't mhlib itself deprecated? (It's gone in Py3k.)
I wouldn't like that, but it is beside my point. If a module is
deprecated, then it should not be used in released code.
If mhlib
On Fri, Feb 19, 2010 at 07:27, Stuart Bishop stu...@stuartbishop.net wrote:
In any case, since you want to make a version that can be included and
uses the timezone API, I guess that's a moot question until we have
that version. :)
As I understand it dateutil pretty much already provides what
Sjoerd Mullender wrote:
My point is, as a matter of *policy*, nothing should be released that
uses deprecated stuff. I can't create a bug report about wrong (or
incomplete) policies.
The policy is more that the test suite shouldn't raise Deprecation
Warnings unless it is explicitly checking
My notes from the session I led:
+ argparse
- Same issues brought up.
+ Hg transition
- Just updated everyone; Dirkjan said everything I did in his email update.
+ Stdlib breakout
- Mentioned; nothing planned beyond a PEP at some point.
+ Extension module policy
- If you
On Fri, 19 Feb 2010 06:40:00 +0100, mar...@v.loewis.de wrote:
Antoine Pitrou wrote:
Le Thu, 18 Feb 2010 22:46:41 +0100, Martin v. Löwis a écrit :
It's time to comment and review.
Unfortunately, it's not. I strongly object to any substantial change to
the code base without explicit
On 2010-02-19 16:23, Nick Coghlan wrote:
Sjoerd Mullender wrote:
My point is, as a matter of *policy*, nothing should be released that
uses deprecated stuff. I can't create a bug report about wrong (or
incomplete) policies.
The policy is more that the test suite shouldn't raise Deprecation
Lennart I would like if we could look into making a timezone module
Lennart that works on Python 2.5 to 3.2 that uses system data...
2.5, 2.6 and 3.1 are completely off the radar screen at this point. The
best you could hope for is that someone backports whatever is created for
2.7 or
This is a proto-proposal for including some functionality from virtualenv in
Python itself. I'm not entirely confident about what I'm proposing, so it's
not really PEP-ready, but I wanted to get feedback...
First, a bit about how virtualenv works (this will use Linux conventions;
Windows and
This sounds like a great idea (especially since I proposed something a
little bit like it in yesterday's language summit :-).
I have to admit I cannot remember what uses are made of sys.prefix; it
would be good to explicitly enumerate these in the PEP when you write
it.
Regarding the Windows
Le Fri, 19 Feb 2010 13:49:23 -0500, Ian Bicking a écrit :
* I'd rather ~/env/bin/python be a symlink instead of copying it.
How about simply adding a --prefix argument to the interpreter. Then
virtualenv can create a python script that simply adds --prefix and
forwards all the arguments to
On Feb 19, 2010, at 11:45 AM, Antoine Pitrou wrote:
Le Fri, 19 Feb 2010 13:49:23 -0500, Ian Bicking a écrit :
* I'd rather ~/env/bin/python be a symlink instead of copying it.
How about simply adding a --prefix argument to the interpreter. Then
virtualenv can create a python script that
At 01:49 PM 2/19/2010 -0500, Ian Bicking wrote:
I'm not sure how this should best work on Windows (without symlinks,
and where things generally work differently), but I would hope if
this idea is more visible that someone more opinionated than I would
propose the appropriate analog on Windows.
On Fri, Feb 19, 2010 at 4:18 PM, P.J. Eby p...@telecommunity.com wrote:
At 01:49 PM 2/19/2010 -0500, Ian Bicking wrote:
I'm not sure how this should best work on Windows (without symlinks, and
where things generally work differently), but I would hope if this idea is
more visible that someone
win2k and later have a form of sym link, the api for it is just not
provided in a nice simple app like it is on nix platforms.
On 2/19/10, P.J. Eby p...@telecommunity.com wrote:
At 01:49 PM 2/19/2010 -0500, Ian Bicking wrote:
I'm not sure how this should best work on Windows (without symlinks,
I develop OpenRPG and 90% of our user base is on windows. We require
the user to install python and wxPython from msi because our app
supports GUI plugins so to ensure the user can use any plugin even if
it isnt prepackaged they need to have the full python and wxPython
installed.
We are working
On Fri, 19 Feb 2010 14:35:42 -0700, Dj Gilcrease digitalx...@gmail.com wrote:
On 2/19/10, P.J. Eby p...@telecommunity.com wrote:
At 01:49 PM 2/19/2010 -0500, Ian Bicking wrote:
I'm not sure how this should best work on Windows (without symlinks,
and where things generally work differently),
On 19/02/2010 16:30, Gregory P. Smith wrote:
On Fri, Feb 19, 2010 at 4:18 PM, P.J. Ebyp...@telecommunity.com wrote:
At 01:49 PM 2/19/2010 -0500, Ian Bicking wrote:
I'm not sure how this should best work on Windows (without symlinks, and
where things generally work differently), but
On Fri, Feb 19, 2010 at 9:03 AM, Sjoerd Mullender sjo...@acm.org wrote:
The policy should also be, if someone decides (or rather, implements) a
deprecation of a module, they should do a grep to see where that module
is used and fix the code. It's not rocket science.
I'm not sure if you're
On approximately 2/19/2010 1:18 PM, came the following characters from
the keyboard of P.J. Eby:
At 01:49 PM 2/19/2010 -0500, Ian Bicking wrote:
I'm not sure how this should best work on Windows (without symlinks,
and where things generally work differently), but I would hope if
this idea is
Glenn Linderman wrote:
On approximately 2/19/2010 1:18 PM, came the following characters from
the keyboard of P.J. Eby:
At 01:49 PM 2/19/2010 -0500, Ian Bicking wrote:
I'm not sure how this should best work on Windows (without symlinks,
and where things generally work differently), but I would
On approximately 2/19/2010 7:52 PM, came the following characters from
the keyboard of Eric Smith:
Glenn Linderman wrote:
On approximately 2/19/2010 1:18 PM, came the following characters
from the keyboard of P.J. Eby:
At 01:49 PM 2/19/2010 -0500, Ian Bicking wrote:
I'm not sure how this
On Fri, Feb 19, 2010 at 5:41 PM, Mike Klaas mike.kl...@gmail.com wrote:
On Fri, Feb 19, 2010 at 9:03 AM, Sjoerd Mullender sjo...@acm.org wrote:
The policy should also be, if someone decides (or rather, implements) a
deprecation of a module, they should do a grep to see where that module
is
--
http://www.ironpythoninaction.com
On 19 Feb 2010, at 22:52, Eric Smith e...@trueblade.com wrote:
Glenn Linderman wrote:
On approximately 2/19/2010 1:18 PM, came the following characters
from the keyboard of P.J. Eby:
At 01:49 PM 2/19/2010 -0500, Ian Bicking wrote:
I'm not sure how
My point is, as a matter of *policy*, nothing should be released that
uses deprecated stuff. I can't create a bug report about wrong (or
incomplete) policies.
Sure you can. Write a bug report asking that PEP 4 gets amended with
specific wording.
Not that PEP 4 is followed in practice at all,
32 matches
Mail list logo
