Re: [Python-Dev] Language Summit Follow-Up

good hints about what went wrong when Python 3 encounters what appears to be a print statement. -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe:

Re: [Python-Dev] Language Summit Follow-Up

Right. The point is that the current HOWTO gives information that is not useful for most people who are tasked with a port. On Fri, May 30, 2014 at 6:46 PM, Nick Coghlan wrote: > > On 31 May 2014 08:42, "Guido van Rossum" wrote: > > > > 2to3 is poorly named. With d

Re: [Python-Dev] Internal representation of strings and Micropython

;d have to expect most Python programs to fail with non-ASCII input. Then again the UTF-8 option would be pretty devastating too for anything manipulating strings (especially since many Python APIs are defined using indexes, e.g. the re module). Why not support

Re: [Python-Dev] Internal representation of strings and Micropython

version -- that seems the most contentious point. Realistically, most Python code that works on Python 3.4 won't work on Micropython (for various reasons, not just the string behavior) and neither does it need to. -- --Guido van Rossum (python.org/~

Re: [Python-Dev] asyncio/Tulip: use CPython as the new upstream

dule the workflow should be 3.5 -> Tulip. If Tulip's update_stdlib.sh script's prompts to copy this file are too distracting, I can hack the script to be silent about this file if it detects that the CPython repo is 3.4. -- --Guido van Rossum (python.org/~guido) __

Re: [Python-Dev] Moving Python 3.5 on Windows to a new compiler

A reminder: https://lh5.googleusercontent.com/-d4rF0qJPskQ/U0qpNjP5GoI/PW0/4RF_7zy3esY/w1118-h629-no/Python28.jpg -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman

Re: [Python-Dev] Help preventing SIGPIPE/SIG_DFL anti-pattern.

tor (I guess it would default to None). Then of course you will have to write the code that calls this instead of plain PyErr_SetFromErrno() for those syscalls where a file descriptor is present. And when Python exits with a BrokenPipeError it could suppress printing the stack trace when the file_desc

