Re: [Python-Dev] Usefulness of binary compatibility accross Python versions?

[Antoine Pitrou]

On Sun, 17 Dec 2017 21:07:02 -0500
Random832  wrote:
> 
> Is there any practical for of having the flag off for one slot and on
> for another slot that's been added later?
> 
> Could this be replaced (that is, a slot for such a thing added before
> it's too late) with a simple counter that goes up with each version, and
> any "unused" slot should have NULL or some other sentinel value?

Any replacement here would break binary compatibility, which is what
those flags are precisely meant to avoid.

> If it
> really is important to have the flags themselves, just add another set
> of flags - Py_TPFLAGS_HAVE_MORE_FLAGS.

Yes, we could... but it's more complication again.

That said, if we decide to drop cross-version compatibility, we then
are allowed to enlarge the tp_flags field to, say, 64 bits.

Regards

Antoine.


___
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] Broken svn lookup?

[Victor Stinner]

Hi,

I was looking at old issues. In
https://bugs.python.org/issue8610#msg105805 I found the link:

  http://svn.python.org/view?view=revision&revision=81190

Sadly, the link fails with HTTP 404 Not Found :-(

Is the service down? It's no more possible to browse the old
Subversion repository?

Victor
___
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?

[Steve Holden]

On Fri, Dec 15, 2017 at 9:47 PM, Guido van Rossum  wrote:

> ​[...]
>


> stays ordered across deletions" part of the ruling is true in CPython 3.6.
>
> I don't know what guidance to give Eric, because I don't know what other
> implementations do nor whether Eric cares about being compatible with
> those. IIUC micropython does not guarantee this currently, but I don't know
> if they claim Python 3.6 compatibility -- in fact I can't find any document
> that specifies the Python version they're compatible with more precisely
> than "Python 3".
>

​They currently specify 3.4+.

Specifically, https://github.com/micropython/micropython includes:

"""
MicroPython implements the entire Python 3.4 syntax (including exceptions,
with, yield from, etc., and additionally async/await keywords from Python
3.5). The following core datatypes are provided: str (including basic
Unicode support), bytes, bytearray, tuple, list, dict, set, frozenset,
array.array, collections.namedtuple, classes and instances. Builtin modules
include sys, time, and struct, etc. Select ports have support for
_thread module
(multithreading). *Note that only a subset of Python 3 functionality is
implemented for the data types and modules*.
"""

Note the emphasis I added on the last sentence.
___
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] Decision of having a deprecation period or not for changing csv.DictReader returning type.

[Guido van Rossum]

Let's not do this. Once it's documented as returning an OrderedDict there's
an additional promise about the API, e.g. move_to_end() exists.

On Sun, Dec 17, 2017 at 10:30 PM, 尚辉  wrote:

> Since regular dicts are ordered in 3.7, it might be cleaner to returning 
> regular dict instead of OrderedDict?
>
>


-- 
--Guido van Rossum (python.org/~guido)
___
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] Decision of having a deprecation period or not for changing csv.DictReader returning type.

[Steve Holden]

I submitted the 3.6 patch that Raymond committed. The purpose of the change
was to allow access to the ordering of the columns.

It doesn't use any of the OrderedDict-only methods, and I'd be very
surprised if a reversion to using dict in 3.7 would cause any tests to fail.

regards
 Steve

Steve Holden

On Mon, Dec 18, 2017 at 6:30 AM, 尚辉  wrote:

> Since regular dicts are ordered in 3.7, it might be cleaner to returning 
> regular dict instead of OrderedDict?
>
>
> ___
> 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/
> steve%40holdenweb.com
>
>
___
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] Broken svn lookup?

[Jonathan Goble]

On Mon, Dec 18, 2017 at 9:57 AM Victor Stinner 
wrote:

