On Tue, Jul 28, 2015 at 10:25 AM, Łukasz Rekucki lreku...@gmail.com 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
On Tue, Jul 28, 2015 at 8:11 AM, Tim Peters tim.pet...@gmail.com wrote:
[Tim]
timedelta objects only store days, seconds, and microseconds,
[Lennart Regebro rege...@gmail.com]
Except that they don't actually store days. They store 24 hour
periods,
Not really. A timedelta is truly
On Tue, Jul 28, 2015 at 9:00 AM, Tim Peters tim.pet...@gmail.com 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 datetime objects.
Of course, I
On Tue, Jul 28, 2015 at 3:17 PM, Mark Lawrence breamore...@yahoo.co.uk 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
On Tue, Jul 28, 2015 at 1:55 PM, Mark Lawrence breamore...@yahoo.co.uk 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
On Tue, Jul 28, 2015 at 1:55 PM, Mark Lawrence breamore...@yahoo.co.uk 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
On Tue, Jul 28, 2015 at 10:26 PM, Tim Peters tim.pet...@gmail.com 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
On Tue, Jul 28, 2015 at 7:27 AM, Ethan Furman et...@stoneleaf.us 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 Mon, Jul 27, 2015 at 4:27 PM, Steve Dower steve.do...@microsoft.com 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
On Mon, Jul 27, 2015 at 5:12 PM, Paul Moore p.f.mo...@gmail.com 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
On Mon, Jul 27, 2015 at 4:13 PM, Steven D'Aprano st...@pearwood.info 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
On Mon, Jul 27, 2015 at 3:59 PM, R. David Murray rdmur...@bitdance.com 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
On Mon, Jul 27, 2015 at 4:45 PM, Nick Coghlan ncogh...@gmail.com wrote:
On 28 July 2015 at 00:27, Steve Dower steve.do...@microsoft.com 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
On Mon, Jul 27, 2015 at 6:15 PM, Nikolaus Rath nikol...@rath.org wrote:
On Jul 27 2015, Lennart Regebro rege...@gmail.com 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
alexander.belopol...@gmail.com 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.
On Mon, Jul 27, 2015 at 9:47 PM, Ethan Furman et...@stoneleaf.us 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 seconds to the time
On Tue, Jul 28, 2015 at 12:03 AM, Tim Peters tim.pet...@gmail.com 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
On Tue, Jul 28, 2015 at 12:11 AM, Ronald Oussoren
ronaldousso...@mac.com 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
On Tue, Jul 28, 2015 at 3:22 AM, Mark Lawrence breamore...@yahoo.co.uk 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
On Mon, Jul 27, 2015 at 12:15 AM, Paul Moore p.f.mo...@gmail.com 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
On Mon, Jul 27, 2015 at 4:04 AM, Tim Peters tim.pet...@gmail.com 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()
On Mon, Jul 27, 2015 at 9:09 AM, Tim Peters tim.pet...@gmail.com 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
On Mon, Jul 27, 2015 at 9:09 AM, Tim Peters tim.pet...@gmail.com 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
On Mon, Jul 27, 2015 at 10:47 AM, Paul Moore p.f.mo...@gmail.com 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
On Mon, Jul 27, 2015 at 11:05 AM, Paul Moore p.f.mo...@gmail.com 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
On Sun, Jul 26, 2015 at 8:05 AM, Tim Peters tim.pet...@gmail.com 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
On Sun, Jul 26, 2015 at 2:56 AM, Tim Peters tim.pet...@gmail.com 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
On Sat, Jul 25, 2015 at 7:12 AM, Tim Peters tim.pet...@gmail.com wrote:
[Lennart Regebro rege...@gmail.com]
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
On Thu, Jul 23, 2015 at 5:07 PM, Guido van Rossum gu...@python.org 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
On Wed, Apr 15, 2015 at 11:10 AM, Chris Angelico ros...@gmail.com 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
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,
On Wed, Apr 15, 2015 at 11:43 AM, Lennart Regebro rege...@gmail.com wrote:
On Wed, Apr 15, 2015 at 11:10 AM, Chris Angelico ros...@gmail.com 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
On Wed, Apr 15, 2015 at 12:40 PM, Isaac Schwabacher
ischwabac...@wisc.edu 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
On Wed, Apr 15, 2015 at 3:23 PM, Stuart Bishop stu...@stuartbishop.net 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
,
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 stu...@stuartbishop.net wrote:
On 14 April 2015 at 21:04, Lennart Regebro rege...@gmail.com wrote:
OK, so I realized
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
On Tue, Apr 14, 2015 at 4:52 PM, Alexander Belopolsky
alexander.belopol...@gmail.com 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
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:
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:
On Wed, Apr 8, 2015 at 9:57 PM, Isaac Schwabacher ischwabac...@wisc.edu 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 can be kept simpler
On Thu, Apr 9, 2015 at 1:31 AM, Alexander Belopolsky
alexander.belopol...@gmail.com 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
On Wed, Apr 8, 2015 at 7:37 PM, Carl Meyer c...@oddbird.net 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 of implementing
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 breamore...@yahoo.co.uk 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? :)
On Tue, Feb 18, 2014 at 8:35 AM, Greg Ewing greg.ew...@canterbury.ac.nz 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 Fri, Feb 14, 2014 at 9:04 AM, Chris Withers ch...@simplistix.co.uk 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
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 Sat, Jan 11, 2014 at 8:40 PM, Kristján Valur Jónsson
krist...@ccpgames.com 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
On Thu, Jan 9, 2014 at 8:16 AM, Ben Finney ben+pyt...@benfinney.id.au wrote:
Nick Coghlan ncogh...@gmail.com 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
On Thu, Jan 9, 2014 at 10:06 AM, Kristján Valur Jónsson
krist...@ccpgames.com 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
On Fri, Jan 10, 2014 at 2:03 AM, Joao S. O. Bueno jsbu...@python.org.br wrote:
On 9 January 2014 04:50, Lennart Regebro rege...@gmail.com 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 like
On Thu, Jan 9, 2014 at 1:07 AM, Ben Finney ben+pyt...@benfinney.id.au wrote:
Kristján Valur Jónsson krist...@ccpgames.com 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.
On Sun, Jan 5, 2014 at 5:20 AM, John Yeuk Hon Wong
gokoproj...@gmail.com 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:
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 st...@pearwood.info wrote:
On Tue, Dec 31, 2013 at 08:16:33AM +0100, Lennart
On Tue, Dec 31, 2013 at 6:31 AM, Dan Stromberg drsali...@gmail.com 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
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 dirk...@ochtman.nl wrote:
On Wed, Oct 2, 2013 at 2:17 PM, Lennart Regebro rege...@gmail.com 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
That could be a possibility as well.
On Wed, Oct 2, 2013 at 6:14 PM, Stuart Bishop stu...@stuartbishop.net wrote:
On Wed, Oct 2, 2013 at 9:42 PM, Lennart Regebro rege...@gmail.com wrote:
On Wed, Oct 2, 2013 at 3:05 PM, Dirkjan Ochtman dirk...@ochtman.nl wrote:
On Wed, Oct 2, 2013 at 2:17 PM
On Thu, Sep 19, 2013 at 10:54 PM, Ben Gift benhg...@gmail.com 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
On Thu, Jul 25, 2013 at 12:41 PM, Laurent Gautier lgaut...@gmail.com 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
On Thu, Jul 25, 2013 at 1:53 PM, Laurent Gautier lgaut...@gmail.com 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
On Wed, Jul 24, 2013 at 11:12 AM, Bohuslav Kabrda bkab...@redhat.com 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
On Wed, Jul 24, 2013 at 3:54 PM, Lennart Regebro rege...@gmail.com wrote:
On Wed, Jul 24, 2013 at 11:12 AM, Bohuslav Kabrda bkab...@redhat.com 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
On Wed, Jul 24, 2013 at 7:22 PM, Laurent Gautier lgaut...@gmail.com 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
On Mon, Jul 15, 2013 at 6:17 AM, Nick Coghlan ncogh...@gmail.com 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
On Fri, Jul 12, 2013 at 2:11 AM, Steve Dower steve.do...@microsoft.com 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
On Mon, May 20, 2013 at 1:51 AM, Gregory P. Smith g...@krypto.org wrote:
On May 19, 2013 4:31 PM, Benjamin Peterson benja...@python.org wrote:
2013/5/19 Gregory P. Smith g...@krypto.org:
Idea: I don't believe anybody has written a fixer for lib2to3 that
applies
fixers to doctests.
On Fri, Apr 26, 2013 at 1:09 AM, Ethan Furman et...@stoneleaf.us 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,
On Thu, Apr 25, 2013 at 7:43 AM, Antoine Pitrou solip...@pitrou.net wrote:
On Thu, 25 Apr 2013 04:19:36 +0200
Lennart Regebro rege...@gmail.com wrote:
On Thu, Apr 25, 2013 at 3:54 AM, Stephen J. Turnbull step...@xemacs.org
wrote:
RFC 4648 repeatedly refers to *characters*, without
On Thu, Apr 25, 2013 at 8:57 AM, Stephen J. Turnbull step...@xemacs.org 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
On Thu, Apr 25, 2013 at 11:25 AM, Antoine Pitrou solip...@pitrou.net 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,
On Thu, Apr 25, 2013 at 2:57 PM, Antoine Pitrou solip...@pitrou.net 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
On Thu, Apr 25, 2013 at 4:22 PM, MRAB pyt...@mrabarnett.plus.com 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.
On Thu, Apr 25, 2013 at 5:27 PM, Antoine Pitrou solip...@pitrou.net wrote:
Le Thu, 25 Apr 2013 15:34:45 +0200,
Lennart Regebro rege...@gmail.com 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 intended
On Thu, Apr 25, 2013 at 3:54 AM, Stephen J. Turnbull step...@xemacs.org 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
On Tue, Apr 23, 2013 at 4:04 AM, Steven D'Aprano st...@pearwood.info 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
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:
On Sun, Apr 7, 2013 at 7:11 AM, mar...@v.loewis.de 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 Sun, Apr 7, 2013 at 9:51 AM, mar...@v.loewis.de wrote:
Quoting Lennart Regebro rege...@gmail.com:
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.
I assume
On Sun, Apr 7, 2013 at 10:10 AM, Lennart Regebro rege...@gmail.com 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
On Tue, Mar 26, 2013 at 11:54 AM, Matthias Klose d...@ubuntu.com 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
On Tue, Mar 5, 2013 at 8:11 AM, Donald Stufft donald.stu...@gmail.com 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
On Tue, Mar 5, 2013 at 8:13 AM, Robert Collins
robe...@robertcollins.net wrote:
On 5 March 2013 20:02, Lennart Regebro rege...@gmail.com 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
On Tue, Mar 5, 2013 at 9:25 AM, Nick Coghlan ncogh...@gmail.com wrote:
On Tue, Mar 5, 2013 at 5:02 PM, Lennart Regebro rege...@gmail.com 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
On Tue, Mar 5, 2013 at 1:41 AM, Robert Collins
robe...@robertcollins.net 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
On Tue, Feb 12, 2013 at 10:03 PM, Maciej Fijalkowski fij...@gmail.com 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
On Wed, Feb 13, 2013 at 1:10 PM, Serhiy Storchaka storch...@gmail.com 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. :-)
On Wed, Feb 13, 2013 at 3:27 PM, Amaury Forgeot d'Arc
amaur...@gmail.com wrote:
2013/2/13 Lennart Regebro rege...@gmail.com
On Wed, Feb 13, 2013 at 1:10 PM, Serhiy Storchaka storch...@gmail.com
wrote:
I prefer x = '%s%s%s%s' % (a, b, c, d) when string's number is more
than 3
and some
On Wed, Feb 13, 2013 at 3:27 PM, Amaury Forgeot d'Arc
amaur...@gmail.com 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 7:06 PM, Maciej Fijalkowski fij...@gmail.com 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
On Wed, Feb 13, 2013 at 4:02 PM, Amaury Forgeot d'Arc
amaur...@gmail.com wrote:
2013/2/13 Lennart Regebro rege...@gmail.com
On Wed, Feb 13, 2013 at 3:27 PM, Amaury Forgeot d'Arc
amaur...@gmail.com wrote:
Yes, it's jitted.
Admittedly, I have no idea in which cases the JIT kicks in, and what
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 rege...@gmail.com
BDFL-Delegate: Barry Warsaw ba...@python.org
Status: Draft
Type: Standards Track
Content-Type: text/x
On Mon, Jan 28, 2013 at 11:26 AM, Antoine Pitrou solip...@pitrou.net 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
On Sat, Jan 26, 2013 at 10:38 AM, Nick Coghlan ncogh...@gmail.com 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
On Mon, Jan 28, 2013 at 11:17 PM, Steven D'Aprano st...@pearwood.info wrote:
On 28/01/13 23:52, Antoine Pitrou wrote:
Le Mon, 28 Jan 2013 22:31:29 +1000,
Nick Coghlanncogh...@gmail.com a écrit :
6. Under New collections
Why both lists and sets?
Because pytz did it. But yes, you are
to hg.python.org, for
example?
PEP: 431
Title: Time zone support improvements
Version: $Revision$
Last-Modified: $Date$
Author: Lennart Regebro rege...@gmail.com
BDFL-Delegate: Barry Warsaw ba...@python.org
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 11-Dec-2012
Post
On Fri, Dec 28, 2012 at 10:12 PM, Ronald Oussoren ronaldousso...@mac.comwrote:
On 28 Dec, 2012, at 21:23, Lennart Regebro rege...@gmail.com wrote:
Happy Holidays! Here is the update of PEP 431 with the changes that
emerged after the earlier discussion.
Why is the new timezone support
1 - 100 of 391 matches
Mail list logo
