[Python-Dev] Re: PEP 584: Add Union Operators To dict

[Paul G]

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 to have a "fast path".

On February 7, 2020 11:21:55 PM UTC, Brett Cannon  wrote:
>I agree that if we want to go down the road of creating a copy to allow
>for subclasses then we should define a dunder method for such a use,
>even if it's redundant in the face of dict.copy().
>___
>Python-Dev mailing list -- python-dev@python.org
>To unsubscribe send an email to python-dev-le...@python.org
>https://mail.python.org/mailman3/lists/python-dev.python.org/
>Message archived at
>https://mail.python.org/archives/list/python-dev@python.org/message/ON3E55CDBUDDHY4BEBYH25ZOKZH7HUDQ/
>Code of Conduct: http://python.org/psf/codeofconduct/
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/2QG4IE5GAQPPGCEY7JCE2VHZHGFYZIWK/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 584: Add Union Operators To dict

[Paul G]

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. If we all agree on 
the semantics and we're just trying to decide how to get there, then I suppose 
I don't have a dog in the fight.

I will note that it doesn't seem to be true that operators never call standard 
methods. Looks like date.__add__ calls date.toordinal and date.fromordinal (at 
least in the pure Python implementation), and datetime calls those plus 
tzinfo.utcoffset. Not sure if the rule Serhiy is citing is only intended to 
apply to builtins, though.

On February 6, 2020 10:25:52 PM UTC, Brandt Bucher  
wrote:
>Sorry Paul, I sent my reply too soon.
>
>I see what you're saying, and I'm pretty firmly -1 on reinventing (or
>importing) copy.copy. We already have an API for copying a dict
>(dict.copy). 
>
>I still fail to see problem with using a method that doesn't start and
>end with underscores, other than that we "haven't done it".
>
>Brandt
>___
>Python-Dev mailing list -- python-dev@python.org
>To unsubscribe send an email to python-dev-le...@python.org
>https://mail.python.org/mailman3/lists/python-dev.python.org/
>Message archived at
>https://mail.python.org/archives/list/python-dev@python.org/message/7TQI54BEUN6GERZA3Y2GCXPBD3CHXKM6/
>Code of Conduct: http://python.org/psf/codeofconduct/
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/SCDWUIQX4ZLLU72QI4PYEG25W6JVIBFT/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Do not fallback to __trunc__ when convert to int

[Paul G]

> 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 exactly the point. I always have the option of adding a 
given warning to my ignore list (as long as it's raised in such a way that this 
is easy to do), and I want the hard error so I can heed the warnings.

Avoiding raising warnings because too many test suites break when using -Werror 
seems counterproductive.

Of course, "lots of stuff breaks with -Werror" could be a proxy for "it would 
be a lot of work to fix this", and maybe all that work isn't worth it for 
whatever improvement you'd get from the fixes, but I think it would be better 
to try and evaluate it on those terms rather than considering broken test 
suites an inherently bad thing.


On November 5, 2019 1:06:42 AM UTC, Victor Stinner  wrote:
>Le jeu. 31 oct. 2019 à 11:41, Serhiy Storchaka  a
>écrit :
>> I propose to deprecate the falling back to __trunc__ for converting
>to
>> int and remove it in future.
>
>As Nick already said, I'm working on PEP 608 "Coordinated Python
>release" which discuss such change:
>https://www.python.org/dev/peps/pep-0608/
>
>It's discussed at:
>https://discuss.python.org/t/rfc-pep-608-coordinated-python-release/2539
>
>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'm looking for help to build a tool to test popular PyPI projects on
>a modified Python version, to be able to answer to such questions.
>
>My current experimental project can only test numpy, coverage and
>jinja2, and it doesn't work well (especially on Python 3.9):
>https://github.com/vstinner/pythonci/
>
>Since this tool doesn't exist yet and since we cannot test all PyPI
>projects, I suggest to keep the option of reverting such change if we
>consider that it breaks too many projects during the Python 3.9 beta
>phase.
>
>Victor
>-- 
>Night gathers, and now my watch begins. It shall not end until my
>death.
>___
>Python-Dev mailing list -- python-dev@python.org
>To unsubscribe send an email to python-dev-le...@python.org
>https://mail.python.org/mailman3/lists/python-dev.python.org/
>Message archived at
>https://mail.python.org/archives/list/python-dev@python.org/message/KAIJFQW6OVMRYUIHL7H4KRGF2E2S6WTM/
>Code of Conduct: http://python.org/psf/codeofconduct/
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/PFPNUZIDZ4CW5ODKTS3QINZDY4SROWUY/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Removing dead bytecode vs reporting syntax errors

[Paul G]

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 disqualify all the 
people who notice these bugs because they are working on abstruse meta-code 
manipulation, I think both sides will come up empty.