> Hi,
>
> I was looking at old issues. In
> https://bugs.python.org/issue8610#msg105805 I found the link:
>
>   http://svn.python.org/view?view=revision&revision=81190
>
> Sadly, the link fails with HTTP 404 Not Found :-(
>
> Is the service down? It's no more possible to browse the old
> Subversion repository?
>

I don't get a 404 response. I get a Firefox dialog box asking for my
username and password, and on clicking "Cancel", I then get an HTTP 401
Unauthorized response.
___
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 static typing still optional?

[Chris Barker]

Good Bad or Neutral, this discussion makes my point:

Using typing annotation as a necessary part of a standard library module is
injecting typing into "ordinary" python in a new way.

It is no longer going to appear to be completely optional, and only of
concern to those that choose to use it (and mypy or similar).

And I do think it is really bad UI to have something like:

@dataclass
class C:
a: Int = 1
b: float = 1.0


be the recommended (and shown in all the examples, and really be almost the
only way) to define a dataclass, when the type will in fact be completely
ignored by the implementation.

Newbies are going to be confused by this -- they really are.

Anyway, clearly I personally don't think this is a very good idea, but I
see that annotations are a natural and easy way to express the fields
without adding any new syntax.

But most importantly I don't think this should become standard without
consideration of the impact and a deliberate decision to do so.

A note: I don't know who everyone is that was engaged in the gitHub
discussion working out the details, but at least a few core folks are very
engaged in the introduction of type hinting to Python in general -- so I
think a certain perspective may have been over-represented.

Are there other options??

plain old:

@dataclass
class C:
a = 1
b = 1.0

would work, though then there would be no way to express fields without
defaults:

@dataclass
class C:
a = 1
b = None

almost -- but they is there "no default" or is the default None

Would it be impossible to use the annotation syntax, but with the type
optional:

@dataclass
class C:
a : = 1 # filed with default value
b : # field with no default

This is not legal python now, but are there barriers other than not wanting
to make yet more changes to it being legal (i.e. hard/impossible to
unambiguously parse, etc.

Maybe this can all be addresses by more "Untyped" examples  the docs.

-CHB















On Sun, Dec 17, 2017 at 8:54 AM, David Mertz  wrote:

> On Sun, Dec 17, 2017 at 8:22 AM, Guido van Rossum 
> wrote:
>
>> On Sun, Dec 17, 2017 at 2:11 AM, Julien Salort  wrote:
>>
>>> Naive question from a lurker: does it mean that it works also if one
>>> annotates with something that is not a type, e.g. a comment,
>>>
>>> @dataclass
>>> class C:
>>> a: "This represents the amplitude" = 0.0
>>> b: "This is an offset" = 0.0
>>
>>
>> I would personally not use the notation for this, but it is legal code.
>> However static type checkers like mypy won't be happy with this.
>>
>
> Mypy definitely won't like that use of annotation, but documentation
> systems might.  For example, in a hover tooltip in an IDE/editor, it's
> probably more helpful to see the descriptive message than "int" or "float"
> for the attribute.
>
> What about data that isn't built-in scalars? Does this look right to
> people (and will mypy be happy with it)?
>
> @dataclass
> class C:
> a:numpy.ndarray = numpy.random.random((3,3))
> b:MyCustomClass = MyCustomClass("foo", 37.2, 1+2j)
>
> I don't think those look terrible, but I think this looks better:
>
> @dataclass
> class C:
> a:Infer = np.random.random((3,3))
> b:Infer = MyCustomClass("foo", 37.2, 1+2j)
>
> Where the name 'Infer' (or some other spelling) was a name defined in the
> `dataclasses` module.  In this case, I don't want to use `typing.Any` since
> I really do want "the type of thing the default value has."
>
> --
> Keeping medicines from the bloodstreams of the sick; food
> from the bellies of the hungry; books from the hands of the
> uneducated; technology from the underdeveloped; and putting
> advocates of freedom in prisons.  Intellectual property is
> to the 21st century what the slave trade was to the 16th.
>
> ___
> 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/
> chris.barker%40noaa.gov
>
>


-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
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 static typing still optional?

[Ivan Levkivskyi]

@David
What you propose as `Infer` annotation was proposed some time ago (not only
for dataclasses, there are other use cases).
The discussion is here https://github.com/python/typing/issues/276

@Chris
People are still allowed not to use dataclasses if they really don't like
type hints :-)
Seriously however, annotations are just syntax. In this sense PEP 526 is
more like PEP 3107,
and less like PEP 484. People are still free to write:

@dataclass
class C:
x: "first coordinate"
y: "second coordinate"
plus: "I don't like types"

or

@dataclass
class C:
x: ...
y: ...

I don't see so big difference between hypothesis (testing lib) using
annotations for their purposes
from the situation with dataclasses. It is true that the syntax was chosen
to simplify
support in static type checkers (partially because users were often asking
for such feature),
but not more than this. If you don't use type checkers, there is no problem
in using one of the above forms.

If you have ideas about how to improve the dataclass docs, this can be
discussed in the issue https://bugs.python.org/issue32216

> ... the type will in fact be completely ignored by the implementation.
> Newbies are going to be confused by this -- they really are.

This is not different from

def f(x: int):
pass

f("What")  # OK

that exists starting from Python 3.0. Although I agree this is confusing,
the way forward could be just
explaining this better in the docs.

If you want my personal opinion about the current situation about type
hints _in general_, then I can say that
I have seen many cases where people use type hints where they are not needed
(for example in 10 line scripts or in highly polymorphic functions), so I
agree that some community
style guidance (like PEP 8) may be helpful. I had started such project an
the end of last year
(it was called pep-555, but I didn't have time to work on this and this
number is already taken).

--
Ivan
___
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 static typing still optional?

[Nick Coghlan]

On 19 Dec. 2017 7:00 am, "Chris Barker"  wrote:



Are there other options??

plain old:

@dataclass
class C:
a = 1
b = 1.0

would work, though then there would be no way to express fields without
defaults:


The PEP already supports using "a = field(); b = field()" (etc) to declare
untyped fields without a default value.

This annotation free spelling may not be clearly covered in the current
module docs, though.

Cheers,
Nick.
___
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 static typing still optional?

[Ivan Levkivskyi]

On 18 December 2017 at 20:38, Nick Coghlan  wrote:

>
> On 19 Dec. 2017 7:00 am, "Chris Barker"  wrote:
>
>
> Are there other options??
>
> plain old:
>
> @dataclass
> class C:
> a = 1
> b = 1.0
>
> would work, though then there would be no way to express fields without
> defaults:
>
>
> The PEP already supports using "a = field(); b = field()" (etc) to declare
> untyped fields without a default value.
>
>
The PEP is not 100% clear not this, but it is currently not the case and
this may be intentional (one obvious way to do it),
I just tried and this does not work:

@dataclass
class C:
x = field()

generates `__init__` etc. with no arguments. I think however that it is
better to generate an error than silently ignore it.
(Or if this a bug in the implementation, it should be just fixed.)

--
Ivan
___
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 static typing still optional?

[Eric V. Smith]

On 12/18/2017 2:55 PM, Ivan Levkivskyi wrote:
On 18 December 2017 at 20:38, Nick Coghlan > wrote:



On 19 Dec. 2017 7:00 am, "Chris Barker" mailto:chris.bar...@noaa.gov>> wrote:


Are there other options??

plain old:

@dataclass
class C:
     a = 1
     b = 1.0

would work, though then there would be no way to express fields
without defaults:


The PEP already supports using "a = field(); b = field()" (etc) to
declare untyped fields without a default value.


The PEP is not 100% clear not this, but it is currently not the case and 
this may be intentional (one obvious way to do it),

I just tried and this does not work:

@dataclass
class C:
     x = field()

generates `__init__` etc. with no arguments. I think however that it is 
better to generate an error than silently ignore it.

(Or if this a bug in the implementation, it should be just fixed.)


Hmm, not sure why that doesn't generate an error. I think it's a bug 
that should be fixed. Or, we could make the same change we're making in 
make_dataclass(), where we'll use "typing.Any" (as a string) if the type 
is omitted. See https://bugs.python.org/issue32278.


___
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 567 -- Context Variables

[Ivan Levkivskyi]

On 13 December 2017 at 22:35, Yury Selivanov 
wrote:

> [..]
> >> A new standard library module ``contextvars`` is added
> >
> > Why not add this to contextlib instead of adding a new module?  IIRC
> > this was discussed relative to PEP 550, but I don't remember the
> > reason.  Regardless, it would be worth mentioning somewhere in the
> > PEP.
> >
>
> The mechanism is generic and isn't directly related to context
> managers.  Context managers can (and in many cases should) use the new
> APIs to store global state, but the contextvars APIs do not depend on
> context managers or require them.
>
>
This was the main point of confusion for me when reading the PEP.
Concept of TLS is independent of context managers, but using word "context"
everywhere leads to doubts like "Am I getting everything right?" I think
just adding the
two quoted sentences will clarify the intent.

Otherwise the PEP is easy to read, the proposed API looks simple, and this
definitely will be a useful feature.

--
Ivan
___
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] Decision of having a deprecation period or not for changing csv.DictReader returning type.