Re: [Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

the invisible, > implicit function used by comprehensions; > > - oh, you didn't know about that either? read the source code. > > > Only the first two levels of explanation are part of Python the > language. The rest is CPython implementation. > > > > -- &

Re: [Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

-- > Terry Jan Reedy > > > _______ > 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 > --

Re: [Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

On Tue, Jul 3, 2018 at 4:25 PM Victor Stinner wrote: > 2018-07-02 20:19 GMT+02:00 Guido van Rossum : > > Thank you all. I will accept the PEP as is. (...) > > I see more and more articles ("on the Internet") saying that Guido van > Rossum already accepted the PEP. Is

Re: [Python-Dev] Checking that PEP 558 (defined semantics for locals()) handles assignment expressions

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

Re: [Python-Dev] PEP 572 semantics

o see it listed like this. Assignment expressions always > evaluate from innermost to outermost. > > Gramatically, "Single assignment targets *other than* NAME are not > supported" would be more precise. And for specification's sake, does > "not suppor

Re: [Python-Dev] PEP 572 semantics: all capabilities of the assignment statement

iguities - for instance, is "x, y > := expr" going to be equivalent to "x, (y := expr)" or "(x, y) := > expr" ? As it is, we neatly dodge that. > Again, the biggest argument against this is that there just aren't enough use cases. -- --Guido

Re: [Python-Dev] Comparing PEP 576 and PEP 580

Would it be possible to get outside experts to help? Like Cython or numpy devs? On Thu, Jul 5, 2018 at 8:09 AM Jeroen Demeyer wrote: > On 2018-07-05 14:20, INADA Naoki wrote: > > What you can do is "divide and conquer". Split PEP in small topics we > > can focus. > > The PEP is already small an

Re: [Python-Dev] How about integrating "as" semantics and postpone PEP 572 to Python 4.0

assing instance of the > right hand of `as` in its statement. > - Exceptions must be instanciated and also it must be confirmed otherwise > `except` statement could rewrite the class globally. > > > Thanks, > Rin Arakaki > > ___ >

Re: [Python-Dev] Checking that PEP 558 (defined semantics for locals()) handles assignment expressions

On Thu, Jul 5, 2018 at 3:06 PM Nick Coghlan wrote: > > > On Thu., 5 Jul. 2018, 1:21 am Guido van Rossum, wrote: > >> Correct, there shouldn't be any additional corner cases for your PEP due >> to inline assignments. We're not introducing new scopes nor other ru

Re: [Python-Dev] PEP 572, VF/B, and "Shark Jumping"

romise design: > > 1 Handles the most common cases (of a group of infrequent cases) > 0 Doesn't handle more obscure cases. > 1 No new syntax (through reuse) > 1 Looks Pythonic as hell > 1 Difficult to misuse, complexity capped > >

Re: [Python-Dev] PEP 572 semantics: all capabilities of the assignment statement

On Thu, Jul 5, 2018 at 3:45 PM Nick Coghlan wrote: > > > On Thu., 5 Jul. 2018, 3:17 pm Guido van Rossum, wrote: > >> Let me be slightly contrarian. :-) >> >> On Wed, Jul 4, 2018 at 9:12 PM Chris Angelico wrote: >> >>> Definitely against augmentat

Re: [Python-Dev] PEP 572 semantics

that case work sensibly) > Right. > I'm still wondering if it might make sense to define a new > "TargetScopeError" subclass of SyntaxError for that last case, since it > isn't the assignment expression syntax itself that's the problem: it's > whe

Re: [Python-Dev] PEP 572: Do we really need a ":" in ":="?

ence the warnings with redundant (..) if they really want what they > wrote. > > ___ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.pyt

Re: [Python-Dev] On the METH_FASTCALL calling convention

In other words: I see nothing to improve in the calling convention of > METH_FASTCALL. I suggest to keep it and make it public as-is. > > > Jeroen. > > > [1] https://mail.python.org/pipermail/python-dev/2018-June/153945.html > [2] https://mail.python.org/pipermail/

Re: [Python-Dev] PEP 572: Do we really need a ":" in ":="?

s at least one thing that Google still does right. :-) (Though Bing also has an ironically relevant hit: apart from the above StackOverflow issue, it found a piece of third party documentation titled Conditionals and loops. :-) -- --Guido van Rossu

Re: [Python-Dev] PEP 572: Do we really need a ":" in ":="?

Sorry for messing up the quoting. I blame GMail. Only the text starting "Since this thread is dead" was mine. On Thu, Jul 5, 2018 at 8:20 PM Guido van Rossum wrote: > On Thu, Jul 5, 2018 at 7:12 PM Tim Peters wrote: > It doesn't even exist yet, but Googling on &g

Re: [Python-Dev] Comparing PEP 576 and PEP 580

On Fri, Jul 6, 2018 at 2:52 AM Jeroen Demeyer wrote: > On 2018-07-05 21:57, Guido van Rossum wrote: > > Would it be possible to get outside experts to help? > > I don't understand what you mean: to help with what? Designing the PEP? > Discussing the PEP? Accepting the PE

Re: [Python-Dev] Comparing PEP 576 and PEP 580

Thanks, I will wait until there is a conclusion to the debate. On Fri, Jul 6, 2018 at 4:05 PM Jeroen Demeyer wrote: > On 2018-07-06 23:12, Guido van Rossum wrote: > > It's your PEP. And you seem to be struggling with something. But I can't > > tell quite what it

Re: [Python-Dev] Naming comprehension syntax [was Re: Informal educator feedback on PEP 572 ...]

be it's not too late to start calling the latter "generator comprehensions" so that maybe by the year 2025 we can say "comprehensions" and everyone will understand we mean all four types? FWIW more people should start using "

Re: [Python-Dev] Call for prudence about PEP-572

ally e.g.: > > >>> foo(some_long_var_name, another_one, x := bar(), > y := fun()) > > To me this looks like the perfect example of where this functionality can > be abused. Also, I'm not clear what PEP-572 intend to do about "all other > places&quo

Re: [Python-Dev] Making the status of Provisional PEPs clearer