On July 5, 2019 10:39:27 PM UTC, Ned Batchelder  wrote:
>I can understand the desire for correctness.  I do have to wonder 
>though: has anyone *other* than language implementors noticed this
>issue 
>with SyntaxErrors not being reported?
>
>Perhaps we should remember "Practicality beats purity"?
>
>--Ned.
>
>On 7/5/19 6:14 PM, Pablo Galindo Salgado wrote:
>> > Until a solution which makes everyone happy can be found, I suggest
>to
>> move back to the status quo: revert the change.
>>
>> >More people seems to expect "if 0: ..." to be removed, than people
>who
>> care of syntax errors on "if 0".
>>
>> I don't think this is that clear. As Paul wrote on the issue this is 
>> the  result of fixing a bug that has been open since
>> 2008 (11 years), which itself was noticed independently, also in 2008
>
>> (#1875 and #1920, respectively).
>> He also independently discovered the same issue last year when
>writing 
>> some tests for IPython.
>>
>> https://bugs.python.org/msg347394
>>
>> On Fri, 5 Jul 2019 at 23:10, Victor Stinner > > wrote:
>>
>> Hi,
>>
>> Until a solution which makes everyone happy can be found, I
>suggest to
>> move back to the status quo: revert the change.
>>
>> More people seems to expect "if 0: ..." to be removed, than
>people who
>> care of syntax errors on "if 0".
>>
>> --
>>
>> Would it be possible to detect if the "if 0" block would raise a
>> syntax error, and only remove it if it doesn't raise a syntax
>error?
>>
>> That's the approach I chose in my fatoptimizer project which is
>> implemented as an AST optimizer:
>>
>https://github.com/vstinner/fatoptimizer/blob/master/fatoptimizer/dead_code.py
>>
>> See the tests to see which cases are *not* optimized:
>>
>https://github.com/vstinner/fatoptimizer/blob/master/test_fatoptimizer.py#L2428
>>
>> Some examples (the "dead code elimitaiton" is not only about "if
>0",
>> but also "while 0", dead code after return, etc.):
>>
>>     self.check_dont_optimize("""
>>         def func():
>>             if 0:
>>                 yield
>>     """)
>>
>>     self.check_dont_optimize("while 1: x = 1")
>>
>>     self.check_dont_optimize("""
>>         def func(obj):
>>             return
>>             if 0:
>>                 yield from obj
>>     """)
>>
>>     self.check_dont_optimize("""
>>         try:
>>             pass
>>         except Exception:
>>             yield 3
>>     """)
>>
>> See also the doc:
>>
>https://fatoptimizer.readthedocs.io/en/latest/optimizations.html#dead-code
>>
>> --
>>
>> About code coverage, it seems like -X noopt would help:
>> https://github.com/python/cpython/pull/13600
>>
>> But I'm not sure anymore after Ned Batchelder wrote:
>>
>> "The real-word implications from my world are this: if your code
>has
>> "if 0:" clauses in it, and you measure its coverage, then because
>the
>> lines have not been optimized away, coverage.py will think the
>lines
>> are a possible execution path, and will be considered a miss
>because
>> they are not executed.  This will reduce your coverage
>percentage."
>> https://bugs.python.org/issue37500#msg347362
>>
>> Does it mean that coverage.py will report even more "false
>positive"
>> using -X noopt?
>>
>> Victor
>>
>>
>> ___
>> Python-Dev mailing list -- python-dev@python.org
>> To unsubscribe send an email to python-dev-le...@python.org
>> https://mail.python.org/mailman3/lists/python-dev.python.org/
>> Message archived at
>https://mail.python.org/archives/list/python-dev@python.org/message/LWZPZQ2IL67DPX3RC342TTOVCLKDSBTJ/
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/JWMNYB4F2S7XMCWLSHJ2IQG3D5MFEQMU/

Re: [Python-Dev] Compilation of "except FooExc as var" adds useless store

[Paul G]

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 Paul G  wrote:
>>
>> 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.
>
>Ahh! Thank you. I interpreted that example as a "this is what it
>compiles to", rather than actual source code that might fail. Can we
>get this example, suitably annotated, into the documentation
>somewhere?
>
>ChrisA
>___
>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/paul%40ganssle.io
___
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-archive.com

Re: [Python-Dev] Compilation of "except FooExc as var" adds useless store

[Paul G]

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 Storchaka 
>wrote:
>>
>> 06.01.19 17:35, Chris Angelico пише:
>> > On Mon, Jan 7, 2019 at 2:27 AM Serhiy Storchaka
> wrote:
>> >> Because there is a reason for such code.
>> >
>> > What reason though??
>>
>> I added references and excerpts in the previous message.
>
>Which I read, and they do not explain the assignment of None. The only
>reference is that the tracker issue mentions having a test case to
>ensure that it's happening, which is further proof that it's
>intentional, but still fails to explain *why*.
>
>ChrisA
>___
>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/paul%40ganssle.io
___
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-archive.com

Re: [Python-Dev] Fuzzing the Python standard library

[Paul G]

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 amounts of memory). 
It's also not *inconceivable* that under the hood Python would represent 
fractions.Fraction("1.64E664644") "lazily" in some fashion so that it did 
not consume all the memory on disk.

It seems to me that "Hey by the way the size of this thing is unbounded and 
because of exponents small strings can expand to huge objects" is a good tip.

On 07/17/2018 06:15 PM, Michael Selik wrote:
> On Tue, Jul 17, 2018 at 4:57 PM Jussi Judin  > wrote:
> 
> Quick answer: undocumented billion laughs/exponential entity expansion 
> type of an attack that is accessible through web through any library that 
> uses fractions module to parse user input (that are actually available on 
> Github).
> 
> 
> Are you suggesting a warning in the fractions documentation to mention that 
> large numbers require large amounts of memory?
> 
> 
> ___
> 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/paul%40ganssle.io
> 



