Guido van Rossum wrote:
On Thu, Mar 26, 2009 at 10:26 PM, Greg Ewing
greg.ew...@canterbury.ac.nz wrote:
Guido van Rossum wrote:
I'll gladly take that as an added rationalization of my plea not to
change datetime.
In the case of datetime, could perhaps just the
module name be changed so
Nick Coghlan wrote:
I think the main thing that may be putting me off is the amount of
energy that went into deciding whether or not to emit Py3k warnings or
DeprecationWarning or PendingDeprecationWarning for use of the old
threading API.
Having made that decision, though, couldn't the
Greg Ewing wrote:
Nick Coghlan wrote:
I think the main thing that may be putting me off is the amount of
energy that went into deciding whether or not to emit Py3k warnings or
DeprecationWarning or PendingDeprecationWarning for use of the old
threading API.
Having made that decision,
Guido van Rossum wrote:
I'll gladly take that as an added rationalization of my plea not to
change datetime.
In the case of datetime, could perhaps just the
module name be changed so that it's not the same
as a name inside the module? Maybe call it
date_time or date_and_time.
--
Greg
On Thu, Mar 26, 2009 at 10:26 PM, Greg Ewing
greg.ew...@canterbury.ac.nz wrote:
Guido van Rossum wrote:
I'll gladly take that as an added rationalization of my plea not to
change datetime.
In the case of datetime, could perhaps just the
module name be changed so that it's not the same
as a
Guido van Rossum wrote:
Please don't do this. We need stable APIs. Trying to switch the entire
community to use CapWord APIs for something as commonly used as
datetime sounds like wasting a lot of cycles with no reason except the
mythical PEP 8 conformance. As I said, it's a pity we didn't
On Wed, Mar 25, 2009 at 5:46 AM, Nick Coghlan ncogh...@gmail.com wrote:
Guido van Rossum wrote:
Please don't do this. We need stable APIs. Trying to switch the entire
community to use CapWord APIs for something as commonly used as
datetime sounds like wasting a lot of cycles with no reason
Guido van Rossum wrote:
On Wed, Mar 25, 2009 at 5:46 AM, Nick Coghlan ncogh...@gmail.com wrote:
Having helped with that kind of rename once (and for a relatively small
API at that), I'd want a *really* compelling reason before ever going
through it again - it's messy, tedious and a really good
Please don't do this. We need stable APIs. Trying to switch the entire
community to use CapWord APIs for something as commonly used as
datetime sounds like wasting a lot of cycles with no reason except the
mythical PEP 8 conformance. As I said, it's a pity we didn't change
this at the 3.0 point,
On Tue, Mar 24, 2009 at 1:23 PM, Jess Austin jaus...@post.harvard.edu wrote:
On Tue, Mar 24, 2009 at 3:14 PM, Guido van Rossum gu...@python.org wrote:
Please don't do this. We need stable APIs. Trying to switch the entire
community to use CapWord APIs for something as commonly used as
datetime
On Tue, Mar 3 at 19:25:21 Guido van Rossum gu...@python.org wrote:
On Tue, Mar 3, 2009 at 5:15 PM, Brett Cannon br...@python.org wrote:
On Tue, Mar 3, 2009 at 05:13, rdmur...@bitdance.com wrote:
On Tue, 3 Mar 2009 at 06:01, Ivan Krsti?~G wrote:
On Mar 2, 2009, at 7:08 PM, Steve Holden
Benjamin Peterson wrote:
Yes, I'm already looking forward to Py4k now. :)
Shh, Guido will need at least 5 years before he's ready to contemplate
going through something like this again.
Or maybe a decade to be on the safe side ;)
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com |
On Wed, Mar 4, 2009 at 3:23 AM, Nick Coghlan ncogh...@gmail.com wrote:
Benjamin Peterson wrote:
Yes, I'm already looking forward to Py4k now. :)
Shh, Guido will need at least 5 years before he's ready to contemplate
going through something like this again.
Or maybe a decade to be on the
2009/3/4 Guido van Rossum gu...@python.org:
On Wed, Mar 4, 2009 at 3:23 AM, Nick Coghlan ncogh...@gmail.com wrote:
Benjamin Peterson wrote:
Yes, I'm already looking forward to Py4k now. :)
Shh, Guido will need at least 5 years before he's ready to contemplate
going through something like
On Tue, Mar 3, 2009 at 05:13, rdmur...@bitdance.com wrote:
On Tue, 3 Mar 2009 at 06:01, Ivan KrstiÄ~G wrote:
On Mar 2, 2009, at 7:08 PM, Steve Holden wrote:
PS.: so is datetime.datetime a builtin then? :)
Another historic accident. Like socket.socket. :-(
A pity this stuff wasn't
On Tue, Mar 3, 2009 at 5:15 PM, Brett Cannon br...@python.org wrote:
On Tue, Mar 3, 2009 at 05:13, rdmur...@bitdance.com wrote:
On Tue, 3 Mar 2009 at 06:01, Ivan KrstiÄ~G wrote:
On Mar 2, 2009, at 7:08 PM, Steve Holden wrote:
PS.: so is datetime.datetime a builtin then? :)
Another
We need a really long lead time before we can remove these. I
recommend starting with a *silent* deprecation in 3.1 combined with a
PR offensive for the new names.
I think the old names basically have to live forever in some way, due to
loading old pickles. Remember the problems we had when we
On Tue, Mar 3, 2009 at 17:30, Eric Smith e...@trueblade.com wrote:
We need a really long lead time before we can remove these. I
recommend starting with a *silent* deprecation in 3.1 combined with a
PR offensive for the new names.
I think the old names basically have to live forever in some
Brett Cannon wrote:
On Tue, Mar 3, 2009 at 17:30, Eric Smith e...@trueblade.com
mailto:e...@trueblade.com wrote:
We need a really long lead time before we can remove these. I
recommend starting with a *silent* deprecation in 3.1 combined
with a
PR
2009/3/3 Brett Cannon br...@python.org:
On Tue, Mar 3, 2009 at 17:30, Eric Smith e...@trueblade.com wrote:
We need a really long lead time before we can remove these. I
recommend starting with a *silent* deprecation in 3.1 combined with a
PR offensive for the new names.
I think the old
20 matches
Mail list logo