Should we update some PEPs with the new status? E.g. PEP 484. On Sat, Jul 7, 2018 at 7:46 PM Nick Coghlan wrote: > Hi folks, > > After review from Barry & Guido, I've just merged an update to PEP 1 > and the PEP index generator that separates out provisionally accepted > PEPs to their own state

Re: [Python-Dev] Making the status of Provisional PEPs clearer

Thanks! On Sat, Jul 7, 2018 at 8:29 PM Nick Coghlan wrote: > On 8 July 2018 at 12:48, Guido van Rossum wrote: > > Should we update some PEPs with the new status? E.g. PEP 484. > > Aye, 3 PEPs were given the new status as part of the commit: > > - 484 (type hi

Re: [Python-Dev] Call for prudence about PEP-572

a bunch of lines were saved. Potentially *a > lot* of lines can be saved so it even more advanced users may be > tempted to use it. After all the language allows it + "it's brand new > syntax so it must be good". > > 5) It has no keyword argument correspondence. If fo

Re: [Python-Dev] Naming comprehension syntax [was Re: Informal educator feedback on PEP 572 ...]

s and list comprehensions. > > So I think we could start a new naming scheme for those. > > ‘cause then we’d get lost of questions about the difference between > generator expressions and generator comprehensions ;-) > > > -CHB > -- --Guido van Rossum (python.org/~guid

Re: [Python-Dev] Naming comprehension syntax [was Re: Informal educator feedback on PEP 572 ...]

t Cannon wrote: > > > On Mon, 9 Jul 2018 at 12:05 Guido van Rossum wrote: > >> I think this is worth a try. >> > > How far do we want to go with this? Update the docs? Update the grammar > and/or code? I think the former is probably good enough for now to see if &

[Python-Dev] PEP 572: Assignment Expressions -- intention to accept, near-final draft

72.rst). PEP: 572 Title: Assignment Expressions Author: Chris Angelico , Tim Peters , Guido van Rossum Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 28-Feb-2018 Python-Version: 3.8 Post-History: 28-Feb-2018, 02-Mar-2018, 23-Mar-2018, 04-Apr-2018, 17-Apr-2018,

Re: [Python-Dev] PEP 572: Assignment Expressions -- intention to accept, near-final draft

On Mon, Jul 9, 2018 at 7:40 PM, Glenn Linderman wrote: > On 7/9/2018 6:00 PM, Guido van Rossum wrote: > > This rule is included to simplify the choice for the user between an > assignment statements and an assignment expression -- there is no > > > "statements&qu

Re: [Python-Dev] PEP 572: Assignment Expressions -- intention to accept, near-final draft

On Mon, Jul 9, 2018 at 8:24 PM, Rob Cliffe via Python-Dev < python-dev@python.org> wrote: > I apologise for not replying in the form of a Pull Request - I don't know > how to make one. > > > On 10/07/2018 02:00, Guido van Rossum wrote: > >> Rationale >>

[Python-Dev] Accepting PEP 572, Assignment Expressions

inds less tightly than - Dropped section "This could be used to create ugly code" - Clarified the example in Appendix C Now on to the implementation work! (Maybe I'll sprint on this at the core-dev sprint in September.) -- --Guido van Rossum (python.org/~guido) _

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

Also nobody had a use case. On Fri, Jul 13, 2018 at 6:57 AM Chris Angelico wrote: > On Fri, Jul 13, 2018 at 11:36 PM, Random832 > wrote: > > On Wed, Jul 11, 2018, at 20:10, Guido van Rossum wrote: > >> As anticippated, after a final round of feedback I am hereby acc

Re: [Python-Dev] Question about PEP 484

. But then again >>> Guido just got a bit more free time so he might chime in on this one. ;) >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "pytype" group. >>> To unsubscribe from this gro

Re: [Python-Dev] Question about PEP 484

On Mon, Jul 16, 2018 at 2:56 PM, Gregory P. Smith wrote: > > On Mon, Jul 16, 2018 at 1:44 PM Guido van Rossum wrote: > >> As one of the authors of PEP 484, *I* never thought there was an >> ambiguity here. The intention was for stub files to conform to the same >> g

Re: [Python-Dev] Question about PEP 484

