I'm not entirely sure I understand the full set of reasoning for this - I
couldn't really tell what the problem with OrderedDict is from the link Stefan
provided. It seems to me like a kind of huge change for the language to move
from arbitrary-ordered to guaranteed-ordered dict. The problem I s
7;foo', 'c': o{'this': b'123'}
Then there is no backwards incompatibility problem and users can express
whether order does or does not matter to them when initializing a container.
On 11/05/2017 01:39 PM, Stefan Krah wrote:
> On Sun, Nov 05, 2017 at 01:14:54PM -05
Is there a major objection to just adding in explicit syntax for
order-preserving dictionaries? To some extent that seems like a reasonable
compromise position in an "explicit is better than implicit" sense. A whole lot
of code is out there that doesn't require or expect order-preserving
dictio
If dictionary order is *not* guaranteed in the spec and the dictionary order
isn't randomized (which I think everyone agrees is a bit messed up), it would
probably be useful if you could enable "random order mode" in CPython, so you
can stress-test that your code isn't making any assumptions abo
f code that assumes that `assert` statements will always
throw `AssertionError`, but that's not guaranteed, and some people run their
test suites with -O just to check that they aren't making that assumption.
On 11/07/2017 04:15 PM, Paul Moore wrote:
> On 7 November 2017 at 20:35, P
I think the latest version can now strptime offsets of the form ±HH:MM with %z,
so there's no longer anything blocking you from parsing from all isoformat()
outputs with strptime, provided you know which one you need.
I think a from_isoformat() like method that *only* supports isoformat outputs
IIRC, arrow usually calls dateutil to parse dates anyway, and there are many
other, lighter dependencies that will parse an ISO 8601 date quickly into a
datetime.datetime object.
I still think it's reasonable for the .isoformat() operation to have an inverse
operation in the standard library.
I can write at least a pure Python implementation in the next few days, if not
a full C implementation. Shouldn't be too hard since I've got a few different
Cython implementations sitting around anyway.
On November 29, 2017 7:06:58 PM EST, Alexander Belopolsky
wrote:
>On Wed, Nov 29, 2017 at 6
t deadline
here if we want this for Python 3.7?
Best,
Paul
On 12/01/2017 12:47 PM, Chris Barker wrote:
> On Wed, Nov 29, 2017 at 4:19 PM, Paul G wrote:
>
>> I can write at least a pure Python implementation in the next few days, if
>> not a full C implementation. Shouldn
> And I'm sorry, I got a bit lost in the PR, but you are attaching an
> "offset" tzinfo, when parsing an iso string that has one, yes?
Yes, a fixed offset time zone (since the original zone information is lost):
>>> from dateutil import tz
>>> from datetime import datetime
>>> datetim
One thing to note is that if getting Travis working with Python 3.7 is a pain,
a huge number of libraries on PyPI probably just won't test against Python 3.7,
which is not a great situation to be in.
It's probably worth contacting Travis to give them a head's up and see how
likely it is that th
I don't think it matters so much whether you are stacking two decorators or a
single decorator, but would an @add_unsafe_hash decorator be useful for
anything *except* data classes? If not, then there's no point in having a
*second* decorator that can *only* modify the first one - particularly
Breaking this off from the pickle thread because it seems unrelated:
On 04/02/2018 06:57 PM, Lukasz Langa wrote:
> I think we need to get past thinking about "Python 2" vs. "Python 3". This
> frame of mind creates space for another mythical release of Python that will
> break all the compatibili
ompatibility
will be confusing and annoying for most people (not me, because I know about it
and I test against nightly), and as long as there's a "3" in the "major" slot,
people will speculate about the possibility of a "4".
On 04/03/2018 09:07 AM, Paul Moore wro
> When programs use calendar-based versioning, I'm left with no
> information as to whether it's breaking changes or not. In fact, it
> might as well have no version numbers whatsoever. If I care about
> backward compatibility, I just have to stick with the exact same
> unpatched version that I had
On 04/03/2018 10:10 AM, Nick Coghlan wrote:
> The reason for sticking with 3.x for a while is because of the corner
> \*nix systems have gotten stuck into regarding the "python" symlink,
> and the fact it currently still points to "python2" (if it exists at
> all). Once we've updated PEP 394 to rec
On 04/03/2018 12:36 PM, Brett Cannon wrote:
> On Tue, 3 Apr 2018 at 07:39 Paul G wrote:
> Paul's point is that he knows e.g. code working in 3.6.0 will work when he
> upgrades to 3.6.5, and if his code is warning-free and works with all
> __future__ statements in 3.6 that it
On 04/23/2018 06:04 PM, Tim Peters wrote:
> However, against "as" is that its current use in "with" statements
> does something quite different:
>
> with f() as name:
>
> does not bind the result of `f()` to `name`, but the result of
> `f().__enter__()`. Whether that "should be" fatal, I do
Rust has a few syntactic ways to accomplish the same thing, though. I think
match expressions are used for the equivalent of conditionals that carry the
condition value into the body of the expression, and all blocks return the
result of the last statement, so you can do things like:
let mut x;
This doesn't seem like the best idea, since it would kick off dozens or
hundreds of builds for every commit to the master branch.
On 05/29/2018 11:25 AM, Matthias Bussonnier wrote:
>> As I wrote, it became very difficult to merge any PR on 2.7 because of
>> that. We all run a race to be the first
In many languages numeric types can't hold arbitrarily large values, and I for
one hadn't really previously recognized that if you read in a numeric value
with an exponent that it would be represented *exactly* in memory (and thus one
object with a very compact representation can take up huge am
I think Serhiy is saying that if you delete exc before the except body ends,
when the compiled code goes to delete it it will fail. Binding to None
guarantees that there is something to delete.
On January 6, 2019 4:05:27 PM UTC, Chris Angelico wrote:
>On Mon, Jan 7, 2019 at 2:52 AM Serhiy Storc
I am not familiar enough with the compiler logic, but would it be possible to
optimize this away by detecting whether the bound name has already been deleted
during the body of the except statement?
On January 6, 2019 4:18:00 PM UTC, Chris Angelico wrote:
>On Mon, Jan 7, 2019 at 3:13 AM P
That's a bit of a fine line to walk. I noticed it when writing tests for
IPython, which is not a implementation of Python, but is dealing with the nitty
gritty details and manipulating the syntax tree it's true, but it's roughly the
same class of project as implementing coverage.py, so if we dis
> Do you have an idea of how many projects would emit such warning? More
and more projects are running their test suite using -Werror. Any new
warning can make a project test suite to fail.
I don't have an opinion on __trunc__, but as someone who runs such a project, I
have to say this is exactl
I don't have a terribly strong opinion about whether or not it is acceptable to
use dict.copy, my point was that the desired semantics can be achieved using
only dunder methods if desired, and I think at this point getting the semantics
right probably matters more than the implementation details
It looks to me like dict.__copy__ is not implemented, does anyone know why it's
not basically an alias for dict.copy?
If it's just random happenstance, presumably we could move dict.copy to
__copy__ and then have dict.copy as an alias or thin wrapper. It might be
desirable anyway for copy.copy
27 matches
Mail list logo