[Brett Cannon]

On Mon, 18 Dec 2017 at 07:30 Steve Holden  wrote:

> I submitted the 3.6 patch that Raymond committed. The purpose of the
> change was to allow access to the ordering of the columns.
>
> It doesn't use any of the OrderedDict-only methods, and I'd be very
> surprised if a reversion to using dict in 3.7 would cause any tests to fail.
>

But as Guido pointed out, the expected interface of what gets returned
would be broken. I say just leave it as-is.

-Brett


>
> regards
>  Steve
>
> Steve Holden
>
> On Mon, Dec 18, 2017 at 6:30 AM, 尚辉  wrote:
>
>> Since regular dicts are ordered in 3.7, it might be cleaner to returning 
>> regular dict instead of OrderedDict?
>>
>>
>> ___
>> 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/steve%40holdenweb.com
>>
>>
> ___
> 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/brett%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/archive%40mail-archive.com

Re: [Python-Dev] Broken svn lookup?

[Benjamin Peterson]

I turned viewvc off a few months ago because subversion is highly
deprecated at this point. In fact, now that Windows build dependencies
have moved off, I’m probably going to shut it off for good soon.

On Mon, Dec 18, 2017, at 06:55, Victor Stinner wrote:
> Hi,
>
> I was looking at old issues. In
> https://bugs.python.org/issue8610#msg105805 I found the link:
>
>   http://svn.python.org/view?view=revision&revision=81190
>
> Sadly, the link fails with HTTP 404 Not Found :-(
>
> Is the service down? It's no more possible to browse the old
> Subversion repository?
>
> Victor

___
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] Broken svn lookup?

[Victor Stinner]

I don't need Subversion. I only need an online service redirecting me
to the change.

The bug tracker points to http://hg.python.org/lookup/r81190 which
redirects to http://svn.python.org/view?view=revision&revision=81190

In the master branch, there is the Misc/svnmap.txt file which maps
Subversion commits to Mercurial commits. Hum. Now we need Git commits
:-)

Well, it's not really a blocker issue. It would just be "nice to
have", but sadly I don't have the bandwidth to work on that :-(

Victor

