On Fri, Jan 10, 2014 at 7:54 AM, Roy Smith 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
> "../../../../
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 3:51 AM, Piet van Oostrum 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 UTC may come
>
On Fri, Jan 10, 2014 at 3:21 AM, Roy Smith 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-start
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, ye
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 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 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 t
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.
--
htt
Chris Angelico writes:
> On Fri, Jan 10, 2014 at 1:06 AM, Piet van Oostrum wrote:
>> Chris Angelico writes:
>>
>>> On Thu, Jan 9, 2014 at 2:34 PM, Ben Finney
>>> wrote:
With time zones, as with text encodings, there is a single technically
elegant solution (for text: Unicode; for ti
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 is
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 06:57 AM, Chris Angelico wrote:
On Fri, Jan 10, 2014 at 1:14 AM, Roy Smith 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 where I assume
> 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, bu
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
>
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 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
On Fri, Jan 10, 2014 at 2:01 AM, Dan Sommers 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 was born is -231
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
--
https://mail.python.org/mailman/listinfo/pyt
On Fri, Jan 10, 2014 at 1:14 AM, Roy Smith wrote:
> In article ,
> Chris Angelico wrote:
>
>> What can you (Roy), with your use-case, achieve with datetime that
>> you can't achieve (at least reasonably easily) with a timestamp?
Thanks for this collection! Now we can discuss.
> As I'm mentione
In article ,
Ben Finney wrote:
> Kushal Kumaran writes:
>
> > Ben Finney writes:
> >
> > > Kushal Kumaran writes:
> > >
> > >> Roy Smith writes:
> > >> > How, in Python, do you get an aware UTC datetime object?
> > >>
> > >> classmethod datetime.utcnow()
> > >>
> > >> Return the current
In article ,
Chris Angelico 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 the way, the solution that the aviation industry has adopted.
On Fri, Jan 10, 2014 at 1:06 AM, Piet van Oostrum wrote:
> Chris Angelico writes:
>
>> On Thu, Jan 9, 2014 at 2:34 PM, Ben Finney
>> wrote:
>>> With time zones, as with text encodings, there is a single technically
>>> elegant solution (for text: Unicode; for time zones: twelve simple,
>>> stat
In article ,
Chris Angelico 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 datetime, you get
something that's human friendly. When you print a time
Chris Angelico writes:
> On Thu, Jan 9, 2014 at 2:34 PM, Ben Finney 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
Kushal Kumaran writes:
> Ben Finney writes:
>
> > Kushal Kumaran writes:
> >
> >> Roy Smith writes:
> >> > How, in Python, do you get an aware UTC datetime object?
> >>
> >> classmethod datetime.utcnow()
> >>
> >> Return the current UTC date and time, with tzinfo None. […]
> >
> > No, that
Kushal Kumaran 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 doc and use
that
On 09/01/2014 09:03, Ben Finney wrote:
Kushal Kumaran writes:
Roy Smith 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
li
Ben Finney writes:
> Kushal Kumaran writes:
>
>> Roy Smith 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
>>
Kushal Kumaran writes:
> Roy Smith 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
> like now(), but returns the cur
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 curre
On 09/01/2014 01:27, Roy Smith wrote:
In article ,
Kevin Walzer 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 unix timest
Roy Smith writes:
> In article ,
> Chris Angelico wrote:
>
>> On Thu, Jan 9, 2014 at 2:35 PM, Roy Smith 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 wi
On Thu, Jan 9, 2014 at 5:57 PM, Ben Finney wrote:
> Chris Angelico 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?
On 09/01/2014 03:42, Chris Angelico wrote:
On Thu, Jan 9, 2014 at 2:34 PM, Ben Finney 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
Chris Angelico 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 you? If not, ca
On Thu, Jan 9, 2014 at 4:31 PM, Ethan Furman 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 o
On 01/08/2014 08:34 PM, Chris Angelico wrote:
On Thu, Jan 9, 2014 at 3:29 PM, Roy Smith 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 fu
On Thu, Jan 9, 2014 at 3:29 PM, Roy Smith 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 you need? Ar
On Thu, Jan 9, 2014 at 3:29 PM, Roy Smith 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 represents an
In article ,
Chris Angelico wrote:
> On Thu, Jan 9, 2014 at 2:35 PM, Roy Smith 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
On Thu, Jan 9, 2014 at 2:35 PM, Roy Smith 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, because
In article ,
Ben Finney wrote:
> Chris Angelico writes:
>
> > On Thu, Jan 9, 2014 at 1:25 PM, Roy Smith 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(
On Thu, Jan 9, 2014 at 2:34 PM, Ben Finney 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
exactly what Roy already posted,
In article ,
Chris Angelico wrote:
> On Thu, Jan 9, 2014 at 1:25 PM, Roy Smith 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 datetim
Chris Angelico writes:
> On Thu, Jan 9, 2014 at 1:25 PM, Roy Smith 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
> > w
On Thu, Jan 9, 2014 at 1:25 PM, Roy Smith 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, it's a pain i
In article ,
Chris Angelico 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 to be
friends?" "Why not simply find a safe way to store nuc
On Thu, Jan 9, 2014 at 12:52 PM, Ethan Furman 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
On 01/08/2014 05:27 PM, Roy Smith wrote:
In article ,
Kevin Walzer 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.
[snip]
Naive datetimes are what eve
On Thu, Jan 9, 2014 at 12:27 PM, Roy Smith 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 directly from
In article ,
Kevin Walzer 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 unix timestamp. People need to go back
and fort
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
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'
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 wh
On 08/01/2014 15:39, Chris Angelico wrote:
On Thu, Jan 9, 2014 at 2:22 AM, Martijn Faassen 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 i
On Thu, Jan 9, 2014 at 2:22 AM, Martijn Faassen 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 a
> worthwhile consi
On Thu, Jan 9, 2014 at 2:06 AM, Grant Edwards wrote:
> On 2014-01-08, Chris Angelico 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 difference between those two
versions
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
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 o
On 2014-01-08, Chris Angelico 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 I thought
On 01/08/2014 01:46 PM, Chris Angelico wrote:
On Wed, Jan 8, 2014 at 11:36 PM, Martijn Faassen 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
On Thu, Jan 9, 2014 at 1: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 f
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 wrote:
>
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 wh
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 h
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
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.
R
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 Wed, Jan 8, 2014 at 11:36 PM, Martijn Faassen 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 projects to move anywher
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 h
On Wed, Jan 8, 2014 at 3:42 AM, Martijn Faassen 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 errors and
> be force
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 P
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 + py3bytes
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
On Tue, Jan 7, 2014 at 2:12 PM, Devin Jeanpierre 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 lower cost than a wh
On Mon, Jan 6, 2014 at 6:28 PM, Chris Angelico 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
> autoencod
On Tue, Jan 7, 2014 at 1:15 PM, Devin Jeanpierre 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 see what module you'
On Mon, Jan 6, 2014 at 6:00 PM, Chris Angelico wrote:
> On Tue, Jan 7, 2014 at 12:55 PM, Devin Jeanpierre
> 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
On Tue, Jan 7, 2014 at 12:55 PM, Devin Jeanpierre
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" __future__ feature:
On Mon, Jan 6, 2014 at 5:00 PM, Chris Angelico wrote:
> On Tue, Jan 7, 2014 at 11:27 AM, Devin Jeanpierre
> 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 ar
On Tue, Jan 7, 2014 at 11:27 AM, Devin Jeanpierre
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 -- but in the context
On Mon, Jan 6, 2014 at 4:19 PM, 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 la
On Tue, Jan 7, 2014 at 6:26 AM, Mark Lawrence 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 no
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
> 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
> firs
86 matches
Mail list logo
