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

2017-12-22 Thread Eric Fahlgren
On Thu, Dec 21, 2017 at 7:51 PM, Stephen J. Turnbull <
turnbull.stephen...@u.tsukuba.ac.jp> wrote:

> I understand the motivation to guarantee order, but it's a programmer
> convenience that has nothing to do with the idea of mapping, and the
> particular (insertion) order is very special and usually neither
> relevant nor reproducible.  I have no problem whatsoever with just
> documenting any failure to preserve order while reproducing dicts,
> *except* that a process that inserts keys in the same order had better
> result in the same insertion order.
>

​json, pickle == png, i.e., guaranteed lossless.
repr, pprint == jpg, lossy for very specific motivating reasons.​

In particular, I use pprint output in regression baselines, and if the long
documented sort-by-key behavior changed, I would not be happy.
___
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] Summary of Python tracker Issues

2017-12-22 Thread Python tracker

ACTIVITY SUMMARY (2017-12-15 - 2017-12-22)
Python tracker at https://bugs.python.org/

To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.

Issues counts and deltas:
  open6342 (+12)
  closed 37819 (+64)
  total  44161 (+76)

Open issues with patches: 2456 


Issues opened (52)
==

#30697: segfault in PyErr_NormalizeException() after memory exhaustion
https://bugs.python.org/issue30697  reopened by brett.cannon

#32335: Failed Python build on Fedora 27
https://bugs.python.org/issue32335  opened by amitg-b14

#32336: Save OrderedDict import in argparse
https://bugs.python.org/issue32336  opened by rhettinger

#32337: Dict order is now guaranteed, so add tests and doc for it
https://bugs.python.org/issue32337  opened by rhettinger

#32338: Save OrderedDict import in re
https://bugs.python.org/issue32338  opened by serhiy.storchaka

#32339: Make the dict type used in csv.DictReader configurable
https://bugs.python.org/issue32339  opened by serhiy.storchaka

#32343: Leak Sanitizer reports memory leaks while building using ASAN
https://bugs.python.org/issue32343  opened by kirit1193

#32345: EIO from write() is only fatal if print() contains a newline
https://bugs.python.org/issue32345  opened by Creideiki

#32346: Speed up slot lookup for class creation
https://bugs.python.org/issue32346  opened by pitrou

#32347: System Integrity Protection breaks shutil.copystat()
https://bugs.python.org/issue32347  opened by Ryan Govostes

#32352: `inspect.getfullargspec` doesn't work fine for some builtin ca
https://bugs.python.org/issue32352  opened by thautwarm

#32353: Add docs about Embedding with an frozen module limitation.
https://bugs.python.org/issue32353  opened by Decorater

#32354: Unclear intention of deprecating Py_UNICODE_TOLOWER / Py_UNICO
https://bugs.python.org/issue32354  opened by ideasman42

#32358: json.dump: fp must be a text file object
https://bugs.python.org/issue32358  opened by qingyunha

#32359: Add getters for all SSLContext internal configuration
https://bugs.python.org/issue32359  opened by njs

#32360: Save OrderedDict imports in various stdlibs.
https://bugs.python.org/issue32360  opened by inada.naoki

#32361: global / nonlocal interference : is this a bug, a feature or a
https://bugs.python.org/issue32361  opened by Camion

#32362: multiprocessing.connection.Connection misdocumented as multipr
https://bugs.python.org/issue32362  opened by Amery

#32363: Deprecate task.set_result() and task.set_exception()
https://bugs.python.org/issue32363  opened by asvetlov

#32364: Add AbstractFuture and AbstractTask
https://bugs.python.org/issue32364  opened by asvetlov

#32367: [Security] CVE-2017-17522: webbrowser.py in Python does not va
https://bugs.python.org/issue32367  opened by vstinner

#32368: Segfault when compiling many conditional expressions
https://bugs.python.org/issue32368  opened by snordhausen

#32370: Wrong ANSI encoding used by subprocess for some locales
https://bugs.python.org/issue32370  opened by Segev Finer