2017-12-19 1:20 GMT+01:00 Benjamin Peterson :
> I turned viewvc off a few months ago because subversion is highly deprecated
> at this point. In fact, now that Windows build dependencies have moved off,
> I’m probably going to shut it off for good soon.
>
>
> On Mon, Dec 18, 2017, at 06:55, Victor Stinner wrote:
>> Hi,
>>
>> I was looking at old issues. In
>> https://bugs.python.org/issue8610#msg105805 I found the link:
>>
>>   http://svn.python.org/view?view=revision&revision=81190
>>
>> Sadly, the link fails with HTTP 404 Not Found :-(
>>
>> Is the service down? It's no more possible to browse the old
>> Subversion repository?
>>
>> Victor
>
___
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 567 -- Context Variables

[Yury Selivanov]

> 3. The connection pool has a queue, and creates a task for each connection to 
> serve requests from that queue. Naively, each task could inherit the context 
> of the request that caused it to be created, but the task would outlive the 
> request and go on to serve other requests. The connection pool would need to 
> specifically suppress the caller's context when creating its worker tasks.

I haven't used this pattern myself, but it looks like a good case for
adding a keyword-only 'context' rgument to `loop.create_task()`.  This
way the pool can capture the context when some API method is called
and pass it down to the queue along with the request.  The queue task
can then run connection code in that context.

Yury
___
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 567 -- Context Variables

[Yury Selivanov]

On Mon, Dec 18, 2017 at 6:00 PM, Ivan Levkivskyi  wrote:
> On 13 December 2017 at 22:35, Yury Selivanov 
> wrote:
>>
>> [..]
>> >> A new standard library module ``contextvars`` is added
>> >
>> > Why not add this to contextlib instead of adding a new module?  IIRC
>> > this was discussed relative to PEP 550, but I don't remember the
>> > reason.  Regardless, it would be worth mentioning somewhere in the
>> > PEP.
>> >
>>
>> The mechanism is generic and isn't directly related to context
>> managers.  Context managers can (and in many cases should) use the new
>> APIs to store global state, but the contextvars APIs do not depend on
>> context managers or require them.
>>
>
> This was the main point of confusion for me when reading the PEP.
> Concept of TLS is independent of context managers, but using word "context"
> everywhere leads to doubts like "Am I getting everything right?" I think
> just adding the
> two quoted sentences will clarify the intent.

I'll try to clarify this in the Abstract section.

>
> Otherwise the PEP is easy to read, the proposed API looks simple, and this
> definitely will be a useful feature.

Thanks, Ivan!

Yury
___
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 567 -- Context Variables

[Ben Darnell]

On Sun, Dec 17, 2017 at 2:49 PM Yury Selivanov 
wrote:

> > One caveat based on Tornado's experience with stack_context: There are
> times
> > when the automatic propagation of contexts won't do the right thing (for
> > example, a database client with a connection pool may end up hanging on
> to
> > the context from the request that created the connection instead of
> picking
> > up a new context for each query).
>
> I can see two scenarios that could lead to that:
>
> 1. The connection pool explicitly captures the context with
> 'get_context()' at
> the point where it was created. It later schedules all of its code within
> the
> captured context with Context.run().
>
> 2. The connection pool calls ContextVar.get() once and _caches_ it.
>
>

3. The connection pool has a queue, and creates a task for each connection
to serve requests from that queue. Naively, each task could inherit the
context of the request that caused it to be created, but the task would
outlive the request and go on to serve other requests. The connection pool
would need to specifically suppress the caller's context when creating its
worker tasks.

The situation was more complicated for Tornado since we were trying to
support callback-based workflows as well. Limiting this to coroutines
closes off a lot of the potential issues - most of the specific examples I
can think of would not be possible in a coroutine-only world.

-Ben
___
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?

[Chris Barker]

Now that dicts are order-preserving, maybe we should change prettyprint:

In [7]: d = {'one':1, 'two':2, 'three':3}

In [8]: print(d)
{'one': 1, 'two': 2, 'three': 3}

order preserved.

In [9]: pprint.pprint(d)
{'one': 1, 'three': 3, 'two': 2}

order not preserved ( sorted, I presume? )

With arbitrary order, it made sense to sort, so as to always give the same
"pretty" representation. But now that order is "part of" the dict itself,
it seems prettyprint should present the preserved order of the dict.

NOTE: I discovered this making examples for an intro to  Python class -- I
was updating the part where I teach that dicts do not preserve order. I was
using iPython, which, unbeknownst to me, was using pprint under the hood,
so got a different order depending on whether I simply displayed the dict
(which used pprint) or called str() or repr() on it. Pretty confusing.

Will changing pprint be considered a breaking change?

-Chris


-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
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 static typing still optional?

[Chris Barker]

I'm really surprised no one seems to get my point here.

TL;DR:
My point is that having type annotation syntax required for something in
the stdlib is a significant step toward "normalizing" type hinting in
Python. Whether that's a good idea or not is a judgement call, but it IS a
big step.


@Chris

> People are still allowed not to use dataclasses if they really don't like
> type hints :-)
> Seriously however, annotations are just syntax. In this sense PEP 526 is
> more like PEP 3107,
> and less like PEP 484. People are still free to write:
>
> @dataclass
> class C:
> x: "first coordinate"
> y: "second coordinate"
> plus: "I don't like types"
>

Well, yes, of course, but this is not like PEP 3107, as it introduces a
requirement for annotations (maybe not *type* annotations per se) in the
std lib. Again, that may be the best way to go -- but it should be done
deliberately.

@dataclass

> class C:
> x: ...
> y: ...
>

Ah! I had no idea you could use ellipses to indicate no type. That actually
helps a lot. We really should have that prominent in the docs. And in the
dataclass docs, not just the type hinting docs -- again, people will want
to use these that may not have any interest in nor prior knowledge of type
hints.



> I don't see so big difference between hypothesis (testing lib) using
> annotations for their purposes
> from the situation with dataclasses.
>

The big difference is that hypothesis is not in the standard library. Also,
I didn't know about hypothesis until just now, but their very first example
in the quick start does not use annotation syntax, so it's not as baked in
as it is with dataclasses.


