Roy Smith r...@panix.com writes:
In article mailman.5231.1389240235.18130.python-l...@python.org,
Chris Angelico ros...@gmail.com wrote:
On Thu, Jan 9, 2014 at 2:35 PM, Roy Smith r...@panix.com wrote:
Yes, it *is* simple. It *is* easy. I've been working with pure-UTC
times (either called
On 09/01/2014 01:27, Roy Smith wrote:
In article laknps$umv$1...@dont-email.me,
Kevin Walzer k...@codebykevin.com wrote:
I haven't updated my Python apps to 3.x because there's nothing in 3.x
that offers benefits to my users.
I almost found a reason to move to Python 3 today. Then I got
On 09/01/2014 06:06, Kushal Kumaran wrote:
My local copy of the python 3.2.3 docs says:
classmethod datetime.utcnow()
Return the current UTC date and time, with tzinfo None. This is like
now(), but returns the current UTC date and time, as a naive
datetime object. An aware
Kushal Kumaran kushal.kuma...@gmail.com writes:
Roy Smith r...@panix.com writes:
How, in Python, do you get an aware UTC datetime object?
My local copy of the python 3.2.3 docs says:
classmethod datetime.utcnow()
Return the current UTC date and time, with tzinfo None. This is
Ben Finney ben+pyt...@benfinney.id.au writes:
Kushal Kumaran kushal.kuma...@gmail.com writes:
Roy Smith r...@panix.com writes:
How, in Python, do you get an aware UTC datetime object?
My local copy of the python 3.2.3 docs says:
classmethod datetime.utcnow()
Return the current UTC
On 09/01/2014 09:03, Ben Finney wrote:
Kushal Kumaran kushal.kuma...@gmail.com writes:
Roy Smith r...@panix.com writes:
How, in Python, do you get an aware UTC datetime object?
My local copy of the python 3.2.3 docs says:
classmethod datetime.utcnow()
Return the current UTC date and
Kushal Kumaran kushal.kuma...@gmail.com writes:
Yes, but the documentation for utcnow explicitly tells you how to get
an aware object.
An aware current UTC datetime can be obtained by calling
datetime.now(timezone.utc).
And in Python 2.7 you can just copy the definition of utc from the
Kushal Kumaran kushal.kuma...@gmail.com writes:
Ben Finney ben+pyt...@benfinney.id.au writes:
Kushal Kumaran kushal.kuma...@gmail.com writes:
Roy Smith r...@panix.com writes:
How, in Python, do you get an aware UTC datetime object?
classmethod datetime.utcnow()
Return the
Chris Angelico ros...@gmail.com writes:
On Thu, Jan 9, 2014 at 2:34 PM, Ben Finney ben+pyt...@benfinney.id.au wrote:
[ a bunch of stuff that I totally agree with ]
No response needed here :)
So I was wrong on the specific example of .today(), but asking the
question the other way is at
In article mailman.5244.1389254198.18130.python-l...@python.org,
Chris Angelico ros...@gmail.com wrote:
What can you (Roy), with your use-case, achieve with datetime that
you can't achieve (at least reasonably easily) with a timestamp?
As I'm mentioned several times, when you print a
On Fri, Jan 10, 2014 at 1:06 AM, Piet van Oostrum p...@vanoostrum.org wrote:
Chris Angelico ros...@gmail.com writes:
On Thu, Jan 9, 2014 at 2:34 PM, Ben Finney ben+pyt...@benfinney.id.au
wrote:
With time zones, as with text encodings, there is a single technically
elegant solution (for
In article mailman.5259.1389278063.18130.python-l...@python.org,
Chris Angelico ros...@gmail.com wrote:
Actually, the nearest parallel to Unicode is probably use UTC
everywhere, which makes for a superb internal representation and
transmission format, but bugs most human beings :)
It is, by
In article mailman.5257.1389274514.18130.python-l...@python.org,
Ben Finney ben+pyt...@benfinney.id.au wrote:
Kushal Kumaran kushal.kuma...@gmail.com writes:
Ben Finney ben+pyt...@benfinney.id.au writes:
Kushal Kumaran kushal.kuma...@gmail.com writes:
Roy Smith r...@panix.com
On Fri, Jan 10, 2014 at 1:14 AM, Roy Smith r...@panix.com wrote:
In article mailman.5244.1389254198.18130.python-l...@python.org,
Chris Angelico ros...@gmail.com wrote:
What can you (Roy), with your use-case, achieve with datetime that
you can't achieve (at least reasonably easily) with a
On Thu, 09 Jan 2014 09:14:22 -0500, Roy Smith wrote:
Oh, and another thing I can do with a datetime that I can't do with a
unix timestamp. I can represent the day I was born.
At the risk of dating myself, the day I was born is -231094800.
Dan
--
On Fri, Jan 10, 2014 at 2:01 AM, Dan Sommers d...@tombstonezero.net wrote:
On Thu, 09 Jan 2014 09:14:22 -0500, Roy Smith wrote:
Oh, and another thing I can do with a datetime that I can't do with a
unix timestamp. I can represent the day I was born.
At the risk of dating myself, the day I
On Thursday, January 9, 2014 9:57:57 AM UTC-5, Chris Angelico wrote:
And months are more
complicated still, so it's probably easiest to use strftime:
time.strftime(%Y%m,time.gmtime(ts))
'201401'
strftime is a non-starter at far as easy goes. I don't know about you, but I
certainly
On 09/01/2014 16:21, Roy Smith wrote:
No, it would be solved by a built-in method. Recipes are a cop-out. If
something is complicated enough to require a recipe, and used frequently enough
to be worth writing that recipe up and documenting it, you might as well have
gone the one additional
On 09/01/2014 16:30, Mark Lawrence wrote:
On 09/01/2014 16:21, Roy Smith wrote:
No, it would be solved by a built-in method. Recipes are a cop-out.
If something is complicated enough to require a recipe, and used
frequently enough to be worth writing that recipe up and documenting
it, you
and %s (which is incredibly useful) is not even documented (I suspect it's
also not available on all platforms).
The format specifiers available to Python are just whatever is available to the
underlying c time.h.
The manpage for strftime indicates that %s isn't part of the C standard, but
On 09/01/2014 16:42, Nick Cash wrote:
and %s (which is incredibly useful) is not even documented (I suspect it's
also not available on all platforms).
The format specifiers available to Python are just whatever is available to the
underlying c time.h.
The manpage for strftime indicates that
On 01/09/2014 12:42 AM, Mark Lawrence wrote:
On 09/01/2014 01:27, Roy Smith wrote:
Naive datetimes are what everybody uses. It's what utcnow() gives you.
So why make life difficult for everybody? Python 3 didn't win a convert
today.
Yep, dates and times are easy. That's why there are 17
Chris Angelico ros...@gmail.com writes:
On Fri, Jan 10, 2014 at 1:06 AM, Piet van Oostrum p...@vanoostrum.org wrote:
Chris Angelico ros...@gmail.com writes:
On Thu, Jan 9, 2014 at 2:34 PM, Ben Finney ben+pyt...@benfinney.id.au
wrote:
With time zones, as with text encodings, there is a
On 01/09/2014 06:57 AM, Chris Angelico wrote:
On Fri, Jan 10, 2014 at 1:14 AM, Roy Smith r...@panix.com wrote:
Thanks for this collection! Now we can discuss.
[snip]
Datetimes are self-describing. If I have a datetime or a timedelta, I
know what I've got. I've written more than one bug
I wrote:
Recipes are a cop-out
On Thursday, January 9, 2014 11:30:31 AM UTC-5, Mark Lawrence wrote:
So all of the itertools recipes should be part of the Python module and
not in more-itertools on pypi?
Certainly, the recipes that are documented on the official itertools page, yes.
--
On 09/01/2014 16:01, Ethan Furman wrote:
On 01/09/2014 12:42 AM, Mark Lawrence wrote:
On 09/01/2014 01:27, Roy Smith wrote:
Naive datetimes are what everybody uses. It's what utcnow() gives you.
So why make life difficult for everybody? Python 3 didn't win a convert
today.
Yep, dates and
On 09/01/2014 17:07, Roy Smith wrote:
I wrote:
Recipes are a cop-out
On Thursday, January 9, 2014 11:30:31 AM UTC-5, Mark Lawrence wrote:
So all of the itertools recipes should be part of the Python module and
not in more-itertools on pypi?
Certainly, the recipes that are documented on the
On 01/09/2014 10:18 AM, Mark Lawrence wrote:
On 09/01/2014 16:01, Ethan Furman wrote:
On 01/09/2014 12:42 AM, Mark Lawrence wrote:
On 09/01/2014 01:27, Roy Smith wrote:
Naive datetimes are what everybody uses. It's what utcnow() gives you.
So why make life difficult for everybody? Python 3
On 01/09/2014 10:20 AM, Mark Lawrence wrote:
On Thursday, January 9, 2014 11:30:31 AM UTC-5, Mark Lawrence wrote:
So all of the itertools recipes should be part of the Python module and
not in more-itertools on pypi?
Certainly, the recipes that are documented on the official itertools page,
On Fri, Jan 10, 2014 at 3:21 AM, Roy Smith r...@panix.com wrote:
On Thursday, January 9, 2014 9:57:57 AM UTC-5, Chris Angelico wrote:
And months are more
complicated still, so it's probably easiest to use strftime:
time.strftime(%Y%m,time.gmtime(ts))
'201401'
strftime is a non-starter at
On Fri, Jan 10, 2014 at 3:51 AM, Piet van Oostrum p...@vanoostrum.org wrote:
I don't know how other countries do it, but here, when the clock goes back,
it goes from 03:00 to 02:00. So I wonder how they communicate when your plane
leaves at 02:30 in that night. Which 02:30? In that case using
On Thursday, January 9, 2014 3:35:05 PM UTC-5, Chris Angelico wrote:
In fact, I've given end users the ability to enter strftime strings (eg
to construct a filename), and it's worked just fine.
I assume you realize that
../../../../../../../../../../../../../../../../etc/passwd is a valid
On Fri, Jan 10, 2014 at 7:54 AM, Roy Smith r...@panix.com wrote:
On Thursday, January 9, 2014 3:35:05 PM UTC-5, Chris Angelico wrote:
In fact, I've given end users the ability to enter strftime strings (eg
to construct a filename), and it's worked just fine.
I assume you realize that
Hi there,
On 01/07/2014 06:00 PM, Chris Angelico wrote:
I'm still not sure how Python 2.8 needs to differ from 2.7. Maybe the
touted upgrade path is simply a Python 2.7 installer plus a few handy
libraries/modules that will now be preinstalled? These modules look
great (I can't say, as I don't
On Wed, Jan 8, 2014 at 11:36 PM, Martijn Faassen faas...@startifact.com wrote:
Well, in the original article I argue that it may be risky for the Python
community to leave the large 2.7 projects behind because they tend to be the
ones that pay us in the end.
I also argue that for those
Martijn Faassen wrote:
I also argue that for those projects to move anywhere, they need a
clear, blessed, official, as simple as possible, incremental upgrade
path. That's why I argue for a Python 2.8.
That incremental upgrade path is Python 2.7.
Remember, when Python 3 first came out, the
On 08/01/2014 13:01, Steven D'Aprano wrote:
Martijn Faassen wrote:
I also argue that for those projects to move anywhere, they need a
clear, blessed, official, as simple as possible, incremental upgrade
path. That's why I argue for a Python 2.8.
That incremental upgrade path is Python 2.7.
On 08/01/2014 12:36, Martijn Faassen wrote:
Hi there,
On 01/07/2014 06:00 PM, Chris Angelico wrote:
I'm still not sure how Python 2.8 needs to differ from 2.7. Maybe the
touted upgrade path is simply a Python 2.7 installer plus a few handy
libraries/modules that will now be preinstalled? These
As somebody who is still firmly in the 2.x world, I'm worried about the
idea of a 2.x fork. While I have my doubts that 3.x was a good idea,
the fact is, it's here. Having the community fractured between the two
camps is not good. Let's say I'm somebody who wants to contribute some
OSS. I
On 08/01/2014 14:15, Roy Smith wrote:
As somebody who is still firmly in the 2.x world, I'm worried about the
idea of a 2.x fork. While I have my doubts that 3.x was a good idea,
the fact is, it's here. Having the community fractured between the two
camps is not good. Let's say I'm somebody
I think for new projects one should go with 3.x this is the right thing to
do. If you require a module that's 2.x only it's easy enough to port it
unless it depends on some monster like protobuf which doesn't have
python3.x support
Pedro.
On Wed, Jan 8, 2014 at 3:30 PM, Mark Lawrence
On Thu, Jan 9, 2014 at 1:30 AM, Mark Lawrence breamore...@yahoo.co.uk wrote:
But to be serious why not stick with 2.x if there's no compelling reason to
move? Whatever happened to if it ain't broke, don't fix it? And before
anyone says anything please don't start on about the bytes versus
On 01/08/2014 01:46 PM, Chris Angelico wrote:
On Wed, Jan 8, 2014 at 11:36 PM, Martijn Faassen faas...@startifact.com wrote:
Well, in the original article I argue that it may be risky for the Python
community to leave the large 2.7 projects behind because they tend to be the
ones that pay us in
On 2014-01-08, Chris Angelico ros...@gmail.com wrote:
Two reasons for moving:
1) Support for newer hardware
How does Python 3.x support newer hardware than Python 2.7?
--
Grant Edwards grant.b.edwardsYow! Psychoanalysis??
at
Hey,
I'm pointing out possible improvements that Python 2.8 could offer that
would help incremental porting efforts of applications. I'm pointing
about that helping application developers move forward incrementally may
be a worthwhile consideration. Like, there's money there.
You can point
Hey,
On 01/08/2014 03:30 PM, Mark Lawrence wrote:
But to be serious why not stick with 2.x if there's no compelling reason
to move? Whatever happened to if it ain't broke, don't fix it?
That's fine for static applications that don't have to change.
Successful applications tend to grow new
On Thu, Jan 9, 2014 at 2:06 AM, Grant Edwards invalid@invalid.invalid wrote:
On 2014-01-08, Chris Angelico ros...@gmail.com wrote:
Two reasons for moving:
1) Support for newer hardware
How does Python 3.x support newer hardware than Python 2.7?
At the moment, I would say there's no
On Thu, Jan 9, 2014 at 2:22 AM, Martijn Faassen faas...@startifact.com wrote:
I'm pointing out possible improvements that Python 2.8 could offer that
would help incremental porting efforts of applications. I'm pointing about
that helping application developers move forward incrementally may be
On 08/01/2014 15:39, Chris Angelico wrote:
On Thu, Jan 9, 2014 at 2:22 AM, Martijn Faassen faas...@startifact.com wrote:
I'm pointing out possible improvements that Python 2.8 could offer that
would help incremental porting efforts of applications. I'm pointing about
that helping application
On 1/8/2014 9:15 AM, Roy Smith wrote:
As somebody who is still firmly in the 2.x world, I'm worried about the
idea of a 2.x fork. While I have my doubts that 3.x was a good idea,
the fact is, it's here. Having the community fractured between the two
camps is not good. Let's say I'm somebody
Martijn Faassen wrote:
Hey,
I'm pointing out possible improvements that Python 2.8 could offer that
would help incremental porting efforts of applications. I'm pointing
about that helping application developers move forward incrementally may
be a worthwhile consideration. Like, there's
On 1/8/14, 9:30 AM, Mark Lawrence wrote:
But to be serious why not stick with 2.x if there's no compelling reason
to move? Whatever happened to if it ain't broke, don't fix it? And
before anyone says anything please don't start on about the bytes versus
string debate, I'm fairly certain that
In article laknps$umv$1...@dont-email.me,
Kevin Walzer k...@codebykevin.com wrote:
I haven't updated my Python apps to 3.x because there's nothing in 3.x
that offers benefits to my users.
I almost found a reason to move to Python 3 today. Then I got smacked.
I had a datetime. I needed a
On Thu, Jan 9, 2014 at 12:27 PM, Roy Smith r...@panix.com wrote:
Anyway, I discovered that Python 3.3's datetime has a .timestamp()
method. Yeah. Finally. Exactly what the world had needed for years.
Then I kept reading and found:
Note: There is no method to obtain the POSIX timestamp
On 01/08/2014 05:27 PM, Roy Smith wrote:
In article laknps$umv$1...@dont-email.me,
Kevin Walzer k...@codebykevin.com wrote:
I haven't updated my Python apps to 3.x because there's nothing in 3.x
that offers benefits to my users.
I almost found a reason to move to Python 3 today. Then I
On Thu, Jan 9, 2014 at 12:52 PM, Ethan Furman et...@stoneleaf.us wrote:
as soon as you try to mix different timezone datetimes that are naive, you
have a mess (temporal-bake, anyone?).
Doctor Who gets into cookies?
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
In article mailman.5222.1389232077.18130.python-l...@python.org,
Chris Angelico ros...@gmail.com wrote:
Why not simply use a UTC datetime instead of a naive one?
[Pet peeve of mine: uses of simple or just to imply that something
is easy, when it's not. Why not just get the Arabs and the Jews
On Thu, Jan 9, 2014 at 1:25 PM, Roy Smith r...@panix.com wrote:
Because it's easy to get a naive one. You call datetime.utcnow(). If
utcnow() returned an aware datetime, that's probably what we would be
using. Why didn't utcnow() just return an aware datetime to begin with?
Conversely,
Chris Angelico ros...@gmail.com writes:
On Thu, Jan 9, 2014 at 1:25 PM, Roy Smith r...@panix.com wrote:
Because it's easy to get a naive one. You call datetime.utcnow(). If
utcnow() returned an aware datetime, that's probably what we would
be using. Why didn't utcnow() just return an aware
In article mailman.5226.1389237436.18130.python-l...@python.org,
Chris Angelico ros...@gmail.com wrote:
On Thu, Jan 9, 2014 at 1:25 PM, Roy Smith r...@panix.com wrote:
Because it's easy to get a naive one. You call datetime.utcnow(). If
utcnow() returned an aware datetime, that's probably
On Thu, Jan 9, 2014 at 2:34 PM, Ben Finney ben+pyt...@benfinney.id.au wrote:
[ a bunch of stuff that I totally agree with ]
No response needed here :)
So I was wrong on the specific example of .today(), but asking the
question the other way is at least helpful. Maybe the best solution is
In article mailman.5227.1389238511.18130.python-l...@python.org,
Ben Finney ben+pyt...@benfinney.id.au wrote:
Chris Angelico ros...@gmail.com writes:
On Thu, Jan 9, 2014 at 1:25 PM, Roy Smith r...@panix.com wrote:
Because it's easy to get a naive one. You call datetime.utcnow(). If
On Thu, Jan 9, 2014 at 2:35 PM, Roy Smith r...@panix.com wrote:
Yes, it *is* simple. It *is* easy. I've been working with pure-UTC
times (either called time_t, or TIMESTAMP WITH TIME ZONE, or even just
float) for decades. Like with so many other things, the easiest
solution is also the best,
In article mailman.5231.1389240235.18130.python-l...@python.org,
Chris Angelico ros...@gmail.com wrote:
On Thu, Jan 9, 2014 at 2:35 PM, Roy Smith r...@panix.com wrote:
Yes, it *is* simple. It *is* easy. I've been working with pure-UTC
times (either called time_t, or TIMESTAMP WITH TIME
On Thu, Jan 9, 2014 at 3:29 PM, Roy Smith r...@panix.com wrote:
So, I'd like to see your code which generates an aware UTC datetime
object in Python. And then we can argue about whether it's simple or
not :-)
Like I said, I don't use the datetime module. But fundamentally, an
aware datetime
On Thu, Jan 9, 2014 at 3:29 PM, Roy Smith r...@panix.com wrote:
So, I'd like to see your code which generates an aware UTC datetime
object in Python. And then we can argue about whether it's simple or
not :-)
In fact, I'll go further. Why do you need a datetime object at all?
What is it that
On 01/08/2014 08:34 PM, Chris Angelico wrote:
On Thu, Jan 9, 2014 at 3:29 PM, Roy Smith r...@panix.com wrote:
So, I'd like to see your code which generates an aware UTC datetime
object in Python. And then we can argue about whether it's simple or
not :-)
Like I said, I don't use the datetime
On Thu, Jan 9, 2014 at 4:31 PM, Ethan Furman et...@stoneleaf.us wrote:
On 01/08/2014 08:34 PM, Chris Angelico wrote:
This is simple:
time.time()
1389242048.669482
I agree, and I'm sure Roy also agrees, that that is simple. However, that
is *not* a timezone-aware datetime. The point of
Chris Angelico ros...@gmail.com writes:
What exactly does datetime offer you that a timestamp doesn't? Can we
get a quick run-down, please?
Isn't this answered by you reading the standard library documentation
for the ‘datetime’ and ‘time’ modules? Are you asking for someone to
read those for
On 09/01/2014 03:42, Chris Angelico wrote:
On Thu, Jan 9, 2014 at 2:34 PM, Ben Finney ben+pyt...@benfinney.id.au wrote:
[ a bunch of stuff that I totally agree with ]
No response needed here :)
So I was wrong on the specific example of .today(), but asking the
question the other way is at
On Thu, Jan 9, 2014 at 5:57 PM, Ben Finney ben+pyt...@benfinney.id.au wrote:
Chris Angelico ros...@gmail.com writes:
What exactly does datetime offer you that a timestamp doesn't? Can we
get a quick run-down, please?
Isn't this answered by you reading the standard library documentation
for
On 01/07/2014 01:19 AM, Chris Angelico wrote:
Can we get a run-down of everything that actually must be broken in
2.7 - 3.3, that can't be backported via __future__, so we can start
cherry-picking which bits to break in 2.8? The biggest one is going to
be Unicode strings, for a large number of
Hi there,
I just tried this out with the future module to see what it actually
does, and I got this:
On 01/07/2014 01:54 PM, Martijn Faassen wrote:
First the Python 3 behavior:
py3str + py3str = py3str
Yup, of course.
py3bytes + py3bytes = py3bytes
Again of course.
py3str +
Hi,
I've posted a documentation issue to the 'future' module which includes
a further evolution of my thinking. As I expected, the author of the
'future' module has thought this through more than I had:
https://github.com/PythonCharmers/python-future/issues/27
To get back to a hypothetical
On Wed, Jan 8, 2014 at 3:42 AM, Martijn Faassen faas...@startifact.com wrote:
To get back to a hypothetical Python 2.8, it could implement this kind of
behavior, and I think it would help support incremental upgrades. As long as
you're using Py 3 bytes and str in your code, you'll be aware of
http://blog.startifact.com/posts/python-2-gravity.html
A Way Forward - How to go forward then? I think it makes sense to work as
hard as possible to lift those Python 2 codebases out of the gravity well.
I think this is complete nonsense. There's only been five years since the
first
On 06/01/2014 19:41, Mark Janssen wrote:
http://blog.startifact.com/posts/python-2-gravity.html
A Way Forward - How to go forward then? I think it makes sense to work as
hard as possible to lift those Python 2 codebases out of the gravity well.
I think this is complete nonsense. There's only
On Tue, Jan 7, 2014 at 6:26 AM, Mark Lawrence breamore...@yahoo.co.uk wrote:
http://blog.startifact.com/posts/python-2-gravity.html
A Way Forward - How to go forward then? I think it makes sense to work as
hard as possible to lift those Python 2 codebases out of the gravity well.
I think
On Mon, Jan 6, 2014 at 4:19 PM, Chris Angelico ros...@gmail.com wrote:
Can we get a run-down of everything that actually must be broken in
2.7 - 3.3, that can't be backported via __future__, so we can start
cherry-picking which bits to break in 2.8? The biggest one is going to
be Unicode
On Tue, Jan 7, 2014 at 11:27 AM, Devin Jeanpierre
jeanpierr...@gmail.com wrote:
For example, I imagine that it is kind of _silly_ to have a
__future__.disable_str_autoencoding on a per-module basis, because
some modules' functions will fail when they are given the wrong type,
and some won't --
On Mon, Jan 6, 2014 at 5:00 PM, Chris Angelico ros...@gmail.com wrote:
On Tue, Jan 7, 2014 at 11:27 AM, Devin Jeanpierre
jeanpierr...@gmail.com wrote:
For example, I imagine that it is kind of _silly_ to have a
__future__.disable_str_autoencoding on a per-module basis, because
some modules'
On Tue, Jan 7, 2014 at 12:55 PM, Devin Jeanpierre
jeanpierr...@gmail.com wrote:
What if we decide there is no single source of responsibility, and it
can't be limited exactly to a module, and make a __future__ feature
the best we can regardless? We can still exact some benefit from a
sloppy
On Mon, Jan 6, 2014 at 6:00 PM, Chris Angelico ros...@gmail.com wrote:
On Tue, Jan 7, 2014 at 12:55 PM, Devin Jeanpierre
jeanpierr...@gmail.com wrote:
What if we decide there is no single source of responsibility, and it
can't be limited exactly to a module, and make a __future__ feature
the
On Tue, Jan 7, 2014 at 1:15 PM, Devin Jeanpierre jeanpierr...@gmail.com wrote:
The other alternative is having + (etc.) do something different
depending on what module it's in. It's not hard to do: add a condition
to all places where Python automatically converts, and check the call
stack to
On Mon, Jan 6, 2014 at 6:28 PM, Chris Angelico ros...@gmail.com wrote:
class Foo(str):
def __add__(self, other):
if isinstance(other, unicode): return self + other.encode(cp500)
return str.__add__(self, other)
What happens if you have the __future__ directive disabling
On Tue, Jan 7, 2014 at 2:12 PM, Devin Jeanpierre jeanpierr...@gmail.com wrote:
Doing a flag like that that enables a backwards incompatible change
does in fact address that issue you were worried about originally, so
that's something. And feature-by-feature moves are, like the OP said,
still
86 matches
Mail list logo