#32371: Delay-loading of python dll is impossible when using some C ma
https://bugs.python.org/issue32371  opened by Pierre Chatelier

#32372: Optimize out __debug__ at the AST level
https://bugs.python.org/issue32372  opened by serhiy.storchaka

#32373: Add socket.getblocking() method
https://bugs.python.org/issue32373  opened by yselivanov

#32374: Document that m_traverse for multi-phase initialized modules c
https://bugs.python.org/issue32374  opened by encukou

#32375: Compilation warnings in getpath.c with gcc on Ubuntu / -D_FORT
https://bugs.python.org/issue32375  opened by pitrou

#32378: test_npn_protocols broken with LibreSSL 2.6.1+
https://bugs.python.org/issue32378  opened by christian.heimes

#32380: functools.singledispatch interacts poorly with methods
https://bugs.python.org/issue32380  opened by Ethan Smith

#32381: Python 3.6 cannot reopen .pyc file with non-ASCII path
https://bugs.python.org/issue32381  opened by tianjg

#32384: Generator tests is broken in non-CPython implementation
https://bugs.python.org/issue32384  opened by isaiahp

#32387: Disallow untagged C extension import on major platforms
https://bugs.python.org/issue32387  opened by pitrou

#32388: Remove cross-version binary compatibility
https://bugs.python.org/issue32388  opened by pitrou

#32390: AIX (xlc_r) compile error with Modules/posixmodule.c: Function
https://bugs.python.org/issue32390  opened by Michael.Felt

#32391: Add StreamWriter.wait_closed()
https://bugs.python.org/issue32391  opened by asvetlov

#32392: subprocess.run documentation does not have **kwargs
https://bugs.python.org/issue32392  opened by oprypin

#32393: nav menu jitter in old documentation
https://bugs.python.org/issue32393  opened by Joseph Hendrey

#32394: socket lib beahavior change in 3.6.4
https://bugs.python.org/issue32394  opened by skn78

#32395: asyncio.StreamReader.readuntil is not general enough
https://bugs.python.org/issu

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

2017-12-22 Thread Brett Cannon
On Thu, Dec 21, 2017, 03:37 Ivan Levkivskyi,  wrote:

> On 21 December 2017 at 11:22, Terry Reedy  wrote:
>
>> On 12/21/2017 4:22 AM, Eric V. Smith wrote:
>>
>>> On 12/21/2017 1:46 AM, Chris Barker wrote:
>>>
>>
>> I suggest that it be clear in the docs, and ideally in the PEP, that the
 dataclass decorator is using the *annotation" syntax, and that the the only
 relevant part it uses is that an annotation exists, but the value of the
 annotation is essentially (completely?) ignored.

>>>
>>> I think the PEP is very clear about this: "The dataclass decorator
>>> examines the class to find fields. A field is defined as any variable
>>> identified in __annotations__. That is, a variable that has a type
>>> annotation. With two exceptions described below, none of the Data Class
>>> machinery examines the type specified in the annotation."
>>>
>>
>> This seems clear enough.  It could come after describing what a dataclass
>> *is*.
>>
>> I agree the docs should also be clear about this.
>>>
>>
>>
>> So we should have examples like:

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

 Then maybe:

 @dataclass
 class C:
  a: "the a parameter" # field with no default
  b: "another, different parameter" = 0.0 # field with a default

 Then the docs can go to say that if the user wants to specify a type
 for use with a static type checking pre-processor, they can do it like so:

 @dataclass
 class C:
  a: int # integer field with no default
  b: float = 0.0 # float field with a default

 And the types will be recognized by type checkers such as mypy.

 And I think the non-typed examples should go first in the docs.

