> 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 al
--
http://www.ironpythoninaction.com
On 19 Feb 2010, at 22:52, Eric Smith 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 this should best work
On Fri, Feb 19, 2010 at 5:41 PM, Mike Klaas wrote:
> On Fri, Feb 19, 2010 at 9:03 AM, Sjoerd Mullender 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
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 shoul
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 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 mor
On Fri, Feb 19, 2010 at 9:03 AM, Sjoerd Mullender 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 aware of it, b
On 19/02/2010 16:30, Gregory P. Smith wrote:
On Fri, Feb 19, 2010 at 4:18 PM, P.J. Eby 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 id
On Fri, 19 Feb 2010 14:35:42 -0700, Dj Gilcrease wrote:
> On 2/19/10, P.J. Eby 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
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 o
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 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 ge
On Fri, Feb 19, 2010 at 4:18 PM, P.J. Eby 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 more opiniona
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 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" sc
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 t
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 ques
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 some
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
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 Dep
On Fri, 19 Feb 2010 06:40:00 +0100, 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 approval by
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 wri
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
On Fri, Feb 19, 2010 at 07:27, Stuart Bishop 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 I'm describing.
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.
Eric Smith 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 Fri, Feb 19, 2010 at 08:40, 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
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 i
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 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
wrote:
> -On [20100219 08:37], Simon Cross (hodgestar+pyt
Isn't mhlib itself deprecated? (It's gone in Py3k.)
On Fri, Feb 19, 2010 at 4:33 AM, Sjoerd Mullender 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 mere user there
-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 th
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
construc
32 matches
Mail list logo