signature.asc
Description: OpenPGP digital signature
___
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-archive.com

Re: [Python-Dev] Troubles to merge changes in the 2.7 branch: PR "out-of-date" branch

[Paul G]

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 one to merge a change into
>> 2.7. The next one will get a "conflict" even if the merged commit is
>> unrelated (as I described: two different unrelated directories).
> 
> Couldn't miss-islington be configured to automatically rebase those (when
> there is no actual conflict). The "Allow edit from maintainer" would most
> likely permit to push on the PRs branch.
> 
> 
> 
> ___
> 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/paul%40ganssle.io
> 



signature.asc
Description: OpenPGP digital signature
___
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-archive.com

Re: [Python-Dev] Is PEP 572 really the most effective way to solve the problems it's targeting?

[Paul G]

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;
while { x = foo(); x } {
 bar(x);
}

I don't know if that's idiomatic Rust (and I wrote it on a phone and didn't 
check to be sure it compiles), but it does more or less solve the problem of 
assignment in a control flow condition.

On April 27, 2018 12:58:16 AM UTC, Steven D'Aprano  wrote:
>On Thu, Apr 26, 2018 at 09:36:48AM -0700, Mike Miller wrote:
>
>> However, there were two good questions in this message which I
>haven't seen 
>> addressed yet:
>> 
>> - How are other modern languages solving this issue?
>> - How does this new construct intersect with typing
>functionality?
>
>What counts as a modern language? Less than five years old? Less than 
>fifty years old? Are Javascript, Ruby and R modern? They all support 
>assignment as expressions.
>
>I think Koitlin, Rust and Go prohibit assignment as expressions.
>
>Swift assignment evaluates as Void (equivalent to None in Python, I 
>guess), so you can use assignment in an expression but it returns 
>nothing and only operates by side-effect.
>
>As far as type hints go, I think that if you need explicit type hints
>in 
>the middle of an expression, it's a bad idea and you ought to pull it 
>out as a separate statement. That applies regardless of whether that 
>expression involves binding or not.
>
>
>-- 
>Steve
>___
>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/paul%40ganssle.io
___
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-archive.com

Re: [Python-Dev] PEP 572: Assignment Expressions

[Paul G]

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 don't know, but
> it's at least annoying ;-)


This could be read a different way, though, since `with f()` calls 
`f().__enter__()`, you could read it as `(with f()) as name:`, in which case it 
does the same thing as an `as`-based binding expression would. Viewing it that 
way *also* helps alleviate the cognitive problem that `with f() as name` and 
`with (f() as name)` do two different things - the parentheses there are 
changing the precedence in the same way that `2 + 4 * 3` and `(2 + 4) * 3` do 
two different things.

This sorta also works for `except`, if you read it as `(except SomeException) 
as e:`, but I think this fiction falls apart when you look at `import`, since 
`import foo` *already* binds "foo" to a name, and `import foo as bar` not only 
binds `foo` to `bar`, but also *doesn't* bind `foo` to `foo`.



signature.asc
Description: OpenPGP digital signature
___
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-archive.com

Re: [Python-Dev] Python version numbers

[Paul G]

On 04/03/2018 12:36 PM, Brett Cannon wrote:
> On Tue, 3 Apr 2018 at 07:39 Paul G <p...@ganssle.io> 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 will work fine in 3.7. With CalVer you
> could make a similar promise if you keep the major version the year of
> release and then keep our feature/bugfix number promise like we already
> have, but at that point who cares about the year?

I think it is reasonable to use a scheme like this:

YY.MM.patch

The canonical release is numbered by Year-Month, and patches intended to add 
new features and break nothing get a patch release, no matter when they are 
released. That allows for simple pinning.

> While we have an 18 month schedule for releases, we also can't guarantee we
> will hit our release window in a specific year, e.g. 3.6 was first released
> in December but we could have slipped into January. That makes promises for
> a specific version tied to a year number problematic.

I think no promises for a specific version number need to be made until *after* 
a release is made. Using calendar-based versioning facilitates using a 
calendar-based deprecation schedule, irrespective of how many releases have 
occurred between the deprecation and the removal. If the promise is "we will 
support this feature for 5 years", then you know ahead of time the minimum 
version number in which that feature will be removed.

So say you have a function foo() called in your library that is deprecated in 
the 20.05.0 feature release. You know at that point that any release *after* 
25.05.0 will drop support for foo, so on your next release that uses foo(), you 
set the upper bound on your `requires_python` to `<25.05.0`. It doesn't matter 
if that release happens in 2025-08 or 2027-01.

Similarly if you are developing some cutting edge library that is using 
features from the "feature release" branch, you can set `requires_python` to 
some value with a month greater than the current calendar version.


> If we chose to switch to semantic versioning, we would probably make it so
> that any version that makes a __future__ statement the new default is a
> major version bump. But then the issue becomes the stdlib. Do we drop
> everything that was previously deprecated in the stdlib for every major
> version bump? That might be a bit drastic when e.g. all you did was make
> old code that used `await` as a variable name raise a SyntaxError. And
> saying "deprecated for two versions" then becomes messy because you have no
> idea what that second version will be. And what if you **really** want to
> get rid of something in the next release? Can a single module dropping a
> function force a version bump for Python itself?