>>>
>> Module some bike-shedding, the above seems pretty good to me.
>>
>
> For me, the three options for "don't care" have a bit different meaning:
>
> * typing.Any: this class is supposed to be used with static type checkers,
> but this field is too dynamic
> * ... (ellipsis): this class may or may not be used with static type
> checkers, use the inferred type in the latter case
> * "field docstring": this class should not be used with static type
> checkers
>
> Assuming this, the second option would be the "real" "don't care". If this
> makes sense,
> then we can go the way proposed in
> https://github.com/python/typing/issues/276 and make ellipsis semantics
> "official" in PEP 484.
> (pending Guido's approval)
>

I vote for option 2 as well.

I  think it's worth reminding people that if they don't like the fact
dataclasses (ab)use type hints for their succinct syntax that you can
always use attrs instead to avoid type hints. Otherwise whichever approach
we agree to from Ivan's suggestions will take care of this.

As for those who feel dataclasses will force them to teach type hints and
they simply don't want to, maybe we could help land protocols and then
maybe you can use dataclasses as an opportunity to explicitly teach duck
typing?

But I think the key point I want to make is Guido chose dataclasses to
support using the type hints syntax specifically over how attrs does
things, so I don't see this thread trying to work around that going
anywhere at this point since I haven't seen a solid alternative be proposed
after all of this debating.

-brett


> --
> 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/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] Is static typing still optional?

2017-12-22 Thread Stephan Hoyer
On Thu, Dec 21, 2017 at 6:39 AM Ivan Levkivskyi 
wrote:

> For me, the three options for "don't care" have a bit different meaning:
>
> * typing.Any: this class is supposed to be used with static type checkers,
> but this field is too dynamic
> * ... (ellipsis): this class may or may not be used with static type
> checkers, use the inferred type in the latter case
> * "field docstring": this class should not be used with static type
> checkers
>
> Assuming this, the second option would be the "real" "don't care". If this
> makes sense,
> then we can go the way proposed in
> https://github.com/python/typing/issues/276 and make ellipsis semantics
> "official" in PEP 484.
> (pending Guido's approval)
>

I am a little nervous about using "..." for inferred types, because it
could potentially cause confusion with other uses of ellipsis in typing.

Ellipsis already has a special meaning for Tuple, so an annotation like
MyClass[int, ...] could mean either a tuple subclass with integer elements
or a two argument generic type where the second type is inferred. Actually,
it's ambiguous even for Tuple.

Ellipsis could also make a lot of sense for typing multi-dimensional arrays
similar to how it's used in indexing to denote "any number of dimensions."
Again, the semantics for "..." might defer from "an inferred size."

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

2017-12-22 Thread Chris Barker
On Fri, Dec 22, 2017 at 8:49 AM, Brett Cannon  wrote:

> I  think it's worth reminding people that if they don't like the fact
>> dataclasses (ab)use type hints for their succinct syntax that you can
>> always use attrs instead to avoid type hints.
>>
>
sure -- but this doesn't really address the issue, the whole reason this is
even a discussion is because dataclasses is going into the standard
library. Third party packages can do whatever they want, of course.

And the concern is that people (in particular newbies) will get confused /
the wrong impression / other-negative-response by the (semi) use of typing
in a standard library module.


> As for those who feel dataclasses will force them to teach type hints and
> they simply don't want to, maybe we could help land protocols
>

Could you please clarify what this is about ???


> But I think the key point I want to make is Guido chose dataclasses to
> support using the type hints syntax specifically over how attrs does
> things, so I don't see this thread trying to work around that going
> anywhere at this point since I haven't seen a solid alternative be proposed
> after all of this debating.
>

And the PEP has been approved.

So the actionable things are:

Writing good docs

Converging on a "recommended" way to do non-typed dataclass fields.

And that should be decided in order to write the docs, (and probably should
be in the PEP).

-CHB


-- 

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?

2017-12-22 Thread Gregory P. Smith
On Fri, Dec 22, 2017 at 11:40 AM Chris Barker  wrote:

> On Fri, Dec 22, 2017 at 8:49 AM, Brett Cannon 
>
But I think the key point I want to make is Guido chose dataclasses to
>> support using the type hints syntax specifically over how attrs does
>> things, so I don't see this thread trying to work around that going
>> anywhere at this point since I haven't seen a solid alternative be proposed
>> after all of this debating.
>>
>
> And the PEP has been approved.
>
> So the actionable things are:
>
> Writing good docs
>
> Converging on a "recommended" way to do non-typed dataclass fields.
>

My preference for this is "just use Any" for anyone not concerned about the
type.  But if we wanted to make it more opaque so that people need not
realizing that they are actually type annotations, I suggest adding an
alias for Any in the dataclasses module (dataclasses.Data = typing.Any)

from dataclasses import dataclass, Data

@dataclass
class Swallow:
weight_in_oz: Data = 5
laden: Data = False
species: Data = SwallowSpecies.AFRICAN

the word "Data" is friendlier than "Any" in this context for people who
don't need to care about the typing module.

We could go further and have Data not be an alias for Any if desired (so
that its repr wouldn't be confusing, not that anyone should be looking at
its repr ever).

-gps


>
> And that should be decided in order to write the docs, (and probably
> should be in the PEP).
>
> -CHB
>
>
> --
>
> 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/greg%40krypto.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-0557 dataclasses top level module vs part of collections?

2017-12-22 Thread Gregory P. Smith
On Thu, Dec 21, 2017 at 10:47 PM Raymond Hettinger <
raymond.hettin...@gmail.com> wrote:

>
>
> > On Dec 21, 2017, at 3:21 PM, Gregory P. Smith  wrote:
> >
> > It seems a suggested use is "from dataclasses import dataclass"
> >
> > But people are already familiar with "from collections import
> namedtuple" which suggests to me that "from collections import dataclass"
> would be a more natural sounding API addition.
>
> This might make sense if it were a single self contained function.  But
> dataclasses are their own little ecosystem that warrants its own module
> namespace:
>
> >>> import dataclasses
> >>> dataclasses.__all__
> ['dataclass', 'field', 'FrozenInstanceError', 'InitVar', 'fields',
> 'asdict', 'astuple', 'make_dataclass', 'replace']
>
> Also, remember that dataclasses have a dual role as a data holder (which
> is collection-like) and as a generator of boilerplate code (which is more
> like functools.total_ordering).
>
> I support Eric's decision to make this a separate module.
>

sounds good.  lets leave it that way.  dataclasses it is.

if we were further along in figuring out how to remove the distinction
between a class and a module as a namespace I'd suggest the module name
itself be dataclass with a __call__ method so that the module could be the
decorator so we could avoid the antipattern of importing a name from a
module into your local namespace.   but we're not, so we can't. :)

