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, 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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: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 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 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 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 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 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 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 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 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 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 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
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 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?
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 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 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 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
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
,
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
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
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
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
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
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 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 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 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
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
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, 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
__
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 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
>
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, 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 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 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 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 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
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 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
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
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
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 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
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, 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 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 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 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 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 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 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, 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, 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 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 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 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 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 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 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 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 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
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 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
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 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 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 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 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 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 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 Wed, Feb 13, 2013 at 4:02 PM, Amaury Forgeot d'Arc
wrote:
> 2013/2/13 Lennart Regebro
>>
>> On Wed, Feb 13, 2013 at 3:27 PM, Amaury Forgeot d'Arc
>> wrote:
>> > Yes, it's jitted.
>>
>> Admittedly, I have no idea in which cases the JIT
On Wed, Feb 13, 2013 at 7:06 PM, Maciej Fijalkowski wrote:
> I actually wonder.
>
> There seems to be the consensus to avoid += (to some extent). Can
> someone commit the change to urrllib then? I'm talking about reverting
> http://bugs.python.org/issue1285086 specifically
That's unquoting of URL
On Wed, Feb 13, 2013 at 3:27 PM, Amaury Forgeot d'Arc
wrote:
> Yes, it's jitted.
Admittedly, I have no idea in which cases the JIT kicks in, and what I
should do to make that happen to make sure I have the best possible
real-life test cases.
//Lennart
On Wed, Feb 13, 2013 at 3:27 PM, Amaury Forgeot d'Arc
wrote:
>
> 2013/2/13 Lennart Regebro
>>
>> On Wed, Feb 13, 2013 at 1:10 PM, Serhiy Storchaka
>> wrote:
>> > I prefer "x = '%s%s%s%s' % (a, b, c, d)" when string's numbe
On Wed, Feb 13, 2013 at 1:10 PM, Serhiy Storchaka wrote:
> I prefer "x = '%s%s%s%s' % (a, b, c, d)" when string's number is more than 3
> and some of them are literal strings.
This has the benefit of being slow both on CPython and PyPy. Although
using .format() is even slower. :-)
//Lennart
On Tue, Feb 12, 2013 at 10:03 PM, Maciej Fijalkowski wrote:
> Hi
>
> We recently encountered a performance issue in stdlib for pypy. It
> turned out that someone commited a performance "fix" that uses += for
> strings instead of "".join() that was there before.
Can someone show the actual diff? O
> Something is needed - a patch for PyPy or for the documentation I guess.
Not arguing that it wouldn't be good, but I disagree that it is needed.
This is only an issue when you, as in your proof, have a loop that
does concatenation. This is usually when looping over a list of
strings that should
Coghlan for finding a whole bunch of minor mistakes.
//Lennart
PEP: 431
Title: Time zone support improvements
Version: $Revision$
Last-Modified: $Date$
Author: Lennart Regebro
BDFL-Delegate: Barry Warsaw
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 11-Dec-2012
Post
On Mon, Jan 28, 2013 at 11:17 PM, Steven D'Aprano wrote:
> On 28/01/13 23:52, Antoine Pitrou wrote:
>>
>> Le Mon, 28 Jan 2013 22:31:29 +1000,
>> Nick Coghlan a écrit :
>>>
>>>
> 6. Under "New collections"
>
> Why both lists and sets?
Because pytz did it. But yes, you ar
On Sat, Jan 26, 2013 at 10:38 AM, Nick Coghlan wrote:
> 2. Under "New class DstTzInfo"
>
> This will be a subclass of "tzinfo" rather than "zoneinfo" (which is
> not a class). Given that this is a *concrete* subclass, you may want
> to consider the name "DstTimezone", which would be slightly more
On Mon, Jan 28, 2013 at 11:26 AM, Antoine Pitrou wrote:
> Will non-ambiguous shorthands such as "Warsaw" and "GMT" be accepted?
pytz accepts GMT, so that will work. Otherwise no.
> NonExistentTimeError can also be raised for is_dst=True and
> is_dst=False, no? Or am I misunderstanding the semant
Last-Modified: $Date$
Author: Lennart Regebro
BDFL-Delegate: Barry Warsaw
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 11-Dec-2012
Post-History: 11-Dec-2012, 28-Dec-2012
Abstract
This PEP proposes the implementation of concrete time zone support in the
P
1 - 100 of 399 matches
Mail list logo