This is why I suggested a calendar-version based approach, along with a 
pre-commitment that the "rolling backwards compatibility window" would be a 
specific amount of *time*, not a specific number of versions. It makes it very 
easy to make predicitions about when specific features are falling in and out 
of that window, because each deprecation warning can come *pre-populated* with 
the length of the deprecation period and, as a result, the maximum version that 
will support that feature. If that were done, you could even concievably write 
a "compatibility checker" tool that can be run against a repo to calculate the 
`requires_python` upper bound and to order deprecation warnings by urgency.


> I have not read the other thread, but knowing it's from Lukasz makes me
> guess he wants to move up the minor number to become the major one in terms
> of our current semantics so we have a rolling window of support. That would
> mean that as long as you are warnings-free and run fine with all __future__
> statements turned on for version N then N+1 should work for you without
> modification (sans relying on buggy semantics). That approach would deal
> with the above issues cleanly while dropping what our current major number
> semantics which some people view as a fallacy and are getting upset over
> (I'm personally +0 on this last idea as it's easy to explain to folks and I
> have been doing Python version explanations a lot over the last several
> months).
> 

Lukasz did not propose any changes to the version number semantics, just the 
deprecation schedule. I was suggesting that if this happens, it's probably a 
good idea to "drop" the major version number - either by incrementing it with 
each release that breaks backwards compat (which, for a sufficiently continuous 
influx of rolling deprecations should be basically every feature release), or 
by switching to a calendar-based system. From above, I think a calendar-based 
system has the best f

Re: [Python-Dev] Python version numbers

[Paul G]

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 recommend pointing it at Python 3
> (which is currently looking like it might happen around the 3.8 or 3.9
> time frame), then we can start talking about instead pointing it at
> python 4.x, and making "python3" just be a confusingly named symlink
> to python4.x.

I was definitely not suggesting this before the end of the Python 2 era, but I 
don't think Lukasz was suggesting this either. I'm suggesting it specifically 
for the period of time during which Python is using the "rolling backwards 
compatibility guarantee" standard laid out in the original posting.

I would think in terms of evaluating this proposal, it is (in order) worth 
considering:

1. Is it a desirable goal
2. Is it an achievable goal?
3. How specifically can it be achieved?
4. What is the implementation timeline?

If #1 and #2 are true (which is my contention), *then* the specific details can 
be ironed out about how and when. Ideally, if it is desirable and achievable, 
it might be prudent to wait to start the "rolling backwards compatibility 
guarantee" era as part of the new versioning scheme rollout, rather than 
updating the versioning scheme post-hoc to reflect the new status quo.



signature.asc
Description: OpenPGP digital signature
___
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-archive.com

Re: [Python-Dev] Python version numbers

[Paul G]

> 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 before. Not a good thing for a language
> that releases periodic bugfix updates to older versions.

Well, this is not true. As a general rule, you don't know if anything *you care 
about* breaks at a given version change anyway, and I've seen plenty of 
handwringing about what should and should not be considered a breaking change. 
A major change is basically the "nuclear option", and everything I've seen from 
core developers is "there will never be another major change on the scale of 
2->3". Given that from an optics perspective there's no interest in creating a 
Python 4 and it's been repeatedly emphasized in this thread that Python doesn't 
use semantic versioning, I don't see how you can really say that the version 
number gives you much information at all about what will and will not break.

This thread started in response to a proposal to just have a rolling backwards 
compatibility window (e.g. no discontinuous major version changes), which is 
basically ideal for calendar versioning - any time you make a backwards 
incompatible change, you give X notice period. You can encode X directly into 
the deprecation warnings (e.g. "This feature will be removed in Python >= 
2025"), that way users will know on a *per feature basis* where to pin, even 
before specific version numbers are announced.

Presumably if major breaking changes ever *do* occur, the mechanism for 
upgrading Python would be either to create a new program called something else 
(e.g. the core Python simply *does not break backwards compat*), or a slow 
rollout with individual feature flags that start out defaulting on (opt in to 
the new behavior), eventually default to off (opt out of the new behavior), and 
then are removed after a very long deprecation period.



signature.asc
Description: OpenPGP digital signature
___
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-archive.com

Re: [Python-Dev] Python version numbers

[Paul G]

That documentation seems like a "layman's explanation" of how semantic 
versioning works. I suspect anyone familiar with semantic versioning will read 
that and think, "Ah, yes, this is a semantic versioning scheme." 

Regardless of the semantics (har har) of whether Python "follows strict 
semantic versioning", a change to the versioning scheme (CalVer should be 
backwards compatible with SemVer, mind you, since (21, 0, 0) > (3, 8, 0)) 
should make it absolutely clear that Python is not following SemVer.

Counter-intuitively, I think the *fact* of pinning the major version number to 
3 is a worse signal of "we're not going to break everything" than switching to 
CalVer could. By switching to CalVer, you are removing the *ability* to signal 
a discontinuous major breaking change just by the version number. It is very 
much a "burn your boats so you can't retreat" philosophy to versioning.