> If you have ideas about how to improve the dataclass docs, this can be
> discussed in the issue https://bugs.python.org/issue32216
>

I'll try to find time to contribute there -- though maybe better to have
the doc draft in gitHub?

> ... the type will in fact be completely ignored by the implementation.
> > Newbies are going to be confused by this -- they really are.
>
> This is not different from
>
> def f(x: int):
> pass
>
> f("What")  # OK
>
> that exists starting from Python 3.0. Although I agree this is confusing,
> the way forward could be just explaining this better in the docs.
>

Again the difference is that EVERY introduction to defining python
functions doesn't use the type hint. And even more to the point, you CAN
define a function without any annotations.

But frankly, I think as type hinting becomes more common, we're going to
see a lot of confusion :-(

If you want my personal opinion about the current situation about type
> hints _in general_, then I can say that
> I have seen many cases where people use type hints where they are not
> needed
> (for example in 10 line scripts or in highly polymorphic functions), so I
> agree that some community
> style guidance (like PEP 8) may be helpful.
>

It's going to get worse before it gets better :-(

@dataclass
> class C:
>  x = field()


that does require that `field` be imported, so not as nice. I kinda like
the ellipses better.

but good to have a way.

-Chris


-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
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 static typing still optional?

[Barry Warsaw]

On Dec 18, 2017, at 21:41, Chris Barker  wrote:
> 
> TL;DR:
> My point is that having type annotation syntax required for something in the 
> stdlib is a significant step toward "normalizing" type hinting in Python. 
> Whether that's a good idea or not is a judgement call, but it IS a big step.

This is something we’re discussing for importlib.resources:

https://bugs.python.org/issue32248#msg308495

In the standalone version, we’re using annotations for the Python 3 bits.  It 
would make our lives easier if we kept them for the stdlib version (applying 
diffs and keeping them in sync would be easier).  Brett says in the follow up:

"As for the type hints, I thought it was lifted such that new code could 
include it but we wouldn't be taking PRs to add them to pre-existing code?”

So, what’s the deal?

-Barry



signature.asc
Description: Message signed with OpenPGP
___
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?

[Barry Warsaw]

On Dec 18, 2017, at 21:11, Chris Barker  wrote:

> Will changing pprint be considered a breaking change?

Yes, definitely.

-Barry



signature.asc
Description: Message signed with OpenPGP
___
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?

[Nathaniel Smith]

On Mon, Dec 18, 2017 at 7:02 PM, Barry Warsaw  wrote:
> On Dec 18, 2017, at 21:11, Chris Barker  wrote:
>
>> Will changing pprint be considered a breaking change?
>
> Yes, definitely.

Wait, what? Why would changing pprint (so that it accurately reflects
dict's new underlying semantics!) be a breaking change? Are you
suggesting it shouldn't be changed in 3.7?

-n

-- 
Nathaniel J. Smith -- https://vorpus.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/archive%40mail-archive.com

Re: [Python-Dev] PEP 567 -- Context Variables

[Ben Darnell]

On Mon, Dec 18, 2017 at 8:37 PM Yury Selivanov 
wrote:

> > 3. The connection pool has a queue, and creates a task for each
> connection to serve requests from that queue. Naively, each task could
> inherit the context of the request that caused it to be created, but the
> task would outlive the request and go on to serve other requests. The
> connection pool would need to specifically suppress the caller's context
> when creating its worker tasks.
>
> I haven't used this pattern myself, but it looks like a good case for
> adding a keyword-only 'context' rgument to `loop.create_task()`.  This
> way the pool can capture the context when some API method is called
> and pass it down to the queue along with the request.  The queue task
> can then run connection code in that context.
>
>
Yes, that would be useful.

-Ben
___
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?

[Steven D'Aprano]

On Mon, Dec 18, 2017 at 06:11:05PM -0800, Chris Barker wrote:

> Now that dicts are order-preserving, maybe we should change prettyprint:
> 
> In [7]: d = {'one':1, 'two':2, 'three':3}
> 
> In [8]: print(d)
> {'one': 1, 'two': 2, 'three': 3}
> 
> order preserved.
> 
> In [9]: pprint.pprint(d)
> {'one': 1, 'three': 3, 'two': 2}
> 
> order not preserved ( sorted, I presume? )

Indeed. pprint.PrettyPrinter has separate methods for OrderedDict and 
regular dicts, and the method for printing dicts calls sorted() while 
the other does not.


> With arbitrary order, it made sense to sort, so as to always give the same
> "pretty" representation. But now that order is "part of" the dict itself,
> it seems prettyprint should present the preserved order of the dict.

I disagree. Many uses of dicts are still conceptually unordered, even if 
the dict now preserves insertion order. For those use-cases, insertion 
order is of no interest whatsoever, and sorting is still "prettier".



-- 
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/archive%40mail-archive.com

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

[Steven D'Aprano]

On Mon, Dec 18, 2017 at 07:37:03PM -0800, Nathaniel Smith wrote:
> On Mon, Dec 18, 2017 at 7:02 PM, Barry Warsaw  wrote:
> > On Dec 18, 2017, at 21:11, Chris Barker  wrote:
> >
> >> Will changing pprint be considered a breaking change?
> >
> > Yes, definitely.
> 
> Wait, what? Why would changing pprint (so that it accurately reflects
> dict's new underlying semantics!) be a breaking change?

I have a script which today prints data like so:

{'Aaron': 62,
 'Anne': 51,
 'Bob': 23,
 'George': 30,
 'Karen': 45,
 'Sue': 17,
 'Sylvester': 34}

Tomorrow, it will suddenly start printing:

{'Bob': 23,
 'Karen': 45,
 'Sue': 17,
 'George': 30,
 'Aaron': 62,
 'Anne': 51,
 'Sylvester': 34}


and my users will yell at me that my script is broken because the data 
is now in random order. Now, maybe that's my own damn fault for using 
pprint instead of writing my own pretty printer... but surely the point 
of pprint is so I don't have to write my own?

Besides, the docs say very prominently:

"Dictionaries are sorted by key before the display is computed."

https://docs.python.org/3/library/pprint.html

so I think I can be excused having relied on that feature.



-- 
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/archive%40mail-archive.com

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

[Chris Barker]

On Mon, Dec 18, 2017 at 7:41 PM, Steven D'Aprano 
wrote:

> > With arbitrary order, it made sense to sort, so as to always give the
> same
> > "pretty" representation. But now that order is "part of" the dict itself,
> > it seems prettyprint should present the preserved order of the dict.
>
> I disagree. Many uses of dicts are still conceptually unordered, even if
> the dict now preserves insertion order. For those use-cases, insertion
> order is of no interest whatsoever, and sorting is still "prettier".
>

and many uses of dicts have "sorted" order as completely irrelevant, and
sorting them arbitrarily is not necessarily pretty (you can't provide a
sort key can you? -- so yes, it's arbitrary)

I'm not necessarily saying we should break things, but I won't agree that
pprint sorting dicts is the "right" interface for what is actually an
order-preserving mapping.

I would think it was only the right choice in the first place in order (get
it?) to get a consistent representation, not because sorting was a good
thing per se.

-Chris

-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
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?

[Nathaniel Smith]

On Mon, Dec 18, 2017 at 7:58 PM, Steven D'Aprano  wrote:
> On Mon, Dec 18, 2017 at 07:37:03PM -0800, Nathaniel Smith wrote:
>> On Mon, Dec 18, 2017 at 7:02 PM, Barry Warsaw  wrote:
>> > On Dec 18, 2017, at 21:11, Chris Barker  wrote:
>> >
>> >> Will changing pprint be considered a breaking change?
>> >
>> > Yes, definitely.
>>
>> Wait, what? Why would changing pprint (so that it accurately reflects
>> dict's new underlying semantics!) be a breaking change?
>
> I have a script which today prints data like so:
>
> {'Aaron': 62,
>  'Anne': 51,
>  'Bob': 23,
>  'George': 30,
>  'Karen': 45,
>  'Sue': 17,
>  'Sylvester': 34}
>
> Tomorrow, it will suddenly start printing:
>
> {'Bob': 23,
>  'Karen': 45,
>  'Sue': 17,
>  'George': 30,
>  'Aaron': 62,
>  'Anne': 51,
>  'Sylvester': 34}
>
>
> and my users will yell at me that my script is broken because the data
> is now in random order.

To make sure I understand, do you actually have a script like this, or
is this hypothetical?

> Now, maybe that's my own damn fault for using
> pprint instead of writing my own pretty printer... but surely the point
> of pprint is so I don't have to write my own?
>
> Besides, the docs say very prominently:
>
> "Dictionaries are sorted by key before the display is computed."
>
> https://docs.python.org/3/library/pprint.html
>
> so I think I can be excused having relied on that feature.

No need to get aggro -- I asked a question, it wasn't a personal attack.

At a high-level, pprint's job is to "pretty-print arbitray Python data
structures in a form which can be used as input to the interpreter"
(quoting the first sentence of its documentation), i.e., like repr()
it's fundamentally intended as a debugging tool that's supposed to
match how Python works, not any particular externally imposed output
format. Now, how Python works has changed. Previously dict order was
arbitrary, so picking the arbitrary order that happened to be sorted
was a nice convenience. Now, dict order isn't arbitrary, and sorting
dicts both obscures the actual structure of the Python objects, and
also breaks round-tripping through pprint. Given that pprint's
overarching documented contract of "represent Python objects" now
conflicts with the more-specific documented contract of "sort dict
keys", something has to give.

My feeling is that we should preserve the overarching contract, not
the details of how dicts were handled. Here's another example of a
teacher struggling with this:
https://mastodon.social/@aparrish/13011522

But I would be in favor of adding a kwarg to let people opt-in to the
old behavior like:

from pprint import PrettyPrinter
pprint = PrettyPrinter(sortdict=True).pprint

-n

-- 
Nathaniel J. Smith -- https://vorpus.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/archive%40mail-archive.com

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

[Steven D'Aprano]

On Mon, Dec 18, 2017 at 08:28:52PM -0800, Chris Barker wrote:
> On Mon, Dec 18, 2017 at 7:41 PM, Steven D'Aprano 
> wrote:
> 
> > > With arbitrary order, it made sense to sort, so as to always give the
> > same
> > > "pretty" representation. But now that order is "part of" the dict itself,
> > > it seems prettyprint should present the preserved order of the dict.
> >
> > I disagree. Many uses of dicts are still conceptually unordered, even if
> > the dict now preserves insertion order. For those use-cases, insertion
> > order is of no interest whatsoever, and sorting is still "prettier".
> >
> 
> and many uses of dicts have "sorted" order as completely irrelevant, and
> sorting them arbitrarily is not necessarily pretty (you can't provide a
> sort key can you? -- so yes, it's arbitrary)

I completely agree. We might argue that it was a mistake to sort dicts 
in the first place, or at least a mistake to *always* sort them without 
allowing the caller to provide a sort key. But what's done is done: the 
fact that dicts are sorted by pprint is not merely an implementation 
detail, but a documented behaviour.


> I'm not necessarily saying we should break things, but I won't agree that
> pprint sorting dicts is the "right" interface for what is actually an
> order-preserving mapping.

If sorting dicts was the "right" behaviour in Python 3.4, it remains the 
right behaviour -- at least for use-cases that don't care about 
insertion order. Anyone using pprint on dicts *now* doesn't care about 
insertion order. If they did, they would be using OrderedDict.

That will change in the future, but even in the future there are lots of 
use-cases for dicts where insertion order might as well be random. The 
order that some dict happen to be constructed may not be "pretty" or 
significant or even consistent from one dict to the next.

(If your key/values pairs are coming in from an external source, they 
might not always come in the same order.)

I'm not denying that sometimes it would be nice to see dicts in 
insertion order. Right now, those use-cases are handled by OrderedDict 
but in the future many of them will be taken over by regular dicts. So 
we have a conflict:

- for some use-cases, insertion order is the "right" way for pprint
  to display the dict;

- but for others, sorting by keys is the "pretty" way for pprint to
  display the dict;

- and there's no way for pprint to know which is which just by 
  inspecting the dict.

How to break this tie? Backwards compatibility trumps all. If we want 
to change the default behaviour of pprint, we need to go through a 
deprecation period.

Or add a flag sorted=True, and let the caller decide.


> I would think it was only the right choice in the first place in order (get
> it?) to get a consistent representation, not because sorting was a good
> thing per se.

*shrug* That's arguable. As you said yourself, dicts were sorted by key 
to give a "pretty" representation. I'm not so sure that consistency is 
the justification. What does that even mean? If you print the same dict 
twice, with no modifications, it will print the same whether you sort 
first or not. If you print two different dicts, who is to say that they 
were constructed in the same order?

But the point is moot: whatever the justification, the fact that pprint 
sorts dicts by key is the defined behaviour, and even if it was a 
mistake to guarantee it, we can't just change it without a deprecation 
period.


-- 
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/archive%40mail-archive.com

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

[Chris Angelico]

On Tue, Dec 19, 2017 at 6:09 PM, Steven D'Aprano  wrote:
> I completely agree. We might argue that it was a mistake to sort dicts
> in the first place, or at least a mistake to *always* sort them without
> allowing the caller to provide a sort key. But what's done is done: the
> fact that dicts are sorted by pprint is not merely an implementation
> detail, but a documented behaviour.

Personally, I think it's a good default behaviour. Frequently you have
a dictionary that, in normal code, you look up by key rather than
iterating over; but for debugging, you print out everything. (Example:
HTTP request/response headers. In your code, you'll query the headers
dict for "content-type", but it's nice to be able to say "show me
every header".) Insertion order is meaningless, and it's nice to be
able to read them in some kind of sane order. Simply sorting the keys
in the default way is good enough for a LOT of use-cases.

> I'm not denying that sometimes it would be nice to see dicts in
> insertion order. Right now, those use-cases are handled by OrderedDict
> but in the future many of them will be taken over by regular dicts. So
> we have a conflict:
>
> - for some use-cases, insertion order is the "right" way for pprint
>   to display the dict;
>
> - but for others, sorting by keys is the "pretty" way for pprint to
>   display the dict;
>
> - and there's no way for pprint to know which is which just by
>   inspecting the dict.
>
> How to break this tie? Backwards compatibility trumps all. If we want
> to change the default behaviour of pprint, we need to go through a
> deprecation period.
>
> Or add a flag sorted=True, and let the caller decide.

Agreed, except for the last bit. I'd be inclined to kill two birds
with one stone: add a flag sort_key=DEFAULT or sort_key=IDENTITY,
which will sort the keys by themselves; you can provide a key function
to change the way they're sorted, or you can pass sort_key=None to get
them in insertion order.

>> I would think it was only the right choice in the first place in order (get
>> it?) to get a consistent representation, not because sorting was a good
>> thing per se.
>
> *shrug* That's arguable. As you said yourself, dicts were sorted by key
> to give a "pretty" representation. I'm not so sure that consistency is
> the justification. What does that even mean? If you print the same dict
> twice, with no modifications, it will print the same whether you sort
> first or not. If you print two different dicts, who is to say that they
> were constructed in the same order?

In old versions of Python, this code would always produce the same result:

d = {}
d["qwer"] = 1
d["asdf"] = 2
d["zxcv"] = 3
print(d)
import pprint; pprint.pprint(d)

Then along came hash randomization, and the output would change - but
pprint would still be consistent and tidy. Now we have insertion order
retained, and both the repr and the pprint are consistent. Both of
them are sane. They're just different sameness.

> But the point is moot: whatever the justification, the fact that pprint
> sorts dicts by key is the defined behaviour, and even if it was a
> mistake to guarantee it, we can't just change it without a deprecation
> period.

This is really the clincher. But IMO the current behaviour isn't
*just* for backcompat; it's good, useful behaviour as it is. I
wouldn't want to see it changed even _with_ deprecation.

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/archive%40mail-archive.com

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

[Steve Dower]

On 18Dec2017 2309, Steven D'Aprano wrote:
> [A LOT OF THINGS I AGREE WITH]
I agree completely with Steven's reasoning here, and it bothers me that
what is an irrelevant change to many users (dict becoming ordered) seems
to imply that all users of dict have to be updated.

I have never needed OrderedDict before, and dict now also being ordered
doesn't mean that when I reach for it I'm doing it because I need an
ordered dict - I probably just need a regular dict. *Nothing* about dict
should change for me between versions.

Adding an option to pprint to explicitly control sorting without
changing the default is fine. Please stop assuming that everyone wants
an OrderedDict when they say dict. It's an invalid assumption.

Cheers,
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/archive%40mail-archive.com

Re: [Python-Dev] Is static typing still optional?

[Eric V. Smith]

On 12/18/2017 9:41 PM, Chris Barker wrote:

I'm really surprised no one seems to get my point here.

TL;DR:
My point is that having type annotation syntax required for something in 
the stdlib is a significant step toward "normalizing" type hinting in 
Python. Whether that's a good idea or not is a judgement call, but it IS 
a big step.


I get your point, I'm just not concerned about it.

I also don't think it's surprising that you can put misleading 
information (including non-types) in type annotations. All of the 
documentation and discussions are quite clear that type information is 
ignored at runtime.


It _is_ true that @dataclass does actually inspect the type at runtime, 
but those uses are very rare. And if you do need them, the actual type T 
used by ClassVar[T] and InitVar[T] are still ignored.


Data Classes is also not the first use of type annotations in the stdlib:
https://docs.python.org/3/library/typing.html#typing.NamedTuple

When I say that "typing is optional", I mean importing the typing 
module, not that annotations are optional.


Eric.


@Chris

People are still allowed not to use dataclasses if they really don't
like type hints :-)
Seriously however, annotations are just syntax. In this sense PEP
526 is more like PEP 3107,
and less like PEP 484. People are still free to write:

@dataclass
class C:
     x: "first coordinate"
     y: "second coordinate"
     plus: "I don't like types"


Well, yes, of course, but this is not like PEP 3107, as it introduces a 
requirement for annotations (maybe not *type* annotations per se) in the 
std lib. Again, that may be the best way to go -- but it should be done 
deliberately.


@dataclass

class C:
     x: ...
     y: ...


Ah! I had no idea you could use ellipses to indicate no type. That 
actually helps a lot. We really should have that prominent in the docs. 
And in the dataclass docs, not just the type hinting docs -- again, 
people will want to use these that may not have any interest in nor 
prior knowledge of type hints.


I don't see so big difference between hypothesis (testing lib) using
annotations for their purposes
from the situation with dataclasses.


The big difference is that hypothesis is not in the standard library. 
Also, I didn't know about hypothesis until just now, but their very 
first example in the quick start does not use annotation syntax, so it's 
not as baked in as it is with dataclasses.


If you have ideas about how to improve the dataclass docs, this can
be discussed in the issue https://bugs.python.org/issue32216



I'll try to find time to contribute there -- though maybe better to have 
the doc draft in gitHub?


 > ... the type will in fact be completely ignored by the
implementation.
> Newbies are going to be confused by this -- they really are.

This is not different from

def f(x: int):
     pass

f("What")  # OK

that exists starting from Python 3.0. Although I agree this is
confusing, the way forward could be just explaining this better in
the docs.


Again the difference is that EVERY introduction to defining python 
functions doesn't use the type hint. And even more to the point, you CAN 
define a function without any annotations.


But frankly, I think as type hinting becomes more common, we're going to 
see a lot of confusion :-(


If you want my personal opinion about the current situation about
type hints _in general_, then I can say that
I have seen many cases where people use type hints where they are
not needed
(for example in 10 line scripts or in highly polymorphic functions),
so I agree that some community
style guidance (like PEP 8) may be helpful. 



It's going to get worse before it gets better :-(

@dataclass
class C:
  x = field()


that does require that `field` be imported, so not as nice. I kinda like 
the ellipses better.


but good to have a way.

-Chris


--

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

chris.bar...@noaa.gov 


___
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/eric%2Ba-python-dev%40trueblade.com



___
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?

[Eric V. Smith]

On 12/19/2017 2:38 AM, Steve Dower wrote:

On 18Dec2017 2309, Steven D'Aprano wrote:

[A LOT OF THINGS I AGREE WITH]

I agree completely with Steven's reasoning here, and it bothers me that
what is an irrelevant change to many users (dict becoming ordered) seems
to imply that all users of dict have to be updated.

I have never needed OrderedDict before, and dict now also being ordered
doesn't mean that when I reach for it I'm doing it because I need an
ordered dict - I probably just need a regular dict. *Nothing* about dict
should change for me between versions.

Adding an option to pprint to explicitly control sorting without
changing the default is fine. Please stop assuming that everyone wants
an OrderedDict when they say dict. It's an invalid assumption.


Well said, Steve and Steven. I completely agree.

Eric.

___
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