On Sun, Nov 12, 2017 at 2:39 PM, Greg Ewing
wrote:
> Guido van Rossum wrote:
>
>> The PEP answers that clearly (under Implementation):
>>
>> > If an annotation was already a string, this string is preserved
>> > verbatim.
>>
>
> This bothers me,
mypy.
>
> --
> 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/
> guido%40pyt
f PEP 562 is much simpler. With the Zen
of Python in mind, this gives a hint that it is the better idea, and
possibly even a good idea.
Ivan, once you've added the __dir__ thing to your PEP, please post it to
python-dev to solicit review from its (larger) readership.
--
--Guido van Rossum (
On Mon, Nov 13, 2017 at 3:50 PM, Sebastian Rittau
wrote:
> Am 14.11.2017 um 00:29 schrieb Guido van Rossum:
>
>> This is a nice piece of work. I expect to accept it pretty much verbatim
>> (with some small edits, see https://github.com/python/peps/pull/467). I
>> agree
27;__getattr__'](name)
> else:
> raise AttributeError
>
> I'm wondering if the __set_name__ mechanism can be extended to modules.
> What if call the __set_name__() method for all items in a module dict after
> finishing importing the module?
>
>
&
;s only one module (the one containing the
__getattr__ function). Plus we already have a 1-argument module-level
__getattr__ in mypy. See PEP 484.
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.pyth
oad what looks like the complete
c061457_ISO_IEC_TR_24772_2013.pdf (336 pages) after clicking on an "I
accept" button (I didn't read what I accepted :-). The $200 is for the
printed copy I presume.
--
--Guido van Rossum (python.org/~guido)
___
On Wed, Nov 15, 2017 at 6:50 PM, Guido van Rossum wrote:
> On Wed, Nov 15, 2017 at 6:37 PM, Armin Rigo wrote:
>
>> Hi,
>>
>> On 14 November 2017 at 14:55, Jan Claeys wrote:
>> > Sounds like https://www.iso.org/standard/71094.html
>> > which is updati
Python 3.2, but the oldest Python 3 version that's still supported is
3.4, so we're safe generating callable().
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/m
object type).
>>
>
> Not quite, ModuleType overrides object.__getattribute__ in order to
> provide a better error message. So with your suggestion, the change would
> be to *not* override object.__getattribute__ and provide the above
> ModuleType.__getattr__
>
> Cheers,
> Mark.
>
> ___
> 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
:
> > getter = mod.__dict__["__getattr__"]
>
> A minor point: this should(?) be written in terms of the public
> interface for accessing namespaces, namely:
>
> getter = vars(mod)["__getattr__"]
>
Should it? The PEP is not
rite it in
terms of __dict__.
On Sun, Nov 19, 2017 at 6:34 PM, Steven D'Aprano
wrote:
> On Sun, Nov 19, 2017 at 05:34:35PM -0800, Guido van Rossum wrote:
> > On Sun, Nov 19, 2017 at 4:57 PM, Steven D'Aprano
> > wrote:
>
> > > A minor point: this should(?) be wri
> > 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/
> lukasz%40langa.pl
>
>
> ___
Yeah, I don't think there's an action item here except *maybe* changes to
the wording of the PEP. Ivan?
On Mon, Nov 20, 2017 at 12:33 AM, Serhiy Storchaka
wrote:
> 20.11.17 03:02, Guido van Rossum пише:
>
>> Serhiy's definition sounds recursive (defining __getattr__ t
ituations where a
>>> class is expected,
>>> and IMO it is clear that all that are not mentioned in the PEP stay
>>> unchanged.
>>>
>>
>> Indeed, but you do mention issubclass in the PEP. I think a few extra
>> words of explanation would be h
Wow, 44 messages in 4 hours. That must be some kind of record.
If/when there's an action item, can someone summarize for me?
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/ma
On Wed, Nov 22, 2017 at 10:54 AM, Jelle Zijlstra
wrote:
>
>
> 2017-11-22 9:58 GMT-08:00 Guido van Rossum :
>
>> Wow, 44 messages in 4 hours. That must be some kind of record.
>>
>> If/when there's an action item, can someone summarize for me?
>>
>&g
g this two options it looks like me and Serhiy like the first
> one, Paul is undecided (), and Antoine is in favor of option 2.
>
While that may be the right thing to do, it's a silent change in semantics,
which I find pretty disturbing -- how would people debug such a failure?
That's why I
On Wed, Nov 22, 2017 at 11:12 AM, Ivan Levkivskyi
wrote:
> On 22 November 2017 at 20:05, Guido van Rossum wrote:
>
>> On Wed, Nov 22, 2017 at 10:54 AM, Jelle Zijlstra <
>> jelle.zijls...@gmail.com> wrote
>>
>>> 2017-11-22 9:58 GMT-08:00 Guido van R
s a totally logical explanation for that, I still don't like
it, and I think yield in a comprehension should be banned. From this it
follows that we should also simply ban yield from comprehensions.
--
--Guido van Rossum (python.org/~guido)
___
On Thu, Nov 23, 2017 at 9:06 AM, Serhiy Storchaka
wrote:
> 23.11.17 18:08, Guido van Rossum пише:
>
>> This thread is still going over the speed limit. Don't commit anything
>> without my explicit approval.
>>
>
> I'm not going to write a single line of co
The more I hear about this topic, the more I think that `await`, `yield`
and `yield from` should all be banned from occurring in all comprehensions
and generator expressions. That's not much different from disallowing
`return` or `break`.
--
--Guido van Rossum (python.org/~
On Fri, Nov 24, 2017 at 4:22 PM, Guido van Rossum wrote:
> The more I hear about this topic, the more I think that `await`, `yield`
> and `yield from` should all be banned from occurring in all comprehensions
> and generator expressions. That's not much different from disallowing
On Sat, Nov 25, 2017 at 6:55 AM, Ivan Levkivskyi
wrote:
> On 25 November 2017 at 04:30, Guido van Rossum wrote:
>
>> On Fri, Nov 24, 2017 at 4:22 PM, Guido van Rossum
>> wrote:
>>
>>> The more I hear about this topic, the more I think that `await`, `yield`
&
On Sat, Nov 25, 2017 at 8:07 AM, Ivan Levkivskyi
wrote:
> On 25 November 2017 at 16:57, Guido van Rossum wrote:
>
>> On Sat, Nov 25, 2017 at 6:55 AM, Ivan Levkivskyi
>> wrote:
>>
>>> On 25 November 2017 at 04:30, Guido van Rossum wrote:
>>>
>&
>
> On Sat, Nov 25, 2017 at 12:17 PM Brett Cannon wrote:
>
On Fri, Nov 24, 2017, 19:32 Guido van Rossum, wrote:
>>
>>> On Fri, Nov 24, 2017 at 4:22 PM, Guido van Rossum
>>> wrote:
>>>
>>>> The more I hear about this topic, the more I think
I think the proposal is reasonable and won't require a PEP.
On Nov 25, 2017 3:25 PM, "Terry Reedy" wrote:
> On 11/25/2017 1:55 AM, David Cuthbert wrote:
>
>> First time contributing back -- if I should be filing a PEP or something
>> like that for this, please let me know.
>>
>
> I don't think a
t deprecation or even just
> immediate SyntaxError in 3.7.
>
Maybe the rest of the discussion should be about deprecation vs.
SyntaxError in Python 3.7.
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https
ell whether comprehensions
> have an implicit function scope or not should be banned.
>
That's not an unreasonable position, and one that would leave a door open
to a general design for inner scopes that are not implemented using
functions or code objects (something to ponder for 3.8 perha
On Sat, Nov 25, 2017 at 4:57 PM, Nick Coghlan wrote:
> On 26 November 2017 at 02:59, Guido van Rossum wrote:
> >
> > I'd be happy to stop with the conclusion that we're going to rip out some
> > confusing syntax rather than trying to generate code for it -- IM
On Sun, Nov 26, 2017 at 12:29 PM, Nathaniel Smith wrote:
> On Sat, Nov 25, 2017 at 3:37 PM, Guido van Rossum
> wrote:
> > On Sat, Nov 25, 2017 at 1:05 PM, David Mertz wrote:
> >>
> >> FWIW, on a side point. I use 'yield' and 'yield from' ALL T
permissive structure-based
>> matching, that's one of the features that collections.namedtuple
>> offers that data classes don't.
>>
>
> And in this case you could also do:
> astuple(point) == astuple(vector)
>
Didn't we at one point h
Sounds good.
On Nov 27, 2017 8:00 AM, "Eric V. Smith" wrote:
> On 11/27/17 10:51 AM, Guido van Rossum wrote:
>
>> Following up on this subthread (inline below).
>>
>> On Mon, Nov 27, 2017 at 2:56 AM, Eric V. Smith > <mailto:e...@trueblade.com>>
heir own conventions. At least asyncio has an API that allows
overriding the factory for Futures, so if someone comes up with a Future
that is interoperable between asyncio and curio, for example, it might be
possible. But likely curio would have to be modified somewhat too.
--
--Guido van Rossum
his way (in fact I
think most parsers can and probably should be written this way). But I've
got a huge list of things to do already... :-(
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.py
I need to cut this debate short (too much to do already) but I'd like to
press that I wish async/await to be available for general tinkering (like
writing elegant parsers), not just for full fledged event loops.
--
--Guido van Rossum (python.org/~
On Mon, Nov 27, 2017 at 1:58 PM, Greg Ewing
wrote:
> Guido van Rossum wrote:
>
>> The source for sleep() isn't very helpful -- e.g. @coroutine is mostly a
>> backwards compatibility thing.
>>
>
> So how are you supposed to write that *without* using @corou
to show more of the warnings that
> are
> off by default in regular interpeter builds:
> https://bugs.python.org/issue32088
>
>
> References
> ==
>
> .. [1] stdlib-sig thread proposing the original default filter change
>(https://mail.python.org/pipermail/stdlib-sig/2009-November/000789.html
> )
>
> .. [2] Python 2.7 notification of the default warnings filter change
>(https://docs.python.org/3/whatsnew/2.7.html#changes-to-
> the-handling-of-deprecation-warnings)
>
> .. [3] Emitting warnings based on the location of the warning itself
>(https://pypi.org/project/warn/)
>
> .. [4] GitHub PR for PEP 565 implementation
>(https://github.com/python/cpython/pull/4458)
>
> .. [5] Tracker issue for PEP 565 implementation
>(https://bugs.python.org/issue31975)
>
> .. [6] python-dev discussion thread for this PEP
>(https://mail.python.org/pipermail/python-dev/2017-November/150477.html
> )
>
>
> Copyright
> =
>
> This document has been placed in the public domain.
>
> --
> Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
> ___
> 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
I would also be happy with a retreat, where we define `__eq__` to insist
that the classes are the same, and people can override this to their
hearts' content.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/pytho
November 2017 at 09:52, Guido van Rossum wrote:
> > I am basically in agreement with this now. Some remarks:
>
> I've pushed an update which should address most of these, as well as
> Serhiy's comment about the existing FutureWarning use case:
> https://github.co
> >>> re.sub(r'(\W+|(?<=-))', r':', 'Self-Defence Class')
> 'Self:Defence:Class'
>
> As re.split() it never matches the empty string adjacent to the previous
> match. re.findall() and re.finditer() only don't match the empty st
.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/
On Tue, Nov 28, 2017 at 12:56 PM, Eric V. Smith wrote:
> On 11/28/2017 1:57 PM, Guido van Rossum wrote:
>
>> I would also be happy with a retreat, where we define `__eq__` to insist
>> that the classes are the same, and people can override this to their
>> hearts' c
t;
>> [snip]
> After some thought, I've decided that if this happens in the re module in
> Python 3.7, then, for the sake of compatibility (and because the edge cases
> are debatable anyway), I'll have the regex module do the same when used on
> Python 3.7.
>
Maybe i
the screams die down. I'm pretty sure we'll be
> changing our policy at some point, possibly to always use
> FutureWarning for everything.
Can one of you check that the latest version of PEP 565 gets this right?
--
--Guido van Rossum (python.org/~guido)
___
don't know
> that similar file existed.
>
> ___
> 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/guid
Hm. For the file used for lookup, I see the point of keeping it. But in
general, I don't see the point of keeping files we no longer need -- that's
what VCS systems are for!
On Wed, Nov 29, 2017 at 2:28 PM, Serhiy Storchaka
wrote:
> 29.11.17 21:00, Guido van Rossum пише:
>
>
I plan to accept this on Monday if no new objections are raised.
On Nov 29, 2017 3:28 PM, "Eric V. Smith" wrote:
> I've posted a new version of PEP 557, it should soon be available at
> https://www.python.org/dev/peps/pep-0557/.
>
> The only significant changes since the last version are:
>
> -
uld 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.
--
--Guido van Ro
allow, so I also
>> suspect that this is easier said than done.
>>
>> --
>> Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
>>
>>
>>
>> ___
>> Python-Dev mailing list
>>
ubscribe: 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
> Unsubsc
On second thought I don't care that much.
On Dec 3, 2017 9:07 AM, "Eric V. Smith" wrote:
> On 12/3/2017 11:56 AM, Guido van Rossum wrote:
>
>> Not sure I like that better. It's an open-ended sequence of homogeneous
>> types. What's the advantage
e to judge at
> this point. I guess if I clear my head and I were doing it from scratch
> again I'd make them as_dict and as_tuple, so maybe I should brush aside
> inertia and make the change.
>
The Python stdlib is incredibly inconsistent where it comes to inserting
underscor
Ivan,
Congrats on your PEP. I believe the outstanding issues are now resolved and
I am hereby accepting it.
PS. Sorry, Larry, PEP 549 is rejected. But that happened a while ago.
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
ation code, including the very generous authors and maintainers of
"attrs", from which this has taken many ideas.
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/py
Ivan,
Congrats on your PEP. I believe the outstanding issues are now resolved and
I am hereby accepting it.
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
>
> Link for lazy people like me:https://www.python.org/dev/peps/pep-0562/
>
> I changed the PEP status to fix a typo in the
> abstract:https://github.com/python/peps/commit/a87417b22bf15bc4382daeaef6d32886c687ad19
>
> Victor
>
>
> 2017-12-04 17:58 GMT+01:00 Guido va
class ImSet:
> def add(self, a: ImSet) -> List[ImSet]: ...
>
> assert ImSet.add.__annotations__ == {
> 'a': 'ImSet', 'return': 'List[ImSet]'
> }
>
> Such a ``__future__`` import statement may be prop
who don't even know they are Python developers
a hint when they are using deprecated features (for which there always must
be a shiny new replacement!).
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.or
On Tue, Dec 5, 2017 at 9:59 AM, Victor Stinner
wrote:
> 2017-12-05 16:50 GMT+01:00 Guido van Rossum :
> > Honestly, I didn't completely follow what Victor thinks of the PEP -- his
> > post seemed mostly about promoting his own -X dev flag.
>
> -X dev is similar (but
On Tue, Dec 5, 2017 at 11:11 AM, Barry Warsaw wrote:
> On Dec 5, 2017, at 13:24, Guido van Rossum wrote:
>
> > But the whole point of the PEP is that it only warns about deprecations
> in code over which the user has control -- likely __main__ is their own
> code, and th
On Tue, Dec 5, 2017 at 12:10 PM, Victor Stinner
wrote:
> 2017-12-05 19:24 GMT+01:00 Guido van Rossum :
> >> I disagree that *users* of an application is supposed to "handle"
> >> deprecation warnings: report them to the developer, or even try to fix
> >&
-dev/2010-October/104509.html
> >`_
> thread on the python-dev mailing list
>
> Incomplete list of Python issues related to Unicode errors, especially
> with the POSIX locale:
>
> * 2016-12-22: `LANG=C python3 -c "import os; os.path.exists('\xff')"
> <http://bugs.python.org/issue29042#msg283821>`_
> * 2014-07-20: `issue #22016: Add a new 'surrogatereplace' output only
> error handler <http://bugs.python.org/issue22016>`_
> * 2014-04-27: `Issue #21368: Check for systemd locale on startup if
> current locale is set to POSIX <http://bugs.python.org/issue21368>`_
> -- read manually /etc/locale.conf when the locale is POSIX
> * 2014-01-21: `Issue #20329: zipfile.extractall fails in Posix shell
> with utf-8 filename <http://bugs.python.org/issue20329>`_
> * 2013-11-30: `Issue #19846: Python 3 raises Unicode errors with the C
> locale
> <http://bugs.python.org/issue19846>`_
> * 2010-05-04: `Issue #8610: Python3/POSIX: errors if file system
> encoding is None <http://bugs.python.org/issue8610>`_
> * 2013-08-12: `Issue #18713: Clearly document the use of
> PYTHONIOENCODING to set surrogateescape
> <http://bugs.python.org/issue18713>`_
> * 2013-09-27: `Issue #19100: Use backslashreplace in pprint
> <http://bugs.python.org/issue19100>`_
> * 2012-01-05: `Issue #13717: os.walk() + print fails with
> UnicodeEncodeError
> <http://bugs.python.org/issue13717>`_
> * 2011-12-20: `Issue #13643: 'ascii' is a bad filesystem default encoding
> <http://bugs.python.org/issue13643>`_
> * 2011-03-16: `issue #11574: TextIOWrapper should use UTF-8 by default
> for the POSIX locale <http://bugs.python.org/issue11574>`_, thread on
> python-dev: `Low-Level Encoding Behavior on Python 3
> <https://mail.python.org/pipermail/python-dev/2011-March/109361.html>`_
> * 2010-04-26: `Issue #8533: regrtest: use backslashreplace error handler
> for stdout <http://bugs.python.org/issue8533>`_, regrtest fails with
> Unicode encode error if the locale is POSIX
>
> Some issues are real bugs in applications which must explicitly set the
> encoding. Well, it just works in the common case (locale configured
> correctly), so what? The program "suddenly" fails when the POSIX
> locale is used (probably for bad reasons). Such bugs are not well
> understood by users. Example of such issues:
>
> * 2013-11-21: `pip: open() uses the locale encoding to parse Python
> script, instead of the encoding cookie
> <http://bugs.python.org/issue19685>`_ -- pip must use the encoding
> cookie to read a Python source code file
> * 2011-01-21: `IDLE 3.x can crash decoding recent file list
> <http://bugs.python.org/issue10974>`_
>
>
> Prior Art
> =
>
> Perl has a ``-C`` command line option and a ``PERLUNICODE`` environment
> variable to force UTF-8: see `perlrun
> <http://perldoc.perl.org/perlrun.html>`_. It is possible to configure
> UTF-8 per standard stream, on input and output streams, etc.
>
>
> Post History
>
>
> * 2017-04: `[Python-Dev] Proposed BDFL Delegate update for PEPs 538 &
> 540 (assuming UTF-8 for *nix system boundaries)
> <https://mail.python.org/pipermail/python-dev/2017-April/147795.html>`_
> * 2017-01: `[Python-ideas] PEP 540: Add a new UTF-8 mode
> <https://mail.python.org/pipermail/python-ideas/2017-January/044089.html
> >`_
> * 2017-01: `bpo-28180: Implementation of the PEP 538: coerce C locale to
> C.utf-8 (msg284764) <https://bugs.python.org/issue28180#msg284764>`_
> * 2016-08-17: `bpo-27781: Change sys.getfilesystemencoding() on Windows
> to UTF-8 (msg272916) <https://bugs.python.org/issue27781#msg272916>`_
> -- Victor proposed ``-X utf8`` for the :pep:`529` (Change Windows
> filesystem encoding to UTF-8)
>
>
> Copyright
> =
>
> This document has been placed in the public domain.
> ___
> 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
Sorry to burst your bubble, but I have not followed any of the discussion
and I am actually very worried about this topic. I don't think I will be
able to make time for this before the 3.7b1 feature freeze.
On Tue, Dec 5, 2017 at 6:51 PM, Eric Snow
wrote:
> Hi all,
>
> I've finally updated PEP 5
So you're okay with putting this off till (at least) 3.8? That sounds good
to me, given that I'd like to go on vacation soon.
On Wed, Dec 6, 2017 at 5:04 PM, Nick Coghlan wrote:
> On 7 December 2017 at 01:50, Guido van Rossum wrote:
> > Sorry to burst your bubble, but I ha
If the point is just to be able to test the existing API better, no PEP is
needed, right? It would be an unsupported, undocumented API.
On Wed, Dec 6, 2017 at 7:22 PM, Nick Coghlan wrote:
> On 7 December 2017 at 12:46, Guido van Rossum wrote:
> > So you're okay with putting thi
OK, then please just change the PEP's Version: header to 3.8.
On Wed, Dec 6, 2017 at 7:57 PM, Eric Snow
wrote:
>
>
> On Dec 6, 2017 20:31, "Guido van Rossum" wrote:
>
> If the point is just to be able to test the existing API better, no PEP is
> needed,
ADA's point. (Unless
you use encoding='Latin-1'.) His worry is that the surrogateescape error
handler makes it so that you won't get decoding errors, and then the
failure mode is much harder to debug.
--
--Guido van Rossum (python.org/~guido)
___
Py
than would produced for manually written classes. It is unclear
>> what the best practice is for where to put the annotations and their
>> associated docstrings.
>>
>
> I don't have any suggestions here.
>
> Eric.
>
> _
and docstring for
>> constructing instances? Should they be attached to the class, to
>> __init__(), or to __new__() when it used.
>>
>> It would be nice to have an official position on that before, it gets set
>> in stone through arbitrary choices made by pycharm, pydoc, mypy,
>> typing.NamedTuple, and dataclasses.dataclass.
>>
>
> I'm not sure I see why this would relate specifically to typing, since I
> don't think they'd inspect docstrings. But yes, it would be good to come to
> an agreement.
>
I don't recall in detail what all these tools and classes do with
docstrings. Maybe if someone summarizes the status quo and explains how PEP
557 changes that it will be simple to decide.
--
--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
OTOH daytaclass is a decorator for *better* metaclass compatibility.
On Dec 10, 2017 13:17, "Antoine Pitrou" wrote:
> On Sun, 10 Dec 2017 20:47:45 +0100
> Antoine Pitrou wrote:
>
> > Hi,
> >
> > On Sun, 10 Dec 2017 19:17:25 +
> > Tin Tvrtković wrote:
> > > Hello,
> > >
> > > I'm one of the
Maybe it should be a PEP?
On Dec 10, 2017 12:29, "Brett Cannon" wrote:
> While the note from a technical standpoint is interest, Xavier, I don't
> quite see what needs to be done to support Android at this point. Are you
> simply asking we add Android API 24 as an official platform? Or permissio
lso maintain order in a consistent way? I suspect the answer
>there is much the same--there's an obvious way it should behave, it almost
>certainly already behaves that way, but it doesn't guarantee it. I don't
>think I need this for my use case.
>
>
>
> */arry*
>
> ++ Yes, that means "Argument Clinic" should really have been called
> "Parameter Clinic". But the "Parameter Clinic" sketch is nowhere near as
> funny.
>
--
--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
ido van Rossum wrote:
> > On Dec 10, 2017 12:29, "Brett Cannon" wrote:
> >> On Sun, 10 Dec 2017 at 06:19 Xavier de Gaye wrote:
> >>> The following note is a proposal to add the support of the Android
> platform.
> >>> [...]
> >> While t
()) -- I think this will have to be postponed
--
--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
__
> 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)
___
>
> > What about:
> >
> >
> > val = name.strip()[4:].upper() except Exception: -1
>
> That happens to be the exact syntax recommended by PEP 463 (modulo
> some distinguishing parentheses).
>
> https://www.python.org/dev/peps/pep-0463/
>
> ChrisA
> ___
hon 3.7+-only snippet look like this:
>
> import warnings
> warnings.hide_warnings()
>
> And have the forward-compatible snippet look like this:
>
> import warnings:
> if hasattr(warnings, "hide_warnings"):
> # Accounts for `-W`, `-X dev`
at 2:58 PM, Victor Stinner
wrote:
> Hi,
>
> 2017-12-12 21:21 GMT+01:00 Guido van Rossum :
> > I'm still hoping to accept this PEP, but I don't have time to wrap my
> head
> > around -Xdev ("devmode"?) which appears to be Victor's latest pet
>
called on.
This phrase is confusing; it could be read as implying that context changes
made by the function *will* get propagated back to the caller of run(),
contradicting what was said earlier. Maybe it's best to just delete it?
Otherwise if you intend it to add something it needs to be rephras
ppendix with the
perf analysis is the one thing that I think we can safely leave out, just
reference PEP 550 for this.)
> class _ContextData
Since this isn't a real class anyway I think the __mapping attribute might
as well be named _mapping. Ditto for other __variables later.
--
--Gu
___
> 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/
> yselivanov.ml%40gmail.com
> >
>
--
-
17 at 4:29 PM Yury Selivanov
> wrote:
>
>> On Thu, Dec 14, 2017 at 7:03 PM, Guido van Rossum
>> wrote:
>> My motivation to add the slot wasn't the performance: it's just not
>> possible to have a class-level __getitem__ on types defined in C. The
>> only
ke it language spec, I think we have enough room
> to optimize.
>
> * It can make stop discussion like "Does X keeps insertion order?
> It's language spec?", "What about Y? Z?". Everything on top of dict
> keeps insertion order. It's simple t
to confirm that he's okay with
this.
On Thu, Dec 14, 2017 at 6:20 PM, Guido van Rossum wrote:
> I'm in favor of stating that dict keeps order as part of the language spec.
>
> However re-reading https://mail.python.org/pipermail/python-dev/2017-
> November/150381.html the
gt;
> Regards,
>
> INADA Naoki
> ___
> 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%4
On Fri, Dec 15, 2017 at 8:32 AM, Raymond Hettinger <
raymond.hettin...@gmail.com> wrote:
>
> > On Dec 15, 2017, at 7:53 AM, Guido van Rossum wrote:
> >
> > Make it so. "Dict keeps insertion order" is the ruling. Thanks!
>
> Thank you. That is wonde
Whatever it does in 3.6.
On Fri, Dec 15, 2017 at 10:19 AM, Serhiy Storchaka
wrote:
> 15.12.17 17:53, Guido van Rossum пише:
>
>> Make it so. "Dict keeps insertion order" is the ruling. Thanks!
>>
>
> What should dict.popitem() return? The first ite
On Fri, Dec 15, 2017 at 10:30 AM, Eric Snow
wrote:
> On Fri, Dec 15, 2017 at 8:53 AM, Guido van Rossum
> wrote:
> > Make it so. "Dict keeps insertion order" is the ruling. Thanks!
>
> Does that include preserving order after deletion?
Yes, that's what
On Fri, Dec 15, 2017 at 12:45 PM, Raymond Hettinger <
raymond.hettin...@gmail.com> wrote:
>
> > On Dec 15, 2017, at 7:53 AM, Guido van Rossum wrote:
> >
> > Make it so. "Dict keeps insertion order" is the ruling.
>
> On Twitter, someone raised an inte
Cool, thanks! I'm curious why this was brought up at all then...
On Dec 15, 2017 3:36 PM, "Raymond Hettinger"
wrote:
>
>
> > On Dec 15, 2017, at 1:47 PM, Guido van Rossum wrote:
> >
> > On Fri, Dec 15, 2017 at 12:45 PM, Raymond Hettinger <
> raymond
the tp_flags field to 64 bits, precisely because of
> the binary compatibility problem...
>
> Regards
>
> Antoine.
>
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo
g the flag bits it
can cause wild pointer following. This sounds like it would be a potential
security issue (load a module, ignore the warning, try to use a certain API
on a class it defines, boom). Also, could there still be 3rd party modules
out there that haven't been recompiled in a re
2:15 -0800
> Guido van Rossum wrote:
> >
> > If it's only a warning, I worry that if we stop checking the flag bits it
> > can cause wild pointer following. This sounds like it would be a
> potential
> > security issue (load a module, ignore the warning, try to use a
> 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)
__
quot;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.
--
--Guido van Rossum (python.org/~guido)
gular 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
utput 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
> Unsub
Looks to me the prohibition was to prevent a crash. It makes more sense to
fix it.
On Dec 28, 2017 03:39, "Serhiy Storchaka" wrote:
Currently 'continue' is prohibited inside 'finally' clause, but 'break' and
'return' are allowed. What is the r
'continue' was prohibited in https://bugs.python.or
401 - 500 of 6462 matches
Mail list logo