Of course, if we want to reserve the ability to have sudden and major breaking 
changes, then yes, sticking with the current semi-SemVer system is fine, but I 
suspect that the fact that minor releases can break backwards compatibility 
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 wrote:
> On 3 April 2018 at 13:51, Paul G <p...@ganssle.io> wrote:
>> Maybe this has already been discussed ad nauseum, but is the idea here that 
>> Python will stay on Python 3.x, but also start breaking backwards 
>> compatibility with old versions? That would seem to be a violation of 
>> semantic versioning.
> 
> Python's versions don't follow strict semantic versioning. See
> https://docs.python.org/3/faq/general.html#how-does-the-python-version-numbering-scheme-work
> 
> Paul
> 



signature.asc
Description: OpenPGP digital signature
___
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-archive.com

[Python-Dev] Python version numbers

[Paul G]

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 compatibilities, something we promised not to do. A moving 
> backward compatibility window that includes the last release still under 
> security fixes seems like a good new framework for this.

Maybe this has already been discussed ad nauseum, but is the idea here that 
Python will stay on Python 3.x, but also start breaking backwards compatibility 
with old versions? That would seem to be a violation of semantic versioning.

I think if this is going to happen, it should either be that the major version 
number gets bumped with every compatibility-breaking release, or Python should 
switch to some form of calendrical versioning (which may amount to more or less 
the same thing, but be different enough that people won't freak out when you 
say Python 4 is coming): https://calver.org

Switching to CalVer is a pretty clear sign that there is now a "rolling 
backwards compatibility window", and it allows Python to skip right over the 
mythical "Python 4" and directly to "Python 21". Additionally, since the 
version number will be trivially predictable, deprecation warnings can actually 
include the version after which they will be dropped - so if a feature is 
slated to be removed 5 years after it is initially deprecated, just take the 
deprecation release version and add 5.



signature.asc
Description: OpenPGP digital signature
___
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-archive.com

Re: [Python-Dev] Dataclasses and correct hashability

[Paul G]

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 
considering @dataclass actually takes arguments.

On 02/05/2018 02:12 PM, Guido van Rossum wrote:
> Yes, that's what I meant -- "afterwards" meaning after the @dataclass
> decorator is applied.
> 
> On Mon, Feb 5, 2018 at 11:09 AM, Kirill Balunov 
> wrote:
> 
>>
>> 2018-02-05 20:47 GMT+03:00 Guido van Rossum :
>>
>>> If there's going to be an API for it, it should be in the class, not
>>> something that mutates the class afterwards.
>>>
>>
>>
>> I apologize and don't want to make unnecessary noise. But the already
>> selected design with decorator @dataclass implies that it will mutate
>> the freshly created class (which in its turn already limits some
>> possibilities), or I've missed something? If you meant that everything
>> should be defined in one place, then I basically understand your desire as
>> the least of two evils.
>>
>> With kind regards,
>> -gdg
>>
> 
> 
> 
> 
> 
> ___
> 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/paul%40ganssle.io
> 



signature.asc
Description: OpenPGP digital signature
___
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-archive.com

Re: [Python-Dev] Python 3.7: Require OpenSSL >=1.0.2 / LibreSSL >= 2.5.3

[Paul G]

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 they'll be able to support Python 3.7 if it requires a newer 
version of these libraries.


On January 14, 2018 2:16:53 AM UTC, Brett Cannon  wrote:
>On Sat, Jan 13, 2018, 14:45 Christian Heimes, 
>wrote:
>
>> On 2018-01-13 21:02, Brett Cannon wrote:
>> > +1 from me as well for the improved security.
>>
>> Thanks, Brett!
>>
>> How should we handle CPython's Travis CI tests? The 14.04 boxes have
>> OpenSSL 1.0.1. To the best of my knowledge, Travis doesn't offer
>16.04.
>> We could either move to container-based testing with a 16.04
>container,
>> which would give us 1.0.2 Or we could compile our own copy of OpenSSL
>> with my multissl builder and use some rpath magic.
>>
>> In order to test all new features, Ubuntu doesn't cut it. Even
>current
>> snapshot of Ubuntu doesn't contain OpenSSL 1.1. Debian Stretch or
>Fedora
>> would do the trick, though.
>>
>> Maybe Barry's work on official test container could leveraged
>testing?
>>
>
>My guess is we either move to containers on Travis, see if we can
>manually
>install -- through apt or something -- a newer version of OpenSSL, or
>we
>look at alternative CI options.
>
>-Brett
>
>
>> Regards,
>> Christian
>>
___
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-archive.com

Re: [Python-Dev] iso8601 parsing

[Paul G]

> 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
>>> datetime(2014, 12, 11, 9, 30, tzinfo=tz.gettz('US/Eastern'))
datetime.datetime(2014, 12, 11, 9, 30, 
tzinfo=tzfile('/usr/share/zoneinfo/US/Eastern'))
>>> datetime(2014, 12, 11, 9, 30, tzinfo=tz.gettz('US/Eastern')).isoformat()
'2014-12-11T09:30:00-05:00'
>>> datetime.fromisoformat('2014-12-11T09:30:00-05:00')
datetime.datetime(2014, 12, 11, 9, 30, 
tzinfo=datetime.timezone(datetime.timedelta(days=-1, seconds=68400)))

> I fully agree that that's the MVP -- but is it that hard to parse arbitrary
> ISO8601 strings in once you've gotten this far? It's a bit uglier than I'd
> like, but not THAT bad a spec.

