Hi!
I wrote PEP-431 two years ago, and never got around to implement it.
This year I got some renewed motivation after Berker Peksağ made an
effort of implementing it.
I'm planning to work more on this during the PyCon sprints, and also
have a BoF session or similar during the conference.
Anyone
There is plenty of time to book an open space now. I would prefer sometime
Saturday. Any wishes?
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/p
On Wed, Apr 8, 2015 at 9:57 PM, Isaac Schwabacher wrote:
> On 15-04-08, Lennart Regebro wrote:
>> === Stdlib option 2: A datetime _is_dst flag ===
>>
>> By having a flag on the datetime instance that says "this is in DST or not"
>> the timezone implementation
On Thu, Apr 9, 2015 at 1:31 AM, Alexander Belopolsky
wrote:
> Storing isdst in the datetime object would allow utcoffset(dt) to
> distinguish between 1:30AM before clock change and 1:30AM after. Where do
> you propose to store the offset? If you store it in dt, why would you need
> the tzinfo?
On Wed, Apr 8, 2015 at 7:37 PM, Carl Meyer wrote:
> Hi Lennart,
>
> On 04/08/2015 09:18 AM, Lennart Regebro wrote:
>> I wrote PEP-431 two years ago, and never got around to implement it.
>> This year I got some renewed motivation after Berker Peksağ made an
>> effort
I've booked an open space for 3pm in 512CG. Be there or be to naive!
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-arch
The Open Space was good, and the conclusion was that solution #2
indeed seems to be the right one. We also concluded that likely the
datetime() constructor itself needs to grow an is_dst flag. There was
no further insight into whether having an offset or a is_dst flag as
an attribute, I think that
OK, so I realized another thing today, and that is that arithmetic
doesn't necessarily round trip.
For example, 2002-10-27 01:00 US/Eastern comes both in DST and STD.
But 2002-10-27 01:00 US/Eastern STD minus two days is 2002-10-25 01:00
US/Eastern DST
However, 2002-10-25 01:00 US/Eastern DST plu
On Tue, Apr 14, 2015 at 4:52 PM, Alexander Belopolsky
wrote:
> For those who were not at the conference, can someone summarize the
> post-PyCon status of this PEP?
>
> Is Barry still the "BDFL-Delegate"? Is there an updated draft? Should this
> discussion move to python-ideas?
There is no statu
,
2, 0)
(Note the hour change)
I was thinking in calendrial arithmetic, which the datetime module
doesn't need to care about.
On Wed, Apr 15, 2015 at 12:59 AM, Stuart Bishop wrote:
> On 14 April 2015 at 21:04, Lennart Regebro wrote:
>> OK, so I realized another thing today, an
OK, so I just had a realization.
Because we want some internal flag to tell if the datetime is in DST
or not, the datetime pickle format will change. And the datetime
pickle format changing is the biggest reason I had against changing
the internal representation to UTC.
So because of this, perhap
On Wed, Apr 15, 2015 at 11:10 AM, Chris Angelico wrote:
> Bikeshed: Would arithmetic be based on UTC time or Unix time? It'd be
> more logical to describe it as "adding six hours means adding six
> hours to the UTC time", but it'd look extremely odd when there's a
> leap second.
It would ignore l
On Wed, Apr 15, 2015 at 11:43 AM, Lennart Regebro wrote:
> On Wed, Apr 15, 2015 at 11:10 AM, Chris Angelico wrote:
>> Bikeshed: Would arithmetic be based on UTC time or Unix time? It'd be
>> more logical to describe it as "adding six hours means adding six
>> h
On Wed, Apr 15, 2015 at 12:40 PM, Isaac Schwabacher
wrote:
> I am on the fence about EPOCH + offset as an internal representation. On the
> one hand, it is conceptually cleaner than the horrible byte-packing that
> exists today, but on the other hand, it has implications for future
> implementa
On Wed, Apr 15, 2015 at 3:23 PM, Stuart Bishop wrote:
> Huh. I didn't think you would need to change any arithmetic
Not really, the problem is in keeping the date normalized after each
call, and doing so the right way.
> Arithmetic
> remains 'add the timedelta to the naive datetime, and then pun
On Thu, Jul 23, 2015 at 5:07 PM, Guido van Rossum wrote:
> Sorry for reviving this thread, but I was cornered at EuroPython with a
> question about the status of this PEP. It seems the proposal ran out of
> steam and has now missed the Python 3.5 train. What happened? Is the problem
> unsolvable?
And I would want to remind everyone again that this is not a question
of the problem being impossible. It's just really complex to get right
in all cases, and that always having the UTC timestamp around gets rid
of most of that complexity.
On Sat, Jul 25, 2015 at 3:39 AM, Tim Peters wrote:
> [ISA
On Sat, Jul 25, 2015 at 7:12 AM, Tim Peters wrote:
> [Lennart Regebro ]
>> And I would want to remind everyone again that this is not a question
>> of the problem being impossible. It's just really complex to get right
>> in all cases, and that always having the UTC
On Sun, Jul 26, 2015 at 2:56 AM, Tim Peters wrote:
> However, the _body_ of the PEP said nothing whatsoever about altering
> arithmetic. The body of the PEP sounds like it's mainly just
> proposing to fold the pytz package into the core. Perhaps doing
> _just_ that much would get this project un
On Sun, Jul 26, 2015 at 8:05 AM, Tim Peters wrote:
> The Python docs also are quite clear about that all arithmetic within
> a single timezone is "naive". That was intentional. The _intended_
> way to do "aware" arithmetic was always to convert to UTC, do the
> arithmetic, then convert back.
We
On Mon, Jul 27, 2015 at 12:15 AM, Paul Moore wrote:
> I think the current naive semantics are useful and should not be
> discarded lightly. At an absolute minimum, there should be a clear,
> documented way to get the current semantics under any changed
> implementation.
>
> As an example, consider
On Mon, Jul 27, 2015 at 4:04 AM, Tim Peters wrote:
> Realistically, default arithmetic behavior can't change in Python 3
> (let alone Python 2).
Then we can't implement timezones in a reasonable way with the current
API, but have to have something like pytz's normalize() function or
similar.
I'm
On Mon, Jul 27, 2015 at 9:09 AM, Tim Peters wrote:
> It's an instance of single-timezone datetime arithmetic, of the
> datetime + timedelta form.
No, because in that case it would always move 24 hours, and it
doesn't. It sometimes moves 23 hours or 25 hours, when crossing a DST
border. That is a
On Mon, Jul 27, 2015 at 9:09 AM, Tim Peters wrote:
> But for a dozen years it's sufficed to do what Paul did.
No, it never did "suffice". It's just that people have been doing
various kinds of workarounds to compensate for these design flaws. I
guess they need to continue to do that for the time
On Mon, Jul 27, 2015 at 10:47 AM, Paul Moore wrote:
> I'm confused by your position. If it's 7am on the clock behind me,
> right now, then how (under the model proposed by the PEP) do I find
> the datetime value where it will next be 7am on the clock?
PEP-431 does not propose to implement calenda
On Mon, Jul 27, 2015 at 11:05 AM, Paul Moore wrote:
> Am I right to think that because you say "implement calendar
> operations" this is not, as far as you are aware, something that
> already exists in the stdlib (outside of datetime)? I'm certainly not
> aware of an alternative way of doing it.
On Mon, Jul 27, 2015 at 3:59 PM, R. David Murray wrote:
> I'm not sure if the opinion of a relatively inexperienced timezone user
> (whose head hurts when thinking about these things) is relevant, but in
> case it is:
>
> My brief experience with pytz is that it gets this all "wrong". (Wrong
> is
On Mon, Jul 27, 2015 at 4:13 PM, Steven D'Aprano wrote:
> To me, Paul's example is a datetime operation: you start with a datetime
> (7am today), perform arithmetic on it by adding a period of time (one
> day), and get a datetime as the result (7am tomorrow).
Well, OK, let's propose these wording
On Mon, Jul 27, 2015 at 4:27 PM, Steve Dower wrote:
> Am I the only one feeling like this entire thread should be moved to
> python-ideas at this point?
Well, there isn't any idea to discuss. :-) It's just an explanation of
the problem space. Perhaps it should be moved somewhere else though.
On Mon, Jul 27, 2015 at 4:45 PM, Nick Coghlan wrote:
> On 28 July 2015 at 00:27, Steve Dower wrote:
>> Am I the only one feeling like this entire thread should be moved to
>> python-ideas at this point?
>
> Since this is an area where the discussion of implementation details
> and the discussion
On Mon, Jul 27, 2015 at 5:12 PM, Paul Moore wrote:
> Does thinking of the problem in terms of timedeltas not containing
> enough information to make a_time + a_timedelta a well-defined
> operation if a_time uses a non-fixed-offset timezone, make it any
> easier to find a way forward?
Well, I thin
On Mon, Jul 27, 2015 at 6:15 PM, Nikolaus Rath wrote:
> On Jul 27 2015, Lennart Regebro wrote:
>> That you add one hour to it, and the datetime moves forward one hour
>> in actual time? That's doable, but during certain circumstance this
>> may mean that you go from
On Mon, Jul 27, 2015 at 6:42 PM, Alexander Belopolsky
wrote:
> I think this describes what was originally your *second*, not *first*
> option.
Yes, you are absolutely correct, I didn't read my own description of
the options carefully enough.
___
Python-
On Mon, Jul 27, 2015 at 9:47 PM, Ethan Furman wrote:
> On 07/27/2015 07:46 AM, Lennart Regebro wrote:
>> Well, OK, let's propose these wordings: It looks like a date
>> operation, ie, add one to the date, but in reality it's a time
>> operation, ie add 86400 se
On Tue, Jul 28, 2015 at 12:03 AM, Tim Peters wrote:
> timedelta objects only store days, seconds, and microseconds,
Except that they don't actually store days. They store 24 hour
periods, which, because of timezones changing, is not the same thing.
This is also clearly intended, for example timed
On Tue, Jul 28, 2015 at 12:11 AM, Ronald Oussoren
wrote:
> I totally agree with that, having worked on applications that had to deal
> with time a lot and including some where the end of a day was at 4am the
> following day. That app never had to deal with DST because not only are the
> transi
On Tue, Jul 28, 2015 at 3:22 AM, Mark Lawrence wrote:
> To me a day is precisely 24 hours, no more, no less.
OK.
> In my mission critical code, which I use to predict my cashflow, I use code
> such as.
>
> timedelta(days=14)
>
> Is somebody now going to tell me that this isn't actually two weeks
On Tue, Jul 28, 2015 at 7:27 AM, Ethan Furman wrote:
> Lennart, are you saying you would leave naive objects alone, and "fix" the
> tz-aware objects only?
Naive objects are not broken, so they can't be fixed. Which I guess
means "yes". :-)
//Lennart
__
On Tue, Jul 28, 2015 at 8:11 AM, Tim Peters wrote:
> [Tim]
>>> timedelta objects only store days, seconds, and microseconds,
>
> [Lennart Regebro ]
>> Except that they don't actually store days. They store 24 hour
>> periods,
>
> Not really. A timedelta i
On Tue, Jul 28, 2015 at 9:00 AM, Tim Peters wrote:
> [Lennart Regebro]
>> If you don't have to deal with DST, then you don't have to have
>> tzinfo's in your date objects.
>
> There are no tzinfos on date objects. I assume Ronald is talking
> about datetim
On Tue, Jul 28, 2015 at 10:25 AM, Łukasz Rekucki wrote:
> Maybe instead of trying to decide who is "wrong" and which approach is
> "broken", Python just needs a more clear separation between timezone
> aware objects and "naive" ones?
Well, the separation is pretty clear already. Tim wants to have
On Tue, Jul 28, 2015 at 1:55 PM, Mark Lawrence wrote:
> One week == 7 days == 7 * 24 hours
> Two weeks = 2 * (one week)
Right, and that of course is not true in actual reality. I know you
are not interested in DST, but with a timezone that has DST, two times
a year, the above statement is wrong.
On Tue, Jul 28, 2015 at 1:55 PM, Mark Lawrence wrote:
> Correct. What I would like to know is how many people are in my position,
> how many people are in the situation of needing every possible combination
> of dates, times, daylight saving, local time zone rules and anything else
> you can thin
On Tue, Jul 28, 2015 at 3:17 PM, Mark Lawrence wrote:
> Tim asked for my definition of two weeks so I've given it. With respect to
> that in reality this is true, for me, with my application, making my
> statement above correct. For my application we could go from GMT to BST and
> back on succes
On Tue, Jul 28, 2015 at 10:26 PM, Tim Peters wrote:
>> I have yet to see a use case for that.
>
> Of course you have. When you address them, you usually dismiss them
> as "calendar operations" (IIRC).
Those are not usecases for this broken behaviour.
I agree there is a usecase for where you wan
On Tue, Dec 31, 2013 at 6:31 AM, Dan Stromberg wrote:
> So far the results are looking good for 3.x.
Python-dev probably is a bit special.
//Lennart
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
U
Yeah, but I'd still expect more people on Python-dev to at least have
used Python 3 and possibly be maintainers of libraries that have been
ported to Python 3 etc.
On Tue, Dec 31, 2013 at 11:04 AM, Steven D'Aprano wrote:
> On Tue, Dec 31, 2013 at 08:16:33AM +0100, Lennart Regebro
On Sun, Jan 5, 2014 at 5:20 AM, John Yeuk Hon Wong
wrote:
> I think it helps Luca and many others (including myself) if there is a
> reference of the difference between 2.7 and Python 3.3+.
Not specifically for 2.7 and 3.3, no. This is a fairly complete list:
http://python3porting.com/difference
On Thu, Jan 9, 2014 at 1:07 AM, Ben Finney wrote:
> Kristján Valur Jónsson writes:
>
>> Believe it or not, sometimes you really don't care about encodings.
>> Sometimes you just want to parse text files.
>
> Files don't contain text, they contain bytes. Bytes only become text
> when filtered thro
On Thu, Jan 9, 2014 at 8:16 AM, Ben Finney wrote:
> Nick Coghlan writes:
>> Set the mode to "rb", process it as binary. Done.
>
> Which entails abandoning the stated goal of “just want to parse text
> files” :-)
Only if your definition of "text files" means it's unicode.
On Thu, Jan 9, 2014 at 10:06 AM, Kristján Valur Jónsson
wrote:
> Do I speak Chinese to my grocer because china is a growing force in the
> world? Or start every discussion with my children with a negotiation on what
> language to use?
No, because your environment have a default language. And P
On Fri, Jan 10, 2014 at 2:03 AM, Joao S. O. Bueno wrote:
> On 9 January 2014 04:50, Lennart Regebro wrote:
>> To be honest, you can define text as "A stream of bytes that are split
>> up in lines separated by a linefeed", and do some basic text
>> processing li
On Sat, Jan 11, 2014 at 8:40 PM, Kristján Valur Jónsson
wrote:
> Hi there.
> How about a compromise?
> Personally, I think adding the full complement of integer/float formatting to
> bytes is a bit over the top.
> How about just supporting two format specifiers?
> %b : interpolate a bytes object.
On Fri, Feb 14, 2014 at 9:04 AM, Chris Withers wrote:
> Hi All,
>
> Sending this to python-dev as I'm wondering if this was considered when the
> choice to have objects of different types raise a TypeError when ordered...
>
> So, the concrete I case I have is implementing stable ordering for the
>
What I think is the biggest nitpick here is that you can't make a NULL
object so that
NULL is None
evaluates as True. If you could, you could then easily make this NULL
object evaluate as less than everything except itself and None, and
use that consistently. But since this NULL is not None,
On Tue, Feb 18, 2014 at 8:35 AM, Greg Ewing wrote:
> If you don't want to touch comparison in general,
> how about an option to sort()?
>
> results = sorted(invoices, key=attrgetter('duedate'), none='first')
I think this is a much better option.
//Lennart
__
On Tue, Feb 18, 2014 at 5:10 PM, Mark Lawrence wrote:
> Sorry if this has already been suggested, but why not introduce a new
> singleton to make the database people happier if not happy? To avoid
> confusion call it dbnull? A reasonable compromise or complete cobblers? :)
I think this is possi
On Tue, Mar 5, 2013 at 1:41 AM, Robert Collins
wrote:
> So that is interesting, but its not sufficient to meet the automation
> need Barry is calling out, unless all test suites can be run by
> 'python -m unittest discover' with no additional parameters [and a
> pretty large subset cannot].
But c
On Tue, Mar 5, 2013 at 8:11 AM, Donald Stufft wrote:
> I don't care much what that mechanism is, but I think the easiest way
> to get there is to tell people to extend distutils with a test command
> (or use Distribute) and perhaps add such a command in 3.4 that will do
> the unittest discover thi
On Tue, Mar 5, 2013 at 8:13 AM, Robert Collins
wrote:
> On 5 March 2013 20:02, Lennart Regebro wrote:
>> What's needed here is not a tool that can run all unittests in
>> existence, but an official way for automated tools to run tests, with
>> the ability for any test
On Tue, Mar 5, 2013 at 9:25 AM, Nick Coghlan wrote:
> On Tue, Mar 5, 2013 at 5:02 PM, Lennart Regebro wrote:
>> I don't care much what that mechanism is, but I think the easiest way
>> to get there is to tell people to extend distutils with a test command
>> (or use D
On Tue, Mar 26, 2013 at 11:54 AM, Matthias Klose wrote:
> Am 25.03.2013 01:30, schrieb Benjamin Peterson:
>> 2.7.4 will be the latest maintenance release in the Python 2.7 series.
>
> I hope it's not (and in the IDLE thread you say so otherwise too).
It most certainly will be the latest once it's
On Sun, Apr 7, 2013 at 7:11 AM, wrote:
> Wrt. to the 3.x migration rate: I think this is a self-fulfilling
> prophecy. Migration rate will certainly increase once we announce
> an end of 2.7, and then again when the end is actually reached.
Well... People are in general *stuck* on Python 2. They
On Sun, Apr 7, 2013 at 9:51 AM, wrote:
> Quoting Lennart Regebro :
>> Well... People are in general *stuck* on Python 2. They are not
>> staying because they want to. So I'm not so sure migration rate will
>> increase because an end is announced or reached.
>
&g
On Sun, Apr 7, 2013 at 10:10 AM, Lennart Regebro wrote:
> That's the hangup IMO. Ending Python 2.7 will make no difference there
> either good or bad, I think. We need to find other ways of improving
> adoption.
And to be clear: I am therefore not arguing *not* to end it. I just
do
OK, so I finally got tie to read the PEP. I like it, I really have
missed Enums, this is awesome.
That's all folks!
//Lennart
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.
On Tue, Apr 23, 2013 at 4:04 AM, Steven D'Aprano wrote:
> As others have pointed out in the past, repeatedly, the codec system is
> completely general and can transform bytes->bytes and text->text just as
> easily as bytes<->text.
Yes, but the encode()/decode() methods are not, and the fact that
On Thu, Apr 25, 2013 at 3:54 AM, Stephen J. Turnbull wrote:
> RFC 4648 repeatedly refers to *characters*, without specifying an
> encoding for them. In fact, if you copy accurately, you can write
> BASE64 on a napkin and that napkin will accurate transmit the data
> (assuming it doesn't run into
On Thu, Apr 25, 2013 at 7:43 AM, Antoine Pitrou wrote:
> On Thu, 25 Apr 2013 04:19:36 +0200
> Lennart Regebro wrote:
>> On Thu, Apr 25, 2013 at 3:54 AM, Stephen J. Turnbull
>> wrote:
>> > RFC 4648 repeatedly refers to *characters*, without specifyin
On Thu, Apr 25, 2013 at 8:57 AM, Stephen J. Turnbull wrote:
> I think that would be an unfortunate result. These operations on
> streams are theoretically nicely composable. It would be nice if
> practice reflected that by having a uniform API for all of these
> operations (charset translation,
On Thu, Apr 25, 2013 at 11:25 AM, Antoine Pitrou wrote:
> Le Thu, 25 Apr 2013 08:38:12 +0200,
>> Yes it is. Base64 takes 8-bit bytes and transforms them into another
>> 8-bit stream that can be safely transmitted over various channels that
>> would mangle an unencoded 8-bit stream, such as email e
On Thu, Apr 25, 2013 at 2:57 PM, Antoine Pitrou wrote:
> I can think of many usecases where I want to *embed* base64-encoded
> data in a larger text *before* encoding that text and transmitting
> it over a 8-bit channel.
That still doesn't mean that this should be the default behavior. Just
becau
On Thu, Apr 25, 2013 at 4:22 PM, MRAB wrote:
> The JSON specification says that it's text. Its string literals can
> contain Unicode codepoints. It needs to be encoded to bytes for
> transmission and storage, but JSON itself is not a bytestring format.
OK, fair enough.
> base64 is a way of encod
On Thu, Apr 25, 2013 at 5:27 PM, Antoine Pitrou wrote:
> Le Thu, 25 Apr 2013 15:34:45 +0200,
> Lennart Regebro a écrit :
>>
>> I don't agree that there is a significant difference between those
>> wordings in this context. The end result is the same: Things inte
On Fri, Apr 26, 2013 at 1:09 AM, Ethan Furman wrote:
> We just fixed NoneType() to return None instead of raising an exception.
>
> Another use-case for calling NoneType is working with ORMs:
>
> result = []
> for field in row:
> type = get_type(field) # returns int, bool, str, NoneType,
On Mon, May 20, 2013 at 1:51 AM, Gregory P. Smith wrote:
>
> On May 19, 2013 4:31 PM, "Benjamin Peterson" wrote:
>>
>> 2013/5/19 Gregory P. Smith :
>> > Idea: I don't believe anybody has written a fixer for lib2to3 that
>> > applies
>> > fixers to doctests. That'd be an interesting project for s
On Fri, Jul 12, 2013 at 2:11 AM, Steve Dower wrote:
> +1. And maybe amend PEP 11 to specify "whose extended support phase does not
> expire within 6 months of release"? (I picked 6 for no particular reason.)
Why have the specification in PEP 11 if we feel we can change the
rules arbitrarily when
On Mon, Jul 15, 2013 at 6:17 AM, Nick Coghlan wrote:
> =
> Private interfaces
>
> Unless explicitly documented otherwise, a leading underscore on any
> name indicates that it is an internal implementation detail and any
> backwards compatibility guarantees do not apply. It is stron
On Wed, Jul 24, 2013 at 11:12 AM, Bohuslav Kabrda wrote:
> - Should we point /usr/bin/python to Python 3 when we make the move?
No.
> - What should user get after using "yum install python"?
Will a base install include Python 3? If it does, I think yum install
python should mean python3, and he
On Wed, Jul 24, 2013 at 3:54 PM, Lennart Regebro wrote:
> On Wed, Jul 24, 2013 at 11:12 AM, Bohuslav Kabrda wrote:
>> - Should we point /usr/bin/python to Python 3 when we make the move?
>
> No.
To be more explicit. I think it's perfectly fine to not provide a
/usr/bin/
On Wed, Jul 24, 2013 at 7:22 PM, Laurent Gautier wrote:
> The wrapper in /usr/bin/python:
> - could use what is in 2to3. I think that most of the cases are solved
> there.
Only the most trivial cases are solved completely by 2to3, and the
error messages you would get would be hard to understand,
On Thu, Jul 25, 2013 at 12:41 PM, Laurent Gautier wrote:
> - a user is running a python script (he expects to be working), and is using
> the default /usr/bin/python (formerly Python 2, now Python 3). If the
> program fails because of obvious Python 2-only idioms, reporting this rather
> that the
On Thu, Jul 25, 2013 at 1:53 PM, Laurent Gautier wrote:
> My meaning was the use of 2to3's machinery (and fire a message if a
> translation occurs) not 2to3 itself, obviously.
I don't understand what you mean is the difference.
//Lennart
___
Python-Dev
On Tue, Aug 6, 2013 at 9:26 PM, Antoine Pitrou wrote:
> What didn't produce an alarm during Robin's work is that GSoC work is
> done in private.
Why is it done in private?
//Lennart
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.o
On Thu, Sep 19, 2013 at 10:54 PM, Ben Gift wrote:
> I think the lambda keyword is difficult to understand for many people. It
> would be more pythonic to use an empty def call instead.
I agree, but that ship has sailed, at least until the time when Python
2 is dead. I don't want these kinds of sy
Hi all!
If you wonder about the lack of progress reports on pep-431, this is
because of a lack of progress. I simply haven't had any time to work
on this. I considered make a kickstarter so I could take time off from
working, but to be honest, even with that, I still have no time to
realistically
On Wed, Oct 2, 2013 at 3:05 PM, Dirkjan Ochtman wrote:
> On Wed, Oct 2, 2013 at 2:17 PM, Lennart Regebro wrote:
>> If you wonder about the lack of progress reports on pep-431, this is
>> because of a lack of progress. I simply haven't had any time to work
>> on
That could be a possibility as well.
On Wed, Oct 2, 2013 at 6:14 PM, Stuart Bishop wrote:
> On Wed, Oct 2, 2013 at 9:42 PM, Lennart Regebro wrote:
>> On Wed, Oct 2, 2013 at 3:05 PM, Dirkjan Ochtman wrote:
>>> On Wed, Oct 2, 2013 at 2:17 PM, Lennart Regebro wrote:
>>&g
I discovered some remaining cmp() in 3.0.1, 38 minutes after Benjamin
fixed them. :) Unfortunately, that means porting setuptools to 3.0.1
will be a bit difficult. So my question is: Will there be a 3.0.2 with
those fixes, or should I add workaround code for 3.0.1?
--
Lennart Regebro: Pythonista
#x27;t really looked into if there is any other
possibilities yet, I'm concentrating to make it run for 3.1 trunk
first.
--
Lennart Regebro: Pythonista, Barista, Notsotrista.
http://regebro.wordpress.com/
+33 661 58 14 64
___
Python-Dev mailing list
Pyt
e expected to have a graphical installer, so a
gui-version of zc.buildout then? (I'm only half serious).
--
Lennart Regebro: Pythonista, Barista, Notsotrista.
http://regebro.wordpress.com/
+33 661 58 14 64
___
Python-Dev mailing list
Python-Dev@python
On Tue, Apr 7, 2009 at 15:05, KDr2 wrote:
> I need an CPyAN.
On the lighter side of things: That would be pronounced "spy-ann",
which mean "the vomit" is swedish. Do you still want it? :-D
--
Lennart Regebro: Pythonista, Barista, Notsotrista.
http://regebro.wordpres
f Match 2013 again... Code that
doesn't support ALL the weird-ass variants is really not worth putting
into the standard library, IMO.
I'd recommend you to look at the dateutil.rrule code, maybe there is
something you can use there. Perhaps there is something there that can
be used straig
years still. And
until then we kinda need different shebang lines. Not much you can do
to get around that.
--
Lennart Regebro: Python, Zope, Plone, Grok
http://regebro.wordpress.com/
+33 661 58 14 64
___
Python-Dev mailing list
Python-Dev@python.or
er to find another name.
'utf8-binary-replace'?
Is it only usable with utf8 as an encoding?
--
Lennart Regebro: Python, Zope, Plone, Grok
http://regebro.wordpress.com/
+33 661 58 14 64
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.p
ith the other
examples except Zope 3, which is a completely different thing, so it
may very well be that Python did it way better. But still, it's not
pulled off yet.
--
Lennart Regebro: Python, Zope, Plone, Grok
http://regebro.wordpress.com/
+33 661 58 14 64
__
ndard library is that the module
pretty much is dead, and that you don't need new releases or new
features. This isn't true for any part of a refactored setuptools. We
will need to distribute most of this separately for a while first.
That means that distutils.anything doesn't wor
le doesn't have to run on 2.6 or 2.5.
So 2.7 support will for the most part be a case not of supporting
Python versions, but Python *users*.
Which is a good thing.
--
Lennart Regebro: Python, Zope, Plone, Grok
http://regebro.wordpress.com/
+33 661 58 14 64
___
ed.
>
> That was precisely my point.
Then I don't understand what you are saying. Obviously we shouldn't
backport to the 2.6 branch, it's in bugfix mode. This is about 2.7. I
don't see what 2.6 has to do with it.
> There are development practices which mitigate the
&g
2009/10/29 Nick Coghlan :
> Lennart Regebro wrote:
>> 2009/10/28 Antoine Pitrou :
>>> pobox.com> writes:
>>>> >> So 2.7 support will for the most part be a case not of supporting
>>>> >> Python versions, but Python *users*.
>>
1 - 100 of 399 matches
Mail list logo
