Re: [Python-Dev] Third and hopefully final post: PEP 557, Data Classes

2017-12-01 Thread Eric V. Smith 

On 11/30/2017 3:35 PM, Carl Meyer wrote:

On 11/29/2017 05:02 PM, Guido van Rossum wrote:

I tried to look up the discussion but didn't find much except that you
flagged this as an issue. To repeat, your concern is that isdataclass()
applies to *instances*, not classes, which is how Eric has designed it,
but you worry that either through the name or just because people don't
read the docs it will be confusing. What do you suppose we do? I think
making it work for classes as well as for instances would cause another
category of bugs (confusion between cases where a class is needed vs. an
instance abound in other situations -- we don't want to add to that).
Maybe it should raise TypeError when passed a class (unless its
metaclass is a dataclass)? Maybe it should be renamed to
isdataclassinstance()? That's a mouthful, but I don't know how common
the need to call this is, and people who call it a lot can define their
own shorter alias.


Yeah, I didn't propose a specific fix because I think there are several
options (all mentioned in this thread already), and I don't really have
strong feelings about them:

1) Keep the existing function and name, let it handle either classes or
instances. I agree that this is probably not the best option available,
though IMO it's still marginally better than the status quo).

2) Punt the problem by removing the function; don't add it to the public
API at all until we have demonstrated demand.

3) Rename it to "is_dataclass_instance" (and maybe also keep a separate
"is_dataclass" for testing classes directly). (Then there's also the
choice about raising TypeError vs just returning False if a function is
given the wrong type; I think TypeError is better.)


In that case, you can spell "is_dataclass_instance":

def isdataclass_instance(obj):
dataclasses.fields(obj)  # raises TypeError for non-dataclass
 # classes or instances
if not isinstance(obj, type):
raise TypeError('not an instance')
return True

Since this is easy enough to do in your own code, and I still don't see 
a use case, I'll just add a note to the PEP and omit delete isdataclass().


Plus, you can decide for yourself how to deal with the question of 
returning true for classes or instances or both.


Eric.
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] What's the status of PEP 505: None-aware operators?

2017-12-01 Thread Steven D'Aprano 
On Thu, Nov 30, 2017 at 11:54:39PM -0500, Random832 wrote:

> The OP isn't confusing anything; it's Eric who is confused. The quoted
> paragraph of the PEP clearly and unambiguously claims that the sequence
> is "arguments -> function -> call", meaning that something happens after
> the "function" stage [i.e. a None check] cannot short-circuit the
> "arguments" stage. But in fact the sequence is "function -> arguments ->
> call".

I'm more confused than ever. You seem to be arguing that Python 
functions CAN short-circuit their arguments and avoid evaluating them. 
Is that the case?

If not, then I fail to see the difference between 

"arguments -> function -> call"

"function -> arguments -> call"

In *both cases* the arguments are fully evaluated before the function is 
called, and so there is nothing the function can do to delay evaluating 
its arguments.

If this is merely about when the name "function" is looked up, then I 
don't see why that's relevant to the PEP.

What am I missing?


-- 
Steve
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] What's the status of PEP 505: None-aware operators?

2017-12-01 Thread Steve Holden 
On Fri, Dec 1, 2017 at 10:31 AM, Steven D'Aprano 
wrote:

> On Thu, Nov 30, 2017 at 11:54:39PM -0500, Random832 wrote:
>
> > The OP isn't confusing anything; it's Eric who is confused. The quoted
> > paragraph of the PEP clearly and unambiguously claims that the sequence
> > is "arguments -> function -> call", meaning that something happens after
> > the "function" stage [i.e. a None check] cannot short-circuit the
> > "arguments" stage. But in fact the sequence is "function -> arguments ->
> > call".
>
> I'm more confused than ever. You seem to be arguing that Python
> functions CAN short-circuit their arguments and avoid evaluating them.
> Is that the case?
>
> If not, then I fail to see the difference between
>
> "arguments -> function -> call"
>
> "function -> arguments -> call"
>
> In *both cases* the arguments are fully evaluated before the function is
> called, and so there is nothing the function can do to delay evaluating
> its arguments.
>
> If this is merely about when the name "function" is looked up, then I
> don't see why that's relevant to the PEP.
>
> What am I missing?
>
> ​I guess it's possible that if computing the function (i.e., evaluating
the expression immediately to the left of the argument list) and/or the
argument has side effects​