No, and in fact this PR is adapted from a *more general* ISO-8601 parser that I 
wrote (which is now merged into master on python-dateutil). In the CPython PR I 
deliberately limited it to be the inverse of `isoformat()` for two major 
reasons:

1. It allows us to get something out there that everyone can agree on - not 
only would we have to agree on whether to support arcane ISO8601 formats like 
-Www-D, but we also have to then discuss whether we want to be strict and 
disallow MM like ISO-8601 does, do we want fractional minute support? What 
about different variations (we're already supporting replacing T with any 
character in `.isoformat()` and outputting time zones in the form hh:mm:ss, so 
what other non-compliant variations do we want to add... and then maintain? We 
can have these discussions later if we want, but we might as well start with 
the part everyone can agree on - if it comes out of `isoformat()` it should be 
able to go back in througuh `fromisoformat()`.

2. It makes it *much* easier to understand what formats are supported. You can 
say, "This function is for reading in dates serialized with `.isoformat()`", 
you *immediately* know how to create compliant dates. Not to mention, the 
specific of formats emitted by `isoformat()` can be written very cleanly as: 
-MM-DD[*[HH[:MM[:SS[.mmm[mmm][+HH:MM]] (where * means any character). 
ISO 8601 supports -MM-DD and MMDD but not -MMDD or MM-DD

So, basically, it's not that it's amazingly hard to write a fully-featured 
ISO-8601, it's more that it doesn't seem like a great match for the problem 
this is intended to solve at this point.

Best,
Paul

On 12/07/2017 08:12 PM, Chris Barker wrote:
> 
>> Here is the PR I've submitted:
>>
>> https://github.com/python/cpython/pull/4699
>>
>> The contract that I'm supporting (and, I think it can be argued, the only
>> reasonable contract in the intial implementation) is the following:
>>
>> dtstr = dt.isoformat(*args, **kwargs)
>> dt_rt = datetime.fromisoformat(dtstr)
>> assert dt_rt == dt# The two points represent the
>> same absolute time
>> assert dt_rt.replace(tzinfo=None) == dt.replace(tzinfo=None)   # And
>> the same wall time
>>
> 
> 
> that looks good.
> 

> I see this in the comments in the PR:
> 
> 
> """
> This does not support parsing arbitrary ISO 8601 strings - it is only
> intended
> as the inverse operation of :meth:`datetime.isoformat`
> """
> 

> 
> what ISO8601 compatible features are not supported?
> 
> -CHB
> 
> 



signature.asc
Description: OpenPGP digital signature
___
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-archive.com

Re: [Python-Dev] iso8601 parsing

[Paul G]

As an update, I have the C version done and basically tested as an extension (I 
"cheated" on the tests by using hypothesis, so I still need to write 
unittest-style tests), just writing the Python version with tests now.

I know there is a feature freeze coming in soon, is there a strict 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 <p...@ganssle.io> wrote:
> 
>> 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.
>>
>>
> Thanks!
> 
> -CHB
> 
> 
> 
> 
>> On November 29, 2017 7:06:58 PM EST, Alexander Belopolsky <
>> alexander.belopol...@gmail.com> wrote:
>>>
>>>
>>>
>>> On Wed, Nov 29, 2017 at 6:42 PM, Chris Barker <chris.bar...@noaa.gov>
>>> wrote:
>>>
>>>>
>>>> indeed what is the holdup? I don't recall anyone saying it was a bad
>>>> idea in the last discussion.
>>>>
>>>> Do we just need an implementation?
>>>>
>>>> Is the one in the Bug Report not up to snuff? If not, then what's wrong
>>>> with it? This is just not that hard a problem to solve.
>>>>
>>>
>>>
>>> See my comment from over a year ago: <https://bugs.python.org/
>>> issue15873#msg273609>.  The proposed patch did not have a C
>>> implementation, but we can use the same approach as with strptime and call
>>> Python code from C.  If users will start complaining about performance, we
>>> can speed it up in later releases.  Also the new method needs to be
>>> documented.  Overall, it does not seem to require more than an hour of work
>>> from a motivated developer, but the people who contributed to the issue in
>>> the past seem to have lost their interest.
>>>
>>
> 
> 



signature.asc
Description: OpenPGP digital signature
___
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-archive.com

Re: [Python-Dev] iso8601 parsing

[Paul G]

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:42 PM, Chris Barker 
>wrote:
>
>>
>> indeed what is the holdup? I don't recall anyone saying it was a bad
>idea
>> in the last discussion.
>>
>> Do we just need an implementation?
>>
>> Is the one in the Bug Report not up to snuff? If not, then what's
>wrong
>> with it? This is just not that hard a problem to solve.
>>
>
>
>See my comment from over a year ago: <
>https://bugs.python.org/issue15873#msg273609>.  The proposed patch did
>not
>have a C implementation, but we can use the same approach as with
>strptime
>and call Python code from C.  If users will start complaining about
>performance, we can speed it up in later releases.  Also the new method
>needs to be documented.  Overall, it does not seem to require more than
>an
>hour of work from a motivated developer, but the people who contributed
>to
>the issue in the past seem to have lost their interest.
___
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-archive.com

Re: [Python-Dev] iso8601 parsing

[Paul G]

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.

On November 28, 2017 3:45:41 PM EST, Skip Montanaro  
wrote:
>> 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.
>
>Or just punt and install arrow:
>
 import arrow
 arrow.get('2017-10-20T08:20:08.986166+00:00')
>
 arrow.get('2017-10-20T08:20:08.986166+00:00').datetime
>datetime.datetime(2017, 10, 20, 8, 20, 8, 986166, tzinfo=tzoffset(None,
>0))
>
>Skip
___
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-archive.com

Re: [Python-Dev] iso8601 parsing

[Paul G]

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 
is a fine idea, though, with a fairly obvious interface. I'd be happy to take a 
crack at it (I've been working on the somewhat harder problem of an iso8601 
compliant parser for dateutil, so this is fresh in my mind).

On November 28, 2017 2:51:14 PM EST, Mike Miller  
wrote:
>This may have gotten bogged down again.  Could we get the output of 
>datetime.isoformat() parsed at a minimum?  Perfection is not required.
>
>Looks like there is a patch or two and test cases on the bug.
>
>-Mike
>
>
>> Could anyone put this five year-old bug about parsing iso8601 format
>date-times 
>> on the front burner?
>> 
>>      http://bugs.python.org/issue15873
>> 
>> In the comments there's a lot of hand-wringing about different
>variations that 
>> bogged it down, but right now I only need it to handle the output of 
>> datetime.isoformat():
>> 
>>      >>> dt.isoformat()
>>      '2017-10-20T08:20:08.986166+00:00'
>> 
>> Perhaps if we could get that minimum first step in, it could be
>iterated on and 
>> made more lenient in the future.
>> 
>___
>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/paul%40ganssle.io
___
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-archive.com

Re: [Python-Dev] Guarantee ordered dict literals in v3.7?

[Paul G]

@ Paul Moore
> This seems like overkill to me. By the same logic, we should add a
> "delay garbage collection" mode, that allows people to test that their
> code doesn't make unwarranted assumptions that a reference-counting
> garbage collector is in use.

But you can get pretty fine-grained control of garbage collection with 
judicious use of gc.disable(). If there were a similar mechanism for changing 
the ordering properties of dictionaries in code, I wouldn't suggest it as an 
interpreter flag / option.

And you're right - it's not pressing - the people likely to test with 
dictionaries scrambled are exactly the people likely to be supporting 2.7 and 
3.5, but that won't be true forever, and it would be nice to have *some* 
mechanism to test that you're not relying on this property.

@Barry Warsaw
> As has been suggested elsewhere, if we decide not to make that guarantee, 
> then we should probably deliberately randomize iteration order.

This was my suggestion of a middle way, since deliberate randomization seems 
like a step too far just to avoid people relying on implementation details. 
I've seen plenty of 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, Paul G <p...@ganssle.io> wrote:
>> 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 about 
>> dictionary ordering without having to use an implementation where order 
>> isn't deterministic.
>>
>> I could either be something like an environment variable SCRAMBLE_DICT_ORDER 
>> or a flag like --scramble-dict-order. That would probably help somewhat with 
>> the very real problem of "everyone's going to start counting on this ordered 
>> property".
> 

> 
> Most public projects (which are the only ones that really need to
> worry about this sort of detail) will probably be supporting Python
> 3.5 and likely even Python 2.7 for some time yet. So they test under
> non-order-preserving dictionary implementations anyway. And if code
> that's only targeted for Python 3.7 assumes order preserving
> dictionaries, it's likely not got a huge user base anyway, so what's
> the problem?
> 
> Paul
> 



signature.asc
Description: OpenPGP digital signature
___
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-archive.com

Re: [Python-Dev] Guarantee ordered dict literals in v3.7?

[Paul G]

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 about dictionary 
ordering without having to use an implementation where order isn't 
deterministic.

I could either be something like an environment variable SCRAMBLE_DICT_ORDER or 
a flag like --scramble-dict-order. That would probably help somewhat with the 
very real problem of "everyone's going to start counting on this ordered 
property".

On 11/07/2017 12:58 PM, Barry Warsaw wrote:
> On Nov 7, 2017, at 09:39, Paul Sokolovsky  wrote:
> 
>> So, the problem is that there's no "Python language spec”.
> 
> There is a language specification: 
> https://docs.python.org/3/reference/index.html
> 
> But there are still corners that are undocumented, or topics that are 
> deliberately left as implementation details.
> 
> Cheers,
> -Barry
> 
> 
> 
> ___
> 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/paul%40ganssle.io
> 



signature.asc
Description: OpenPGP digital signature
___
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-archive.com

Re: [Python-Dev] Guarantee ordered dict literals in v3.7?

[Paul G]

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 
dictionaries - it would be nice to be able to differentiate out the parts where 
order actually *does* matter.

(Of course, given that CPython's implementation is order-preserving, a bunch of 
code is probably now being written that implicitly requires on this detail, but 
at least having syntax that makes that clear would give people the *option* to 
make the assumption explicit).

On 11/06/2017 01:19 PM, Barry Warsaw wrote:
> On Nov 6, 2017, at 02:18, Paul Sokolovsky  wrote:
> 
>> What it will lead to is further fragmentation of the community. Python2
>> vs Python3 split is far from being over, and now there're splits
>> between:
>>
>> * people who use "yield from" vs "await"
>> * people who use f-strings vs who don't
>> * people who rely on sorted nature of dict's vs who don't
> 
> This is the classic argument of, do you proceed conservatively and use the 
> lowest-common denominator that makes your code work with the widest range of 
> versions, or do you ride the wave and adopt the latest and greatest features 
> as soon as they’re available?
> 
> Neither answer is wrong or right… for everyone.  It’s also a debate as old as 
> the software industry. Every package, project, company, developer, community 
> will have to decide for themselves.  Once you realize you can’t win, you’ve 
> won! :)
> 
> -Barry
> 
> 
> 
> ___
> 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/paul%40ganssle.io
> 



signature.asc
Description: OpenPGP digital signature
___
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-archive.com

Re: [Python-Dev] Guarantee ordered dict literals in v3.7?

[Paul G]

> Scientific applications want something like
> 
>{'a': 10, 'b': "foo", 'c': {'this': b'123'}}
> 
> as an ordered initializer for unboxed or typed (or both) data. In general,
> if dicts are ordered, they can be used for example as initializers for
> (nested) C structs.

I can understand why you'd want an ordered container, I just don't see why it 
must be a dict. Why can't it be:

OrderedDict(a=10, b='foo', c=OrderedDict(this=b'123'))

Is it just that you don't want to type OrderedDict that many times? If it's so 
important to provide ordered dictionary literals, I would think it's a 
no-brainer to give them their own literal syntax (rather than re-defining dicts 
to have guaranteed order). e.g.:

o{'a': 10, 'b': '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 -0500, Paul G wrote:
>> 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 see 
>> is that this introduces a huge backwards compatibility burden on all 
>> implementations of Python.
> 

> 
> 
> 
>> 2. Someone invents a new arbitrary-ordered container that would improve on 
>> the memory and/or CPU performance of the current dict implementation
> 
> I would think this is very unlikely, given that the previous dict 
> implementation
> has always been very fast. The new one is very fast, too.
> 
> 
> 
> Stefan Krah
> 
> 
> 
> ___
> 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/paul%40ganssle.io
> 



signature.asc
Description: OpenPGP digital signature
___
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-archive.com

Re: [Python-Dev] Guarantee ordered dict literals in v3.7?

[Paul G]

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 see is that 
this introduces a huge backwards compatibility burden on all implementations of 
Python.

It's possible that no implementations of Python (either future CPython versions 
or current/future alternative interpreters) will find any reason to use 
anything but an insertion-order sorted dictionary, but given that we've done 
just fine with arbitrary-order semantics for the entire lifetime of the 
language /and/ there is a container (OrderedDict) which has guaranteed order 
semantics, it doesn't seem worth it to me.

I think I would mostly be concerned with (in terms of likeliness to occur):

1. An edge case we haven't thought of where arbitrary order dictionaries would 
allow some crticial optimization for a given platform (perhaps in someone 
writing a transpiler to another language where the convenient equivalent 
container has arbitrary order, e.g. if Brython wants to implement dicts in 
terms of objects - 
https://stackoverflow.com/questions/5525795/does-javascript-guarantee-object-property-order
 )

2. Someone invents a new arbitrary-ordered container that would improve on the 
memory and/or CPU performance of the current dict implementation

3. Some sort of bug or vulnerability is discovered that makes insertion-ordered 
dictionaries an unwise choice (similar to the hash collision vulnerability that 
necessitated hash randomization - 
https://stackoverflow.com/questions/14956313#14959001 ).

Perhaps these concerns are overblown, but if indeed guaranteed-order Mapping 
literals are critical in some or many cases, maybe it would be preferable to 
introduce new syntax for OrderedDict literals.

Best,
Paul

On 11/05/2017 12:50 PM, Guido van Rossum wrote:
> Yup. At least such code will not break in 3.5.
> 
> In general if you write code using a newer version you should expect
> arbitrary breakage when trying to run it under older versions. There is no
> compatibility guarantee in that direction for anything anyways.
> 
> I don't see this as a reason to not put this into the language spec at 3.7.
> 
> On Sun, Nov 5, 2017 at 9:37 AM, Barry Warsaw  wrote:
> 
>> On Nov 4, 2017, at 11:35, Guido van Rossum  wrote:
>>>
>>> This sounds reasonable -- I think when we introduced this in 3.6 we were
>> worried that other implementations (e.g. Jython) would have a problem with
>> this, but AFAIK they've reported back that they can do this just fine. So
>> let's just document this as a language guarantee.
>>
>> The other concern was backward compatibility issues.  For example, if 3.7
>> makes this guarantee official, and folks write code with this assumption
>> that has to work with older versions of Python, then that code could be
>> buggy in previous versions and work in 3.7.  This will probably be most
>> evident in test suites, and such failures are often mysterious to debug (as
>> we’ve seen in the past).
>>
>> That doesn’t mean we shouldn’t do it, but it does mean we have to be
>> careful and explicit to educate users about how to write safe
>> multi-Python-version code.
>>
>> Cheers,
>> -Barry
>>
>>
>> ___
>> 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/
>> guido%40python.org
>>
>>
> 
> 
> 
> 
> ___
> 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/paul%40ganssle.io
> 



signature.asc
Description: OpenPGP digital signature
___
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-archive.com