d eager to help with this, if we get some guidance on what > the authors are still trying to finalize and how we can be useful. As > a conversation starter, we offered two issues in which pytype has some > personal stake. > > Best, > Rebecca > > P.S. Yes, Adam manages Python at

Re: [Python-Dev] PEP 572 and assert

, discourages this, or completely > forbids? > The PEP has no specific opinion except it is not forbidden. Personally I like Barry's example just fine -- assuming `subdirs` is not used later, this feels like a good use case. -- --Guido van Rossum (python.org/~guido) __

Re: [Python-Dev] Question about PEP 484

w what constructs will likely not work and should be > avoided. > > - Sebastian > > ___ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: https://mail.python.o

Re: [Python-Dev] PEP 572 and assert

On Tue, Jul 17, 2018 at 8:28 AM, Serhiy Storchaka wrote: > 17.07.18 17:59, Guido van Rossum пише: > >> The PEP has no specific opinion except it is not forbidden. >> >> Personally I like Barry's example just fine -- assuming `subdirs` is not >> used lat

Re: [Python-Dev] PEP 572 and assert

On Tue, Jul 17, 2018 at 9:24 AM, Serhiy Storchaka wrote: > 17.07.18 18:48, Guido van Rossum пише: > >> On Tue, Jul 17, 2018 at 8:28 AM, Serhiy Storchaka > <mailto:storch...@gmail.com>> wrote: >> Should not the assert statement introduce an implicit lexical scope

Re: [Python-Dev] 2to3 for python annotations

> working code in Python 3. > I think as an optional fixer it would be a fine contribution. Also I apologize for not yet reviewing https://github.com/dropbox/pyannotate/pull/74 (which I presume is yours?). -- --Guido van Rossum (python.org/~guido) _

Re: [Python-Dev] Benchmarks why we need PEP 576/579/580

I don’t think we can safely assume Python 3.7 has the same performance, actually. A lot has changed. On Sat, Jul 21, 2018 at 10:10 AM INADA Naoki wrote: > On Sun, Jul 22, 2018 at 1:28 AM Jeroen Demeyer wrote: > > > > Hello, > > > > I finally managed to get some real-life benchmarks for why we n

Re: [Python-Dev] Benchmarks why we need PEP 576/579/580

Given the cost of a mistake here I recommend a higher standard. But in the end it’s no longer my decision. On Sat, Jul 21, 2018 at 11:18 AM Jeroen Demeyer wrote: > On 2018-07-21 19:55, Guido van Rossum wrote: > > I don’t think we can safely assume Python 3.7 has the same pe

Re: [Python-Dev] Benchmarks why we need PEP 576/579/580

BDFL may be less demanding though. :=) On Sat, Jul 21, 2018 at 2:39 PM Stefan Behnel wrote: > Guido van Rossum schrieb am 21.07.2018 um 22:46: > > Given the cost of a mistake here I recommend a higher standard. > > May I ask what you think the "cost of a mistake" is her

Re: [Python-Dev] Benchmarks why we need PEP 576/579/580

2019 people will remember that you were very forceful in taking your position, not what that position was or why it's reasonable. Sorry I don't have better news. On Sun, Jul 22, 2018 at 5:52 AM, Stefan Behnel wrote: > Guido van Rossum schrieb am 22.07.2018 um 01:14: > > The cost w

Re: [Python-Dev] Benchmarks why we need PEP 576/579/580

de? I know that that's a poor proxy for complexity (we can all imagine example bits of code that would become less complex by rewriting them in more lines), but if your diff actually deleted more lines than it adds, that would cut short a lot of discussion. I have a feeling though tha

Re: [Python-Dev] What's the status of the PEP 572 implementation?

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

Re: [Python-Dev] We cannot fix all issues: let's close XML security issues (not fix them)

mean there shouldn't be any hard limits to expansion depth > or breadth. > > Function calls are a Python feature, yet we limit the amount of > recursion allowed. > > Regards > > Antoine. > _______ > Python-Dev mailing list > Python-Dev@python.org > https://mail.

Re: [Python-Dev] bpo-34595: How to format a type name?

