On 08.09.15 19:59, Brett Cannon wrote:
The approaches to module deprecation I have seen are:
1. Nothing changes to the deprecation process; you deprecate a module
and remove it in one to two releases
2. Deprecate the module but with no plans for removal until Python 2.7
reaches its EOL (I have be
On 9/11/2015 8:40 PM, Alexander Belopolsky wrote:
The insanity I am dealing with now is specific to Python datetime which
wisely blocks any binary operation that involves naive and aware
datetimes, but allows comparisons and subtractions of datetimes with
different timezones. This is not an unu
MRAB writes:
> What would happen if it's decided to stay on DST and then, later on, to
> reintroduce DST?
>
> Or what would happen in the case of "British Double Summer Time" (go
> forward twice in the spring and backward twice in the autumn)?
>
> https://en.wikipedia.org/wiki/British_Summer_Time
On Fri, Sep 11, 2015 at 11:07 PM, MRAB wrote:
> What would happen if it's decided to stay on DST and then, later on, to
> reintroduce DST?
>
No problem as long as you don't move the clock back x minutes and then
decide that you did not move it back enough and move it again before x
minutes have
On Fri, Sep 11, 2015 at 11:03 PM, Tim Peters wrote:
> > then what exactly would a value landing near the
> > "fall back" transition have given for fold? fold=1 but EDT?
>
> As above, pytz is in its own world here. It doesn't need `fold`
> because it has its own hack for disambiguating local time
On 2015-09-12 02:23, Alexander Belopolsky wrote:
On Fri, Sep 11, 2015 at 8:56 PM, Random832 mailto:random...@fastmail.com>> wrote:
Alexander Belopolsky mailto:alexander.belopol...@gmail.com>> writes:
> There is no "earlier" or "later". There are "lesser" and "greater"
> which are al
[Random832 ]
> ...
>
> Also, can someone explain why this:
> >>> ET = pytz.timezone("America/New_York")
> >>> datetime.strftime(datetime.now(ET) + timedelta(days=90),
> ... "%Y%m%d %H%M%S %Z %z")
> returns '20151210 214526 EDT -0400'
pytz lives in its own world here, and only use
On Fri, Sep 11, 2015 at 10:22 PM, Guido van Rossum
wrote:
> I think we're getting into python-ideas territory here...
Well, a violation of transitivity of <= in the current CPython
implementation may be considered a bug by some. This makes this discussion
appropriate for python-dev. We could
On Fri, Sep 11, 2015 at 10:00 PM, Random832 wrote:
> And if EST and EDT are, against all rationality, distinct tzinfo values,
> then when exactly can fold ever actually be 1, and why is it needed?
>
No, fold is not needed in the case of fixed offset timezones. For an
obvious reason: there are n
On Fri, Sep 11, 2015 at 10:00 PM, Random832 wrote:
>
> The current datetime rules, such as they are, as far as I am aware,
> order all aware datetimes (except spring-forward) according to the UTC
> moment they map to.
No. See the library reference manual: "If both comparands are aware, and
have
On Fri, Sep 11, 2015 at 9:51 PM, Glenn Linderman
wrote:
> It wasn't intended to argue for not defining the operations, just intended
> to justify that it is partial ordering...
It is not even that. Note that even partial ordering still requires
transitivity of <=, but we don't have that in dat
I think we're getting into python-ideas territory here...
--Guido (on mobile)
___
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%4
Alexander Belopolsky writes:
> Yes, but it does that at the cost of introducing the second local
> "01:30" which is "later" than the first "01:40" while "obviously" (and
> according to the current datetime rules) "01:30" < "01:40".
The current datetime rules, such as they are, as far as I am awar
On 9/11/2015 6:39 PM, Alexander Belopolsky wrote:
On Fri, Sep 11, 2015 at 9:12 PM, Glenn Linderman
mailto:v+pyt...@g.nevcal.com>> wrote:
That's what the politicians gave us. These are datetime objects,
not mathematical numbers.
That's an argument for not defining mathematical operatio
On Fri, Sep 11, 2015 at 9:12 PM, Glenn Linderman
wrote:
> That's what the politicians gave us. These are datetime objects, not
> mathematical numbers.
That's an argument for not defining mathematical operations like <, > or -
on them, but you cannot deny the convenience of having those. Beside
On Fri, Sep 11, 2015 at 9:12 PM, Glenn Linderman
wrote:
[Alexander Belopolsky]
> But the decision to allow interzone t - s was made long time ago and it is
> a PEP 495 goal to change that.
>
> The last phrase, about it being a PEP 495 goal to change that, might be
> true, but if it changes it, th
On Fri, Sep 11, 2015 at 8:56 PM, Random832 wrote:
> Alexander Belopolsky writes:
> > There is no "earlier" or "later". There are "lesser" and "greater"
> > which are already defined for all pairs of aware datetimes. PEP 495
> > doubles the set of possible datetimes
>
> That depends on what you m
On 9/11/2015 5:40 PM, Alexander Belopolsky wrote:
The insanity I am dealing with now
...
But the decision to allow interzone t - s was made long time ago and
it is a PEP 495 goal to change that.
The first few paragraphs you wrote, which I elided, are a great
explanation of why things work i
Alexander Belopolsky writes:
> There is no "earlier" or "later". There are "lesser" and "greater"
> which are already defined for all pairs of aware datetimes. PEP 495
> doubles the set of possible datetimes
That depends on what you mean by "possible".
> and they don't fit in one
> straight line
On Fri, Sep 11, 2015 at 6:45 PM, Terry Reedy wrote:
>
>> I think we nailed the hard issues there. The next update will have a
>> restored hash invariant and == that satisfies all three axioms of
>> equivalency.
>>
>
> You are trying to sanely deal with politically mandated insanity.
> I think i
On 9/11/2015 2:36 PM, Alexander Belopolsky wrote:
On Tue, Sep 8, 2015 at 8:27 PM, Guido van Rossum mailto:gu...@python.org>> wrote:
Now if only PEP 495 could be as easy... :-)
I think we nailed the hard issues there. The next update will have a
restored hash invariant and == that satisf
> On Sep 11, 2015, at 1:57 PM, Brett Cannon wrote:
>
> In order to facilitate writing code that works in both Python 2 & 3
> simultaneously, any module that exists in both Python 3.5 and
> Python 2.7 will not be removed from the standard library until
> Python 2.7 is no longer supported as speci
On 9/11/2015 3:56 AM, Herbert Kruitbosch wrote:
I was wondering if there are considerations for including partial
function application syntactically. I very often find myself writing
statements as:
data_sorted = sort(data, key = lambda x: x[0])
where I would prefer
data_sorted = sort(data, key
> On Fri, 11 Sep 2015 at 10:41 Herbert Kruitbosch
> wrote:
> __
>> data_sorted = sort(data, key = #1[0])
>
> That syntax won't work because `#` is used to start a comment and
> there is no way to disambiguate that in the grammar.
Obviously :) The #-syntax is used by Mathematica, which is why I u
On Tue, Sep 8, 2015 at 8:27 PM, Guido van Rossum wrote:
> Now if only PEP 495 could be as easy... :-)
>
I think we nailed the hard issues there. The next update will have a
restored hash invariant and == that satisfies all three axioms of
equivalency. I am not making a better progress because
Tweaked wording that clearly state the mere existence in both Python 2.7
and 3.5 means the module won't be removed until Python 2.7 is EOL'ed:
In order to facilitate writing code that works in both Python 2 & 3
simultaneously, any module that exists in both Python 3.5 and
Python 2.7 will not be r
On Fri, 11 Sep 2015 at 10:41 Herbert Kruitbosch <
python-...@herbertkruitbosch.com> wrote:
> Dear developers,
>
> First of all, I'm a programmer for a data science company and I recently
> graduated.
>
> That being said, I have wondered why python does not have syntactical
> support (like syntax s
+1.
The language seems a bit ambiguous: "deprecated from 3.5 onward" -- what if
a module was deprecated in 3.3 or 3.4 but still present in 3.5? I assume
those are also included, but the language makes it possible to interpret
this as applying only to modules that were first marked as deprecated in
Since everyone seems happy with the proposal to keep deprecated modules in
Python 3 until Python 2.7 reaches EOL, here are my proposed changes to PEP
4. If no one objects I will commit the change and then update formatter and
imp to say they will be removed once Python 2.7 is no longer supported.
Dear developers,
First of all, I'm a programmer for a data science company and I recently
graduated.
That being said, I have wondered why python does not have syntactical
support (like syntax sugar) for partial function application. I think
partial function application is a powerful concept, but
ACTIVITY SUMMARY (2015-09-04 - 2015-09-11)
Python tracker at http://bugs.python.org/
To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.
Issues counts and deltas:
open5076 (+19)
closed 31753 (+49)
total 36829 (+68)
Open issues wit
31 matches
Mail list logo