​then the evaluation order will affect the outcome. Intuitively it seems
more straightforward to compute the function first. If this expression were
to raise an exception, of course, then the arguments would not then be
evaluated. Or vice versa. It would be best of the specification matches
current CPython bahviour.
​
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] What's the status of PEP 505: None-aware operators?

2017-12-01 Thread Random832 
On Fri, Dec 1, 2017, at 05:31, Steven D'Aprano wrote:
> I'm more confused than ever. You seem to be arguing that Python 
> functions CAN short-circuit their arguments and avoid evaluating them. 
> Is that the case?

> If this is merely about when the name "function" is looked up, then I 
> don't see why that's relevant to the PEP.
> 
> What am I missing?

You're completely missing the context of the discussion, which was the
supposed reason that a *new* function call operator, with the proposed
syntax function?(args), that would short-circuit (based on the
'function' being None) could not be implemented. The whole thing doesn't
make sense to me anyway, since a new operator could have its own
sequence different from the existing one if necessary.
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Third and hopefully final post: PEP 557, Data Classes

2017-12-01 Thread Eric V. Smith 
Since this is easy enough to do in your own code, and I still don't see 
a use case, I'll just add a note to the PEP and delete isdataclass().


Plus, you can decide for yourself how to deal with the question of 
returning true for classes or instances or both.


I've updated the PEP and reposted it. The only change is removing 
isdataclass().


Eric.
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] What's the status of PEP 505: None-aware operators?

2017-12-01 Thread Andrea Griffini 
The PEP says that a None-aware function call operator (e.g. "f?(x, y)")
would break the rule of python that arguments are evaluated before the
function but this is not correct.

In Python the function is evaluated before the arguments (but of course the
CALL is made after the evaluation of the arguments).

A None-aware function call operator ?(...) wouldn't break this order of
evaluation rule: 1) evaluate the function, 2) only if it's not None
evaluate arguments and make the call.
In bytecode the None-aware function call would simply require a extra
"JNONE" to the end...

...  evaluate the function ...
JNONE  skip
... evaluate arguments ...
CALL n
skip:

Note that I'm not saying this would be a good thing, just that the reason
the PEP uses to dismiss this option is actually wrong because Python
doesn't work the way the PEP says it does.

Andrea

On Fri, Dec 1, 2017 at 11:31 AM, Steven D'Aprano 
wrote:

> On Thu, Nov 30, 2017 at 11:54:39PM -0500, Random832 wrote:
>
> > The OP isn't confusing anything; it's Eric who is confused. The quoted
> > paragraph of the PEP clearly and unambiguously claims that the sequence
> > is "arguments -> function -> call", meaning that something happens after
> > the "function" stage [i.e. a None check] cannot short-circuit the
> > "arguments" stage. But in fact the sequence is "function -> arguments ->
> > call".
>
> I'm more confused than ever. You seem to be arguing that Python
> functions CAN short-circuit their arguments and avoid evaluating them.
> Is that the case?
>
> If not, then I fail to see the difference between
>
> "arguments -> function -> call"
>
> "function -> arguments -> call"
>
> In *both cases* the arguments are fully evaluated before the function is
> called, and so there is nothing the function can do to delay evaluating
> its arguments.
>
> If this is merely about when the name "function" is looked up, then I
> don't see why that's relevant to the PEP.
>
> What am I missing?
>
>
> --
> Steve
> ___
> Python-Dev mailing list
> [email protected]
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/
> agriff%40tin.it
>
___
Python-Dev mailing list
[email protected]
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-01 Thread Python tracker 

ACTIVITY SUMMARY (2017-11-24 - 2017-12-01)
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:
  open6281 (+14)
  closed 37665 (+55)
  total  43946 (+69)

Open issues with patches: 2414 


Issues opened (42)
==

#26856: android does not have pwd.getpwall()
https://bugs.python.org/issue26856  reopened by xdegaye

#30487: DOC: automatically create a venv and install Sphinx when runni
https://bugs.python.org/issue30487  reopened by ned.deily

#30657: [security] CVE-2017-1000158: Unsafe arithmetic in PyString_Dec
https://bugs.python.org/issue30657  reopened by vstinner