-gps

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

2017-12-22 Thread Brett Cannon
On Fri, Dec 22, 2017, 11:38 Chris Barker,  wrote:

> On Fri, Dec 22, 2017 at 8:49 AM, Brett Cannon  wrote:
>
>> I  think it's worth reminding people that if they don't like the fact
>>> dataclasses (ab)use type hints for their succinct syntax that you can
>>> always use attrs instead to avoid type hints.
>>>
>>
> sure -- but this doesn't really address the issue, the whole reason this
> is even a discussion is because dataclasses is going into the standard
> library. Third party packages can do whatever they want, of course.
>
> And the concern is that people (in particular newbies) will get confused /
> the wrong impression / other-negative-response by the (semi) use of typing
> in a standard library module.
>

I'm still not worried. Type hints are part of the syntax and so are no
worse off than async/await and asyncio IMO.


>
>> As for those who feel dataclasses will force them to teach type hints and
>> they simply don't want to, maybe we could help land protocols
>>
>
> Could you please clarify what this is about ???
>

There's a PEP by Ivan (on my phone else I would look up the number).

-Brett


>
>> But I think the key point I want to make is Guido chose dataclasses to
>> support using the type hints syntax specifically over how attrs does
>> things, so I don't see this thread trying to work around that going
>> anywhere at this point since I haven't seen a solid alternative be proposed
>> after all of this debating.
>>
>
> And the PEP has been approved.
>
> So the actionable things are:
>
> Writing good docs
>
> Converging on a "recommended" way to do non-typed dataclass fields.
>
> And that should be decided in order to write the docs, (and probably
> should be in the PEP).
>
> -CHB
>
>
> --
>
> 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?