uot; for fully qualfied name. We would only have to modify > > type.__format__(). > > > > I'm not sure if we need to add new formatters to str % args. > > > > Example of Python code: > > > > raise TypeError("must be str, not %s&quo

Re: [Python-Dev] Request for review: binary op dispatch rules for subclasses

iated! > > Best, > Stephan > ___ > 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

Re: [Python-Dev] Store startup modules as C structures for 20%+ startup speed improvement?

data segment without duplicating all sorts of > "singletons". > > Stefan > > ___ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > htt

Re: [Python-Dev] Store startup modules as C structures for 20%+ startup speed improvement?

On Fri, Sep 21, 2018 at 8:16 AM Christian Heimes wrote: > On 21/09/2018 16.26, Guido van Rossum wrote: > >> What about the small integers cache? > > > > I believe the small integers cache is only used to reduce the number of > > objects -- I don't think there&

Re: [Python-Dev] switch statement

t; statement. Please search for those before re-posting on python-ideas. -- --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/ma

Re: [Python-Dev] Postponed annotations break inspection of dataclasses

function body ran. I was wondering if I could motivate storing the > annotations as lambdas in class bodies and function signatures, in which > the environment is already being captured and is code that usually only > runs once. > ___ > P

Re: [Python-Dev] Postponed annotations break inspection of dataclasses

really thought about it). > Still, I wonder if there's a tweak possible of the globals and locals used when exec()'ing the function definitions in dataclasses.py, so that get_type_hints() gets the right globals for this use case. It's really tough to

Re: [Python-Dev] Documenting the private C API (was Re: Questions about signal handling.)

ehavior incompatibly, even in bugfix releases. -- --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] PEP 544 status (forked off "Petr Viktorin as BDFL-Delegate for PEP 580")

the only > > reason why PEP 544 is not yet accepted for example. > > Did you actually try to get PEP 544 accepted or to appoint a > BDFL-Delegate? I don't find any discussions about PEP 544 after the > stepping down of the BDFL. > -- --Guido van Rossum (python.org/~guido

Re: [Python-Dev] Should assert continue to do a LOAD_GLOBAL on AssertionError?

, > > > 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/guido%40python.org > -- --Gu

Re: [Python-Dev] Petr Viktorin as BDFL-Delegate for PEP 580

nsions that risk breaking). -- --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] Petr Viktorin as BDFL-Delegate for PEP 580

Well, it's not my call any more, so I'll happily stop arguing. On Wed, Oct 3, 2018 at 3:19 PM Terry Reedy wrote: > On 10/3/2018 5:27 PM, Guido van Rossum wrote: > > On Wed, Oct 3, 2018 at 2:13 PM Terry Reedy > <mailto:tjre...@udel.edu>> wrote: > > >

Re: [Python-Dev] PEP 544 status (forked off "Petr Viktorin as BDFL-Delegate for PEP 580")

Cheers, > Nick. > > -- > Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia > -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscr

Re: [Python-Dev] Arbitrary non-identifier string keys when using **kwargs

My feeling is that limiting it to strings is fine, but checking those strings for resembling identifiers is pointless and wasteful. On Tue, Oct 9, 2018 at 9:40 AM Jeff Hardy wrote: > On Sun, Oct 7, 2018 at 3:45 PM Terry Reedy wrote: > > > > On 10/7/2018 1:34 PM, Chris Barker via Python-Dev wrot

Re: [Python-Dev] Arbitrary non-identifier string keys when using **kwargs

On Tue, Oct 9, 2018 at 5:17 PM Barry Warsaw wrote: > On Oct 9, 2018, at 16:21, Steven D'Aprano wrote: > > > > On Tue, Oct 09, 2018 at 10:26:50AM -0700, Guido van Rossum wrote: > >> My feeling is that limiting it to strings is fine, but checking those > >>

Re: [Python-Dev] Arbitrary non-identifier string keys when using **kwargs

On Tue, Oct 9, 2018 at 7:49 PM Chris Jerdonek wrote: > On Tue, Oct 9, 2018 at 7:13 PM Benjamin Peterson > wrote: > > On Tue, Oct 9, 2018, at 17:14, Barry Warsaw wrote: > > > On Oct 9, 2018, at 16:21, Steven D'Aprano wrote: > > > > > > > > O

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