#32128: test_nntplib: test_article_head_body() fails in SSL mode
https://bugs.python.org/issue32128  opened by vstinner

#32129: Icon on macOS
https://bugs.python.org/issue32129  opened by wordtech

#32130: xml.sax parser validation sometimes fails when obtaining DTDs 
https://bugs.python.org/issue32130  opened by failys

#32131: Missing encoding parameter in urllib/parse.py
https://bugs.python.org/issue32131  opened by jmbc

#32133: documentation: numbers module nitpick
https://bugs.python.org/issue32133  opened by abcdef

#32137: Stack overflow in repr of deeply nested dicts
https://bugs.python.org/issue32137  opened by serhiy.storchaka

#32140: IDLE debugger fails with non-trivial __new__ super call
https://bugs.python.org/issue32140  opened by Camion

#32141: configure with Spaces in Directory Name on macOS
https://bugs.python.org/issue32141  opened by philthompson10

#32142: heapq.heappop - documentation misleading or doesn't work
https://bugs.python.org/issue32142  opened by scooter4j

#32143: os.statvfs lacks f_fsid
https://bugs.python.org/issue32143  opened by gscrivano

#32145: Wrong ExitStack Callback recipe
https://bugs.python.org/issue32145  opened by Denaun

#32146: multiprocessing freeze_support needed outside win32
https://bugs.python.org/issue32146  opened by dancol

#32147: improve performance of binascii.unhexlify() by using conversio
https://bugs.python.org/issue32147  opened by sir-sigurd

#32152: Add pid to .cover filename in lib/trace.py
https://bugs.python.org/issue32152  opened by nikhilh

#32153: mock.create_autospec fails if an attribute is a partial functi
https://bugs.python.org/issue32153  opened by cbelu

#32156: Fix flake8 warning F401: ... imported but unused
https://bugs.python.org/issue32156  opened by vstinner

#32160: lzma documentation: example to XZ compress file on disk
https://bugs.python.org/issue32160  opened by dhimmel

#32162: typing.Generic breaks __init_subclass__
https://bugs.python.org/issue32162  opened by Ilya.Kulakov

#32165: PyEval_InitThreads is called before Py_Initialize in LoadPytho
https://bugs.python.org/issue32165  opened by mrkn

#32170: Contrary to documentation, ZipFile.extract does not extract ti
https://bugs.python.org/issue32170  opened by Malcolm Smith

#32173: linecache.py add lazycache to __all__ and use dict.clear to cl
https://bugs.python.org/issue32173  opened by ganziqim

#32174: nonASCII punctuation characters can not display in python363.c
https://bugs.python.org/issue32174  opened by zaazbb

#32175: Add hash auto-randomization
https://bugs.python.org/issue32175  opened by bjarvis

#32176: Zero argument super is broken in 3.6 for methods with a hacked
https://bugs.python.org/issue32176  opened by bup

#32177: spammers mine emails from bugs.python.org
https://bugs.python.org/issue32177  opened by joern

#32178: Some invalid email address groups cause an IndexError instead 
https://bugs.python.org/issue32178  opened by mtorromeo

#32179: Empty email address in headers triggers an IndexError
https://bugs.python.org/issue32179  opened by mtorromeo

#32180: bool() vs len() > 0 on lists
https://bugs.python.org/issue32180  opened by dilyan.palauzov

#32181: runaway Tasks with Task.cancel() ignored.
https://bugs.python.org/issue32181  opened by Oleg K2

#32182: Infinite recursion in email.message.as_string()
https://bugs.python.org/issue32182  opened by Silla Rizzoli

#32183: Coverity: CID 1423264:  Insecure data handling  (TAINTED_SCALA
https://bugs.python.org/issue32183  opened by vstinner

#32185: SSLContext.wrap_socket sends SNI Extension when server_hostnam
https://bugs.python.org/issue32185  opened by nitzmahone

#32186: io.FileIO hang all threads if fstat blocks on inaccessible NFS
https://bugs.python.org/issue32186  opened by nirs

#32188: ImpImporter.find_modules removes symlinks in paths
https://bugs.python.org/issue32188  opened by Henk-Jaap Wagenaar

#32189: SyntaxError for yield expressions inside comprehensions & gene
https://bugs.python.org/issue32189  opened by ncoghlan

#32190: Separate out legacy introspection APIs in the inspect docs
https://bugs.python.org/issue32190  opened by ncoghlan