2017-12-22 Thread Paul Moore
On 22 December 2017 at 19:50, Gregory P. Smith  wrote:

> My preference for this is "just use Any" for anyone not concerned about the
> type.  But if we wanted to make it more opaque so that people need not
> realizing that they are actually type annotations, I suggest adding an alias
> for Any in the dataclasses module (dataclasses.Data = typing.Any)
>
> from dataclasses import dataclass, Data
>
> @dataclass
> class Swallow:
> weight_in_oz: Data = 5
> laden: Data = False
> species: Data = SwallowSpecies.AFRICAN
>
> the word "Data" is friendlier than "Any" in this context for people who
> don't need to care about the typing module.
>
> We could go further and have Data not be an alias for Any if desired (so
> that its repr wouldn't be confusing, not that anyone should be looking at
> its repr ever).

That sounds like a nice simple proposal. +1 from me.

Documentation can say that variables should be annotated with "Data"
to be recognised by the decorator, and if people are using type
annotations an actual type can be used in place of "Data" (which acts
the same as typing.Any. That seems to me to describe the feature in a
suitably type-hinting-neutral way, while still making it clear how
data classes interact with type annotations.

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

2017-12-22 Thread Chris Barker
On Fri, Dec 22, 2017 at 10:10 AM, Stephan Hoyer  wrote:

> On Thu, Dec 21, 2017 at 6:39 AM Ivan Levkivskyi 
> wrote:
>
>>

> * ... (ellipsis): this class may or may not be used with static type
>> checkers, use the inferred type in the latter case
>>
>

> * "field docstring": this class should not be used with static type
>> checkers
>>
>> Assuming this, the second option would be the "real" "don't care". If
>> this makes sense,
>> then we can go the way proposed in https://github.com/python/
>> typing/issues/276 and make ellipsis semantics "official" in PEP 484.
>> (pending Guido's approval)
>>
>
> I am a little nervous about using "..." for inferred types, because it
> could potentially cause confusion with other uses of ellipsis in typing.
>

Isn't that what "make ellipsis semantics "official"" means -- i.e. making
it clear how they are used in typing?

The core problem is that generic annotations are used in dataclasses
without the "type hints" use-case. But:

1) Python is moving to make (PEP 484) type hints be THE recommended usage
for annotations

2) We want the annotations in dataclasses to be "proper" PEP 484 type hints
if they are there.

The challenge is:

- Annotations require a value.
- Any value used might be interpreted by a static type checker.

So we need a way to spell "no type specified" that will not be
mis-interpreted by type checkers, and is in the built in namespace, and
will seem natural to users with no knowledge or interest in static typing.

The ellipses is tempting, because it's a literal that doesn't have any
other obvious meaning in this context. Bu tif it has an incompatible
meaning in PEP 484, then we're stuck.

Is there another Obscure literal that would work?

 - I assume None means "the None type" to type checkers, yes?

 - empty string is one option -- or more to the point, any string -- so
then it could be used as docs as well.