fail. Can we > get this example, suitably annotated, into the documentation > somewhere? > > I don't see a reason to document this behavior -- it would be strange if it *didn't* work. If we had an opcode to delete a variable but didn't raise if it is unset, we

Re: [Python-Dev] Return type of datetime subclasses added to timedelta

care about alternate constructors). >> > > This is right, but the same argument is equally applicable to int, float, > etc. subclasses. If you want to limit your change to datetime types you > should explain what makes these types special. > > __

Re: [Python-Dev] Return type of datetime subclasses added to timedelta

"changed in a way that raises an error in " > "this subclass. Please implement __add__ " > "if you need the old behavior.", DeprecationWarning) > > Then after a suitable notice period drop the warning and t

Re: [Python-Dev] VxWorks and cpython?

> Brian > > > > > > P.S. I can be found on github (and many other places) as kuhlenough. > > > > > ___ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/mailman/listinfo/python-dev >

Re: [Python-Dev] Add more SyntaxWarnings?

egards, > > Neil > ___ > 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 > -- --Gu

Re: [Python-Dev] Add more SyntaxWarnings?

uple tuple case.) > Does there need to be a new subclass of SyntaxError for "Technically > Valid But Not Meaningful" problems? Is there value in distinguishing > "InevitableTypeError" from "InevitableAttributeError"? > I don't think there's a *gen

Re: [Python-Dev] Add more SyntaxWarnings?