#32192: Provide importlib.util.lazy_import helper function
https://bugs.python.org/issue32192  opened by ncoghlan

#32193: Convert

Re: [Python-Dev] iso8601 parsing

2017-12-01 Thread Chris Barker 
On Wed, Nov 29, 2017 at 4:19 PM, Paul G  wrote:

> I can write at least a pure Python implementation in the next few days, if
> not a full C implementation. Shouldn'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 <
> [email protected]> 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: > 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.
>>
>


-- 

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

[email protected]
___
Python-Dev mailing list
[email protected]
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

2017-12-01 Thread 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  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 <
>> [email protected]> 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: >> 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
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] What's the status of PEP 505: None-aware operators?

2017-12-01 Thread Eric Fahlgren 
On Fri, Dec 1, 2017 at 5:24 AM, Random832  wrote:

> You're completely missing the context of the discussion, which was the
> supposed reason that a *new* function call operator, with the proposed
> syntax function?(args), that would short-circuit (based on the
> 'function' being None) could not be implemented. The whole thing doesn't
> make sense to me anyway, since a new operator could have its own
> sequence different from the existing one if necessary.
>

​Right, I was clearly misinterpreting the wording in the PEP.  It's a bit
ambiguous and should probably make explicit that "evaluate the function"
isn't just the common vernacular for "call the function".
___
Python-Dev mailing list
[email protected]
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

2017-12-01 Thread Alexander Belopolsky 
> is there a strict deadline here if we want this for Python 3.7?

The deadline for the new features is the date of the first beta currently
scheduled for 2018-01-29, but if you can get this in before the last alpha
(2018-01-08) it will be best.

See PEP 537 (https://www.python.org/dev/peps/pep-0537) for details and
updates.
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] What's the status of PEP 505: None-aware operators?

2017-12-01 Thread MRAB 

On 2017-12-01 13:24, Random832 wrote:

On Fri, Dec 1, 2017, at 05:31, Steven D'Aprano wrote:
I'm more confused than ever. You seem to be arguing that Python 
functions CAN short-circuit their arguments and avoid evaluating them. 
Is that the case?


If this is merely about when the name "function" is looked up, then I 
don't see why that's relevant to the PEP.


What am I missing?


You're completely missing the context of the discussion, which was the
supposed reason that a *new* function call operator, with the proposed
syntax function?(args), that would short-circuit (based on the
'function' being None) could not be implemented. The whole thing doesn't
make sense to me anyway, since a new operator could have its own
sequence different from the existing one if necessary.


The code:

function?(args)

would be equivalent to:

None if function is None else function(args)

where 'function' would be evaluated once.

If function is None, the arguments would not be evaluated.
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Third and hopefully final post: PEP 557, Data Classes

2017-12-01 Thread Eric V. Smith 
See https://github.com/ericvsmith/dataclasses/issues/104 for a 
discussion on making order=False the default. This matches regular 
classes in Python 3, which cannot be ordered.


Eric.
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] What's the status of PEP 505: None-aware operators?

2017-12-01 Thread Steven D'Aprano 
On Fri, Dec 01, 2017 at 08:24:05AM -0500, Random832 wrote:
> On Fri, Dec 1, 2017, at 05:31, Steven D'Aprano wrote:
> > I'm more confused than ever. You seem to be arguing that Python 
> > functions CAN short-circuit their arguments and avoid evaluating them. 
> > Is that the case?
> 
> > If this is merely about when the name "function" is looked up, then I 
> > don't see why that's relevant to the PEP.
> > 
> > What am I missing?
> 
> You're completely missing the context of the discussion,

Yes I am. That's why I asked.

> which was the
> supposed reason that a *new* function call operator, with the proposed
> syntax function?(args), that would short-circuit (based on the
> 'function' being None) could not be implemented.

Given that neither your post (which I replied to) nor the post you were 
replying to mentioned anything about function?() syntax, perhaps I might 
be forgiven for having no idea what you were talking about?

The PEP only mentions function?() as a rejected idea, do I don't know 
why we're even talking about it. The PEP is deferred, with considerable 
opposition and luke-warm support, even the PEP author has said he's not 
going to push for it, and we're arguing about a pedantic point related 
to a part of the PEP which is rejected...

:-)



-- 
Steve
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com