- Is there another Obscure literal that would work? (or not so obscure one
that doesn't have another meaning to type checkers)

Would it be crazy to bring typing.Any into the builtin namespace?

@dataclass:
a: Any
b: Any = 34
c: int = 0

That reads pretty well to me

And having Any available in the built in namespace may help in other cases
where type hints are getting introduced into code that isn't really being
properly type checked.

I don't LOVE it -- to me, Any means "any type will do", or "I don't care
what type this is" and what we really want is "no type specified" -- i.e.
the same thing as plain old Python code without type hints. But practically
speaking, it has the same effect, yes?

-CHB




-- 

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?

2017-12-22 Thread David Mertz
There name Data seems very intuitive to me without suggesting type
declaration as Any does (but it can still be treated as a synonym by actual
type checkers)

On Dec 22, 2017 12:12 PM, "Paul Moore"  wrote:

> On 22 December 2017 at 19:50, Gregory P. Smith  wrote:
>
> > My preference for this is "just use Any" for anyone not concerned about
> the
> > type.  But if we wanted to make it more opaque so that people need not
> > realizing that they are actually type annotations, I suggest adding an
> alias
> > for Any in the dataclasses module (dataclasses.Data = typing.Any)
> >
> > from dataclasses import dataclass, Data
> >
> > @dataclass
> > class Swallow:
> > weight_in_oz: Data = 5
> > laden: Data = False
> > species: Data = SwallowSpecies.AFRICAN
> >
> > the word "Data" is friendlier than "Any" in this context for people who
> > don't need to care about the typing module.
> >
> > We could go further and have Data not be an alias for Any if desired (so
> > that its repr wouldn't be confusing, not that anyone should be looking at
> > its repr ever).
>
> That sounds like a nice simple proposal. +1 from me.
>
> Documentation can say that variables should be annotated with "Data"
> to be recognised by the decorator, and if people are using type
> annotations an actual type can be used in place of "Data" (which acts
> the same as typing.Any. That seems to me to describe the feature in a
> suitably type-hinting-neutral way, while still making it clear how
> data classes interact with type annotations.
>
> Paul
> ___
> 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/
> mertz%40gnosis.cx
>
___
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?

2017-12-22 Thread Mike Miller


On 2017-12-22 12:15, Chris Barker wrote:

Would it be crazy to bring typing.Any into the builtin namespace?

@dataclass:
     a: Any
     b: Any = 34
     c: int = 0

That reads pretty well to me

> And having Any available in the built in namespace may help in other cases 
where

There is already an "any" function in the builtins.  It looks fine but not sure 
how it will interact with type checkers.


The "dataclass.Data" idea mentioned in a sibling thread is good alternative, 
though just wordy enough to make ... a shortcut.


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

2017-12-22 Thread MRAB

On 2017-12-22 21:02, Mike Miller wrote:


On 2017-12-22 12:15, Chris Barker wrote:

Would it be crazy to bring typing.Any into the builtin namespace?

@dataclass:
     a: Any
     b: Any = 34
     c: int = 0

That reads pretty well to me

  > And having Any available in the built in namespace may help in other cases 
where

There is already an "any" function in the builtins.  It looks fine but not sure
how it will interact with type checkers.

The "dataclass.Data" idea mentioned in a sibling thread is good alternative,
though just wordy enough to make ... a shortcut.

The function is "any", the type is "Any", and "any" != "Any", although I 
wonder how many people will be caught out by that...

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

2017-12-22 Thread Chris Barker
On Fri, Dec 22, 2017 at 1:18 PM, MRAB  wrote:

>
>> The function is "any", the type is "Any", and "any" != "Any", although I
> wonder how many people will be caught out by that...


enough that it's a bad idea

oh well.

-CHB




> ___
> 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] Guarantee ordered dict literals in v3.7?

2017-12-22 Thread Guido van Rossum
Let's not change pprint.

On Fri, Dec 22, 2017 at 7:44 AM, Eric Fahlgren 
wrote:

> On Thu, Dec 21, 2017 at 7:51 PM, Stephen J. Turnbull <
> turnbull.stephen...@u.tsukuba.ac.jp> wrote:
>
>> I understand the motivation to guarantee order, but it's a programmer
>> convenience that has nothing to do with the idea of mapping, and the
>> particular (insertion) order is very special and usually neither
>> relevant nor reproducible.  I have no problem whatsoever with just
>> documenting any failure to preserve order while reproducing dicts,
>> *except* that a process that inserts keys in the same order had better
>> result in the same insertion order.
>>
>
> ​json, pickle == png, i.e., guaranteed lossless.
> repr, pprint == jpg, lossy for very specific motivating reasons.​
>
> In particular, I use pprint output in regression baselines, and if the
> long documented sort-by-key behavior changed, I would not be happy.
>
> ___
> 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
>
>


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