` by accident. They'll write `x + y` and by accident the types won't match. So better error messages at runtime would help. But I doubt we'll see much mileage out of the syntax checks. And making things work different based on whether it's a literal or a variable isn't v

Re: [Python-Dev] Asking for reversion

sage 334805. https://bugs.python.org/issue35813 > > -- > Terry Jan Reedy > > ___ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org

Re: [Python-Dev] Asking for reversion

Also, did anyone ask Davin directly to roll it back? On Sun, Feb 3, 2019 at 4:49 PM Guido van Rossum wrote: > I think this is now up to the 3.8 release manager. > > On Sun, Feb 3, 2019 at 4:34 PM Terry Reedy wrote: > >> On 2/3/2019 4:03 PM, Antoine Pitrou wrote: >> >

Re: [Python-Dev] Return type of datetime subclasses added to timedelta

the > archive link for this thread: > https://mail.python.org/pipermail/python-dev/2019-January/155984.html > > If you want to start commenting on the actual implementation, it's > available here (though it's pretty simple): > https://github.com/python/cpython/pull/10902 > &

Re: [Python-Dev] Return type of datetime subclasses added to timedelta

I think before I started this thread, so > now it's just waiting on merge. > On 2/4/19 11:38 AM, Guido van Rossum wrote: > > I recommend that you submit a PR so we can get it into 3.8 alpha 2. > > On Mon, Feb 4, 2019 at 5:50 AM Paul Ganssle wrote: > >> Hey all, &g

Re: [Python-Dev] "Good first issues" on the bug tracker

Footnotes: > [1] Please tell me I'm wrong about Python! But fixing minor issues > "en passant" is my experience in every other project I've contributed > to, including as a non-committing "new contributor" in the first few > patches. > > [2] Not sa

Re: [Python-Dev] Register-based VM [Was: Possible performance regression]

___ > 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] Typing Summit at PyCon?

If you're going to PyCon and interested in static typing for Python (e.g. mypy, pytype, Pyre, PyCharm), I have something for you. I am hoping to organize a Typing Summit, on Thursday afternoon, May 2nd. If you're interested, please reply to me so I can gauge interest. -- --Guido

Re: [Python-Dev] Remove tempfile.mktemp()

ode like this: binascii.hexlify(os.urandom(8)).decode('ascii') -- --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] Remove tempfile.mktemp()

e the security implications. > Hm, the random sequence (implemented in tempfile._RandomNameSequence) is currently derived from the random module, which is not cryptographically secure. Maybe all we need to do is replace its source of randomness with one derived from the secrets module. That seem

[Python-Dev] Invitation to the PyCon typing summit (Thu, May 2nd, 1-5pm, at PyCon in Cleveland)

on typing-sig, I've got your registration info.) -- --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/

Re: [Python-Dev] A request for PEP announcement format [was: PEP 570]

discuss PEPs on discuss.python.org now? That's > fine for me, should I create a thread like that for PEP 580 too? > It is up to the PEP author where a PEP will be discussed. You have the option of using python-dev, Discourse or a dedicated mailing

Re: [Python-Dev] Deprecating "instance method" class

gt; 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) ___

Re: [Python-Dev] No longer enable Py_TRACE_REFS by default in debug build

#x27;d > want to fix that. But it isn't unusable, so reducing memory usage at the > cost of making debugging harder is not compelling. > > Cheers, > Steve > ___ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/mailman/li

Re: [Python-Dev] No longer enable Py_TRACE_REFS by default in debug build

sed by C code) beyond what gc.get_objects() can report. But I agree that it isn't useful to the vast majority of users of a regular debug build. So let's leave it off by default even in debug builds. But let's not delete the macros. -- --Guido van Rossum (python.org/~guido) *Pronouns

Re: [Python-Dev] Update PEP 394: Distributions can choose what does python command mean

gt; Instead, this PEP specifies the expected behavior of the ``python3`` and > ``python2`` commands, which is not controversial. > ___ > Python-Dev mailing list > Python-Dev@python.org > https://m

Re: [Python-Dev] bpo-36558: Change time.mktime() return type from float to int?

gt; Night gathers, and now my watch begins. It shall not end until my death. > ___ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman

Re: [Python-Dev] Adding shlex.join?

ddressed in something like 5 minutes. > ___ > 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 >

Re: [Python-Dev] PEP 591 discussion (final qualifier) happening at typing-sig@

n >> >> [1] https://github.com/willingc/pep-communication/issues/1 >> [2] https://stackoverflow.com/a/3949004/1925449 >> >> -- >> Nathaniel J. Smith -- https://vorpus.org >> > ___ > Python-Dev mailing

Re: [Python-Dev] Concurrent.futures: no type discovery for PyCharm

cally > relying on undocumented bugs, and it gets really messy really quickly. > > -n > ___ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mail

Re: [Python-Dev] Concurrent.futures: no type discovery for PyCharm

ass of problems? > > Best Regards, > -- > Ilya Kamenshchikov > > > On Tue, Apr 23, 2019 at 7:05 PM Guido van Rossum wrote: > >> In any case I think this should be filed (by the OP) as an issue against >> JetBrains' PyCharm issue tracker. Who knows they may

[Python-Dev] Typing Summit at PyCon US

kka Lehtosalo: Modular typeshed. Ivan Levkivskyi: Typing and mypy usability. Andrey Vlasovskikh: Incremental static analysis in PyCharm. Guido van Rossum: Overview of upcoming typing PEPs (544: Protocols; 586: Literal; 589: TypedDict; 591: Final). There's also room to discuss more speculative ch

[Python-Dev] Steering Council Update for April 2019

I've posted an update from the Steering Council to our repo: https://github.com/python/steering-council/blob/master/updates/2019-04-26_steering-council-update.md I will also link to this on Discourse (discuss.python.org). -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him/his *

Re: [Python-Dev] Increasing the C-optimized pickle extensibility

nks, > > Pierre > ___ > 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 > -- --Guid

Re: [Python-Dev] datetime.fromisocalendar

I think it’s a good idea. On Sat, Apr 27, 2019 at 11:43 AM Paul Ganssle wrote: > Greetings, > > Some time ago, I proposed adding a `.fromisocalendar` alternate > constructor to `datetime` (bpo-36004 ), > with a corresponding implementation (PR #11888 >

Re: [Python-Dev] PEP 581 (Using GitHub issues for CPython) is accepted

note at the most recent PyCon US, please watch it. It is an amazing thing. https://www.youtube.com/watch?v=ftP5BQh1-YM -- start at 21:00 to skip the conference opening remarks.) -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him/his **(why is my pronoun here?)* <http://feministing.

<    8   9   10   11   12   13   14   15   16   17   >