[Python-Dev] PEP 411: Provisional packages in the Python standard library

Eli Bendersky wrote (in http://mail.python.org/pipermail/python-dev/2012-February/116393.html ): A package will be marked provisional by including the following paragraph as a note at the top of its documentation page: I really would like some marker available from within Python itself.

[Python-Dev] PEP 410 (Decimal timestamp): the implementation is ready for a review

PEP author Victor asked (in http://mail.python.org/pipermail/python-dev/2012-February/116499.html): Maybe I missed the answer, but how do you handle timestamp with an unspecified starting point like os.times() or time.clock()? Should we leave these function unchanged? If *all* you know is

[Python-Dev] PEP for new dictionary implementation

PEP author Mark Shannon wrote (in http://mail.python.org/pipermail/python-dev/attachments/20120208/05be469a/attachment.txt): ... allows ... (the ``__dict__`` attribute of an object) to share keys with other attribute dictionaries of instances of the same class. Is the same class a

[Python-Dev] Store timestamps as decimal.Decimal objects

In http://mail.python.org/pipermail/python-dev/2012-February/116073.html Nick Coghlan wrote: Besides, float128 is a bad example - such a type could just be returned directly where we return float64 now. (The only reason we can't do that with Decimal is because we deliberately don't allow

[Python-Dev] plugging the hash attack

In http://mail.python.org/pipermail/python-dev/2012-January/116003.html Benjamin Peterson wrote: 2. It will be off by default in stable releases ... This will prevent code breakage ... 2012/1/27 Steven D'Aprano steve at pearwood.info: ... it will become on by default in some future

[Python-Dev] Counting collisions for the win

In http://mail.python.org/pipermail/python-dev/2012-January/115715.html Frank Sievertsen wrote: Am 20.01.2012 13:08, schrieb Victor Stinner: I'm surprised we haven't seen bug reports about it from users of 64-bit Pythons long ago A Python dictionary only uses the lower bits of a hash value.

[Python-Dev] PEP 414 - Unicode Literals for Python 3

In http://mail.python.org/pipermail/python-dev/2012-February/116953.html Terry J. Reedy wrote: I presume that most 2.6 code has problems other than u'' when attempting to run under 3.x. Why? If you're talking about generic code that has seen minimal changes since 2.0, sure. But I think

[Python-Dev] Add a frozendict builtin type

In http://mail.python.org/pipermail/python-dev/2012-February/116955.html Victor Stinner proposed: The blacklist implementation has a major issue: it is still possible to call write methods of the dict class (e.g. dict.set(my_frozendict, key, value)). It is also possible to use ctypes and

[Python-Dev] PEP 414 - Unicode Literals for Python 3

In http://mail.python.org/pipermail/python-dev/2012-February/117070.html Vinay Sajip wrote: It's moot, but as I see it: the purpose of PEP 414 is to facilitate a single codebase across 2.x and 3.x. However, it only does this if your 3.x interest is 3.3+ For many people -- particularly those

[Python-Dev] PEP 416: Add a frozendict builtin type

In http://mail.python.org/pipermail/python-dev/2012-February/117113.html Victor Stinner posted: An immutable mapping can be implemented using frozendict:: class immutabledict(frozendict): def __new__(cls, *args, **kw): # ensure that all values are immutable

[Python-Dev] [RELEASED] Python 3.3.0 alpha 1

In http://mail.python.org/pipermail/python-dev/2012-March/117348.html Georg Brandl ge...@python.org posted: Python 3.3 includes a range of improvements of the 3.x series, as well as easier porting between 2.x and 3.x. Major new features in the 3.3 release series are: As much as it is

[Python-Dev] problem with recursive yield from delegation

http://mail.python.org/pipermail/python-dev/2012-March/117396.html Stefan Behnel posted: I found a problem in the current yield from implementation ... [paraphrasing] g1 yields from g2 g2 yields from g1 XXX python follows the existing delegation without checking re-entrancy

[Python-Dev] Adding a builtins parameter to eval(), exec() and __import__().

http://mail.python.org/pipermail/python-dev/2012-March/117395.html Brett Cannon posted: [in reply to Mark Shannon's suggestion of adding a builtins parameter to match locals and globals] It's a mess right now to try to grab the __import__() implementation and this would actually help clarify

[Python-Dev] Python install layout and the PATH on win32

In view-source:http://mail.python.org/pipermail/python-dev/2012-March/117586.html van.lindberg at gmail.com posted: 1) The layout for the python root directory for all platforms should be as follows: stdlib = {base/userbase}/lib/python{py_version_short} platstdlib =

[Python-Dev] Python install layout and the PATH on win32

In http://mail.python.org/pipermail/python-dev/2012-March/117617.html van.lindberg at gmail.com posted: As noted earlier in the thread, I also change my proposal to maintain the existing differences between system installs and user installs. [Wanted lower case, which should be irrelevant;

[Python-Dev] Docs of weak stdlib modules should encourage exploration of 3rd-party alternatives

In http://mail.python.org/pipermail/python-dev/2012-March/117570.html Steven D'Aprano posted: Need is awfully strong. I don't believe it is the responsibility of the standard library to be judge and reviewer of third party packages that it doesn't control. It is, however, user-friendly to

[Python-Dev] Issue #10278 -- why not just an attribute?

In http://mail.python.org/pipermail/python-dev/2012-March/117762.html Georg Brandl posted: + If available, a monotonic clock is used. By default, if *strict* is False, + the function falls back to another clock if the monotonic clock failed or is + not available. If *strict* is

[Python-Dev] Rename time.steady(strict=True) to time.monotonic()?

In http://mail.python.org/pipermail/python-dev/2012-March/118024.html Steven D'Aprano wrote: What makes this steady, given that it can be adjusted and it can go backwards? It is best-effort for steady, but putting best in the name would be an attractive nuisance. Is steady() merely a

[Python-Dev] time.clock_info() field names

In http://mail.python.org/pipermail/python-dev/2012-April/119134.html Benjamin Peterson wrote: I see PEP 418 gives time.clock_info() two boolean fields named is_monotonic and is_adjusted. I think the is_ is unnecessary and a bit ugly, and they could just be renamed monotonic and adjusted. I

[Python-Dev] PEP 362: 4th edition

Summary: *Every* Parameter attribute is optional, even name. (Think of builtins, even if they aren't automatically supported yet.) So go ahead and define some others that are sometimes useful. Instead of defining a BoundArguments class, just return a copy of the Signature,

[Python-Dev] backported Enum

(On June 19, 2013) Barry Warsaw wrote about porting mailman from flufl.enum to the stdlib.enum: Switching from call syntax to getitem syntax for looking up an enum member by name, e.g. -delivery_mode = DeliveryMode(data['delivery_mode']) +delivery_mode =

[Python-Dev] PEP 454 (tracemalloc) disable == clear?

(Tue Oct 29 12:37:52 CET 2013) Victor Stinner wrote: For consistency, you cannot keep traces when tracing is disabled. The free() must be enabled to remove allocated memory blocks, or next malloc() may get the same address which would raise an assertion error (you cannot have two memory

[Python-Dev] Which direction is UnTransform? / Unicode is different

(Fri Nov 15 16:57:00 CET 2013) Stephen J. Turnbull wrote: Serhiy Storchaka wrote: If the transform() method will be added, I prefer to have only one transformation method and specify a direction by the transformation name (bzip2/unbzip2). Me too. Until I consider special cases

[Python-Dev] Python3 complexity - 2 use cases

Steven D'Aprano wrote: I think that heuristics to guess the encoding have their role to play, if the caller understands the risks. Ben Finney wrote: In my opinion, content-type guessing heuristics certainly don't belong in the standard library. It would be great if there were never any

[Python-Dev] PEP 460 -- adding explicit assumptions

As best I can tell, some people (apparently including Guido and PEP author Antoine) are taking some assumptions almost for granted, while other people (including me, before Nick's messages) were not assuming them at all. Since these assumptions (or, possibly, rejections of them?) are likely to

[Python-Dev] Automatic encoding detection [was: Re: Python3 complexity - 2 use cases]

So when it is time to guess [at the character encoding of a file], a source of good guesses is an important battery to include. The barrier for entry to the standard library is higher than mere usefulness. Agreed. But most programs will need it, and people will either include (the same)

Re: [Python-Dev] PEP 460 reboot

Nick Coghlan wrote: Arbitrary binary data and ASCII compatible binary data are *different things* and the only argument in favour of modelling them with a single type is because Python 2 did it that way. Greg Ewing replied: I would say that ASCII compatible binary data is a *subset* of

Re: [Python-Dev] PEP 460 reboot

Greg Ewing replied: ... ASCII compatible binary data is a *subset* of arbitrary binary data. I wrote: But in terms of explaining the text model, that separation is important enough that (2) It *may* be worth creating a virtual split in the documentation. (rough sketch

Re: [Python-Dev] PEP 461: Adding % formatting to bytes and bytearray -- Final, Take 2

Victor Stinner wrote: Will ascii() ever emit an antislash representation? Try ascii(chr(0x1f)). In which version? I get: ValueError: chr() arg not in range(0x11) How do you plan to use this output? Write it into a socket or a file? When I debug, I use print logging which

Re: [Python-Dev] PEP 463: Exception-catching expressions

Yury Selivanov wrote: I think the Motivation section is pretty weak. I have normally wished for this when I was (semi- interactively) exploring a weakly structured dataset. Often, I start with a string, split it into something hopefully like records, and then start applying filters and

Re: [Python-Dev] PEP 463: Exception-catching expressions

Greg Ewing suggested: This version might be more readable: value = lst[2] except No value if IndexError Ethan Furman asked: It does read nicely, and is fine for the single, non-nested, case (which is probably the vast majority), but how would it handle nested exceptions? With

[Python-Dev] Alternative forms [was: PEP 463: Exception-catching expressions]

The PEP currently says: Alternative Proposals = Discussion on python-ideas brought up the following syntax suggestions:: value = expr except default if Exception [as e] This one was rejected because of the out-of-order evaluation. Note, however, that the

Re: [Python-Dev] Alternative forms [was: PEP 463: Exception-catching expressions]

(Thu Mar 6 23:26:47 CET 2014) Chris Angelico responded: On Fri, Mar 7, 2014 at 7:29 AM, Jim J. Jewett jimjjewett at gmail.com wrote: [ note that x if y already occurs in multiple contexts, and always evaluates y before x. ] Yes, but that's still out of order. Yeah, but local

[Python-Dev] What is the precise problem? [was: Reference cycles in Exception.__traceback__]

On Wed Mar 5 17:37:12 CET 2014, Victor Stinner wrote: Python 3 now stores the traceback object in Exception.__traceback__ and exceptions can be chained through Exception.__context__. It's convenient but it introduced tricky reference cycles if the exception object is used out of the

[Python-Dev] Why not make frames? [was: Reference cycles in Exception.__traceback__]

On Thu Mar 6 16:52:56 CET 2014, Antoine Pitrou wrote: IMO it is absolutely out of question to allow creation of arbitrary frames from Python code, because the structure and initialization of frames embody too many low-level implementation details. So? Does any of that matter until the

[Python-Dev] Why not make frames? [was: Alternative forms [was: PEP 463: Exception-catching expressions]]

a longer line. (3a) Does the except expression need to be general, or would it work if it were limited to a subclause of variable assignments? (3b) What about comprehensions? On Fri Mar 7 20:54:31 CET 2014, Chris Angelico wrote: On Sat, Mar 8, 2014 at 5:58 AM, Jim J. Jewett jimjjewett

[Python-Dev] Scope issues [was: Alternative forms [was: PEP 463: Exception-catching expressions]]

On Fri Mar 7 20:54:31 CET 2014, Chris Angelico wrote: On Sat, Mar 8, 2014 at 5:58 AM, Jim J. Jewett jimjjewett at gmail.com wrote: (Thu Mar 6 23:26:47 CET 2014) Chris Angelico responded: ...[as-capturing is] deferred until there's a non-closure means of creating a sub-scope. The problem

Re: [Python-Dev] What is the precise problem? [was: Reference cycles in Exception.__traceback__]

On Mon Mar 10 18:56:17 CET 2014 (and earlier quotes), Maciej Fijalkowski wrote: Maciej: You should not rely on __del__s being called timely one way or Maciej: another. Why would you require this for the program to work Maciej: correctly in the particular example of __traceback__? To the extent

[Python-Dev] Keyword meanings [was: Accept just PEP-0426]

Vinay Sajip reworded the 'Provides-Dist' definition to explicitly say: The use of multiple names in this field *must not* be used for bundling distributions together. It is intended for use when projects are forked and merged over time ... (1) Then how *should* the

[Python-Dev] dict and required hashing

(1) I believe the recent consensus was that the number of comparisons made in a dict lookup is an implementation detail. (Please correct me if I am wrong.) (2) Is the item will be hashed at least once a language guarantee? For small mappings, it might well be more efficient to just store the

[Python-Dev] API and process questions (sparked by Claudiu Popa on 16104

(1) Should fixes to a docstring go in with a patch, even if they aren't related to the changing functionality? Bytestring compilation has several orthogonal parameters. Most -- but not all -- are documented in the docstring. (Specifically, there is no explanation of the rx parameter which acts

Re: [Python-Dev] API and process questions (sparked by Claudiu Popa on 16104

On Mon, Apr 28, 2014 at 12:56 PM, Charles-François Natali cf.nat...@gmail.com wrote: Why would the user care if multiprocessing is used behind the scene? Err ... that was another set of questions that I forgot to ask. (A) Why bother raising an error if multiprocessing is unavailable? After

[Python-Dev] Internal representation of strings and Micropython (Steven D'Aprano's summary)

Steven D'Aprano wrote: (1) I asked if it would be okay for MicroPython to *optionally* use nominally Unicode strings limited to ASCII. Pretty much the only response to this as been Guido saying That would be a pretty lousy option, and since nobody has really defended the suggestion, I

Re: [Python-Dev] Fix Unicode-disabled build of Python 2.7

On 6/24/2014 4:22 AM, Serhiy Storchaka wrote: I submitted a number of patches which fixes currently broken Unicode-disabled build of Python 2.7 (built with --disable-unicode configure option). I suppose this was broken in 2.7 when C implementation of the io module was introduced. It has

Re: [Python-Dev] sum(...) limitation

Sat Aug 2 12:11:54 CEST 2014, Julian Taylor wrote (in https://mail.python.org/pipermail/python-dev/2014-August/135623.html ) wrote: Andrea Griffini agriff at tin.it wrote: However sum([[1,2,3],[4],[],[5,6]], []) concatenates the lists. hm could this be a pure python case that

[Python-Dev] Backwards compatibility after certificate autovalidation

Summary: There needs to be a simple way to opt out at install time. It would be far better to offer more fine-grained control, but leaving that better solution to downstream is acceptable. On 3 September 2014 01:19, Antoine Pitrou solipsis at pitrou.net wrote: RFC 2818 (HTTP over TLS) has

Re: [Python-Dev] Backwards compatibility after certificate autovalidation

On Mon, Sep 8, 2014 at 3:44 PM, Cory Benfield c...@lukasa.co.uk wrote: On 8 September 2014 18:23, Jim J. Jewett jimjjew...@gmail.com wrote: Summary: There needs to be a simple way to opt out at install time. It would be far better to offer more fine-grained control, but leaving that better

Re: [Python-Dev] Backwards compatibility after certificate autovalidation

On Tue, Sep 9, 2014 at 12:11 PM, Christian Heimes christ...@python.org wrote: On 09.09.2014 05:03, Nick Coghlan wrote: On 9 Sep 2014 10:48, Jim J. Jewett jimjjew...@gmail.com mailto:jimjjew...@gmail.com wrote: From Guido's and your feedback, I think we may need two things to approve

Re: [Python-Dev] Multilingual programming article on the Red Hat Developer blog

On September 11, 2014, Jeff Allen wrote: ... the area of code point space used for the smuggling of bytes under PEP-383 is not a Unicode Private Use Area, but a portion of the trailing surrogate range. This is a code violation, which I imagine is why surrogateescape is an error

Re: [Python-Dev] Multilingual programming article on the Red Hat Developer blog

On Sat Sep 13 00:16:30 CEST 2014, Jeff Allen wrote: 1. Java does not really have a Unicode type, therefore not one that validates. It has a String type that is a sequence of UTF-16 code units. There are some String methods and Character methods that deal with code points represented as

[Python-Dev] PEP 479

I have a strong suspicion that I'm missing something; I have been persuaded both directions too often to believe I have a grip on the real issue. So I'm putting out some assumptions; please tell me if I'm wrong, and maybe make them more explicit in the PEP. (1) The change will only affect

[Python-Dev] hg vs Github [was: PEP 481 - Migrate Some Supporting Repositories to Git and Github]

M. Cepl asked: What I really don't understand is why this discussion is hg v. GitHub, when it should be hg v. git. Particular hosting is a secondary issue I think even the proponents concede that git isn't better enough to justify a switch in repositories. They do claim that GitHub

Re: [Python-Dev] My thinking about the development process

Brett Cannon wrote: 4. Contributor creates account on bugs.python.org and signs the [contributor agreement](https://www.python.org/psf/contrib/contrib-form/) Is there an expiration on such forms? If there doesn't need to be (and one form is good for multiple tickets), is there an objection

Re: [Python-Dev] libffi embedded in CPython

On Thu, Dec 18, 2014, at 14:13, Maciej Fijalkowski wrote: ... http://bugs.python.org/issue23085 ... is there any reason any more for libffi being included in CPython? [And why a fork, instead of just treating it as an external dependency] Benjamin Peterson responded: It has some sort of

Re: [Python-Dev] libffi embedded in CPython

On Thu, Dec 18, 2014, at 14:13, Maciej Fijalkowski wrote: ... http://bugs.python.org/issue23085 ... is there any reason any more for libffi being included in CPython? Paul Moore wrote: Probably the easiest way of moving this forward would be for someone to identify the CPython-specific

Re: [Python-Dev] PEP 441 - Improving Python ZIP Application Support

Barry Warsaw wrote: I don't know exactly what the procedure would be to claim .pyz for *nix, e.g. updating /etc/mime.types, but I think the PEP should at least mention this. I think we want to get as official support for .pyz files on *nix as possible. Paul Moore wrote: I'll add a note to

Re: [Python-Dev] PEP 441 - Improving Python ZIP Application Support

On Wed, Feb 18, 2015 at 4:16 PM, Paul Moore p.f.mo...@gmail.com wrote: On 18 February 2015 at 20:48, Jim J. Jewett jimjjew...@gmail.com wrote: Barry Warsaw wrote: I don't know exactly what the procedure would be to claim .pyz for *nix, e.g. updating /etc/mime.types, ... Are you just looking

Re: [Python-Dev] PEP 489: Redesigning extension module loading

On 16 March 2015 Petr Viktorin wrote: If PyModuleCreate is not defined, PyModuleExec is expected to operate on any Python object for which attributes can be added by PyObject_GetAttr* and retrieved by PyObject_SetAttr*. I assume it is the other way around (add with Set and retrieve with

Re: [Python-Dev] Thoughts on running Python 3.5 on Windows (path, pip install --user, etc)

On 10 March 2015 at slightly after midnight. Paul Moore wrote: Personally I doubt it would make much difference. If the docs say pygmentize I'm unlikely to dig around to find that the incantation python -m pygments.somemodule:main does the same thing using 3 times as many characters. I'd

Re: [Python-Dev] Request for Pronouncement: PEP 441 - Improving Python ZIP Application Support

On 24 February 2015 at 18:58, Guido van Rossum guido at python.org wrote: The naming of the functions feels inconsistent -- maybe pack(directory, target) - create_archive(directory, archive), and set_interpreter() - copy_archive(archive, new_archive)? Paul Moore wrote: One possible source

Re: [Python-Dev] Request for Pronouncement: PEP 441 - Improving Python ZIP Application Support

On Wed, Feb 25, 2015 at 2:33 PM, Paul Moore p.f.mo...@gmail.com wrote: On 25 February 2015 at 17:06, Paul Moore p.f.mo...@gmail.com wrote: I've included the resulting API documentation below. It looks pretty good to me. Me too. I have a few nits anyhow. .. function::

[Python-Dev] PEP 492: What is the real goal?

On Tue Apr 28 23:49:56 CEST 2015, Guido van Rossum quoted PEP 492: Rationale and Goals === Current Python supports implementing coroutines via generators (PEP 342), further enhanced by the ``yield from`` syntax introduced in PEP 380. This approach has a number of

Re: [Python-Dev] PEP 492: What is the real goal?

On Wed, Apr 29, 2015 at 2:26 PM, Paul Moore p.f.mo...@gmail.com wrote: On 29 April 2015 at 18:43, Jim J. Jewett jimjjew...@gmail.com wrote: So? PEP 492 never says what coroutines *are* in a way that explains why it matters that they are different from generators. ... Looking

Re: [Python-Dev] PEP 492: What is the real goal?

On Wed Apr 29 20:06:23 CEST 2015,Yury Selivanov replied: As best I can guess, the difference seems to be that a normal generator is using yield primarily to say: I'm not done; I have more values when you want them, but an asynchronous (PEP492) coroutine is primarily saying:

Re: [Python-Dev] ABCs - Re: PEP 492: async/await in Python; version 4

On Sun May 3 08:32:02 CEST 2015, Stefan Behnel wrote: Ok, fair enough. So, how would you use this new protocol manually then? Say, I already know that I won't need to await the next item that the iterator will return. For normal iterators, I could just call next() on it and continue the

Re: [Python-Dev] PEP 492: What is the real goal?

On Fri, May 1, 2015 at 2:59 PM, Guido van Rossum gu...@python.org wrote: On Fri, May 1, 2015 at 11:26 AM, Jim J. Jewett jimjjew...@gmail.com wrote: On Thu, Apr 30, 2015 at 3:32 PM, Guido van Rossum gu...@python.org wrote: (Guido:) Actually that's not even wrong. When using generators

Re: [Python-Dev] PEP 492: What is the real goal?

On Thu, Apr 30, 2015 at 3:32 PM, Guido van Rossum gu...@python.org wrote: (me:) A badly worded attempt to say Normal generator: yield (as opposed to return) means that the function isn't done, and there may be more things to return later. but an asynchronous (PEP492) coroutine is primarily

Re: [Python-Dev] PEP 492: What is the real goal?

On Thu Apr 30 21:27:09 CEST 2015, Yury Selivanov replied: On 2015-04-30 2:41 PM, Jim J. Jewett wrote: Bad phrasing on my part. Is there anything that prevents an asynchronous call (or waiting for one) without the async with? If so, I'm missing something important. Either way, I would

Re: [Python-Dev] PEP 492: What is the real goal?

On Fri, May 1, 2015 at 4:10 PM, Guido van Rossum gu...@python.org wrote: On Fri, May 1, 2015 at 12:48 PM, Jim J. Jewett jimjjew...@gmail.com wrote: If there are more tasks than executors, yield is a way to release your current executor and go to the back of the line. I'm pretty sure I saw

Re: [Python-Dev] PEP 492: What is the real goal?

On Fri May 1 23:58:26 CEST 2015, Yury Selivanov wrote: Yes, you can't use 'yield from' in __exit__/__enter__ in current Python. What do you mean by can't use? It probably executed without errors, but it didn't run the generators. True. But it did return the one created by __enter__, so

Re: [Python-Dev] PEP 492: async/await in Python; version 5

On Tue May 5 18:29:44 CEST 2015, Yury Selivanov posted an updated PEP492. Where are the following over-simplifications wrong? (1) The PEP is intended for use (almost exclusively) with asychronous IO and a scheduler such as the asynchio event loop. (2) The new syntax is intended to make it

[Python-Dev] PEP 492: Please mention the Event Loop

On Tue May 5 21:44:26 CEST 2015,Brett Cannon wrote: It's not as complicated as it seems when you realize there is an event loop driving everything (which people have been leaving out of the conversation since it doesn't tie into the syntax directly). Another reason people don't realize it

Re: [Python-Dev] PEP 492: async/await in Python; version 4

Tue May 5 21:48:36 CEST 2015, Yury Selivanov wrote: As for terminology, I view this discussion differently. It's not about the technical details (Python has asymmetric coroutines, that's it), but rather on how to disambiguate coroutines implemented with generators and yield-from, from new

Re: [Python-Dev] Unicode 8.0 and 3.5

On Thu Jun 18 20:33:13 CEST 2015, Larry Hastings asked: On 06/18/2015 11:27 AM, Terry Reedy wrote: Unicode 8.0 was just released. Can we have unicodedata updated to match in 3.5? What does this entail? Data changes, code changes, both? Note that the unicode 7 changes also need to be

Re: [Python-Dev] Importance of async keyword

On Fri Jun 26 16:51:13 CEST 2015, Paul Sokolovsky wrote: So, currently in Python you know if you do: socket.write(buf) Then you know it will finish without interruptions for entire buffer. How do you know that? Are you assuming that socket.write is a builtin, rather than a python

Re: [Python-Dev] Status of PEP 484 and the typing module

Mark Shannon wrote: PY2, etc. really need to go. Assuming that this code type checks OK: if typing.PY2: type_safe_under_py2_only() else: type_safe_under_py3_only() Is the checker supposed to pass this: if sys.hexversion 0x0300: type_safe_under_py2_only()

Re: [Python-Dev] Status of PEP 484 and the typing module

At Thu May 21 22:27:50 CEST 2015, Guido wrote: I want to encourage users to think about annotations as types, and for most users the distinction between type and class is too subtle, So what is the distinction that you are trying to make? That a type refers to a variable (name), and a

Re: [Python-Dev] Preserving the definition order of class namespaces.

On Sun May 24 12:06:40 CEST 2015, Nick Coghlan wrote: On 24 May 2015 at 19:44, Mark Shannon mark at hotpy.org wrote: On 24/05/15 10:35, Nick Coghlan wrote: If we leave __definition_order__ out for the time being then, for the vast majority of code, the fact that the ephemeral namespace used

[Python-Dev] PEPs and PEP 8 changes

PEP 498 is only the latest PEP where part of the concern is fear that it may encourage certain types of bad code. Would it be reasonable to ask PEPs to start including a section on any recommended changes to PEP8? (e.g., "If an embedded expression doesn't fit on a single line, factor it out to a

[Python-Dev] PEP 509

(1) Please make it clear within the abstract what counts as a change. (1a) E.g., a second paragraph such as "Adding or removing a key, or replacing a value, counts as a change. Modifying an object in place, or replacing it with itself may not be picked up." (1b) Is there a way to force a

Re: [Python-Dev] Update PEP 7 to require curly braces in C

> On Jan 17, 2016, at 11:10, Brett Cannon wrote: >> While doing a review of http://bugs.python.org/review/26129/ >> ... update PEP 7 to remove the optionality of curly braces On Mon Jan 18 03:39:42 EST 2016, Andrew Barnert pointed out: > There are two ways you could do that. [The one most

[Python-Dev] pathlib (was: Defining a path protocol)

(1) I think the "built-in" should instead be a module-level function in the pathlib. If you aren't already expecting pathlib paths, then you're just expecting strings to work anyhow, and a builtin isn't likely to be helpful. (2) I prefer that the function be explicit about the fact that it is

Re: [Python-Dev] [Python-ideas] Add citation() to site.py

On Sun Mar 20 16:26:03 EDT 2016, Nikolaus Rath wrote: > Which I believe makes it completely pointless to cite Python at all. As > far as I can see, nowadays citations are given for two reasons: > 1. To give the reader a starting point to get more information on a >topic. I don't often see

Re: [Python-Dev] RFC: PEP 509: Add a private version to dict

On Thu Apr 14 11:19:42 EDT 2016, Victor Stinner posted the latest draft of PEP 509; dict version_tag (1) Meta Question: If this is really only for CPython, then is "Standards Track" the right classification? (2) Why *promise* not to update the version_tag when replacing a value with itself?

Re: [Python-Dev] RFC: PEP 509: Add a private version to dict

On Fri, Apr 15, 2016 at 4:41 PM, Victor Stinner <victor.stin...@gmail.com> wrote: > 2016-04-15 19:54 GMT+02:00 Jim J. Jewett <jimjjew...@gmail.com>: >> (2) Why *promise* not to update the version_tag when replacing a >> value with itself? > It's an useful pr

Re: [Python-Dev] Updated PEP 509

On Sat, Apr 16, 2016 at 5:01 PM, Victor Stinner wrote: > * I mentionned that version++ must be atomic, and that in the case of > CPython, it's done by the GIL Better; if those methods *already* hold the GIL, it is worth saying "already", to indicate that the change is

Re: [Python-Dev] RFC: PEP 509: Add a private version to dict

On Fri, Apr 15, 2016 at 7:31 PM, Victor Stinner <victor.stin...@gmail.com> wrote: > .2016-04-15 23:45 GMT+02:00 Jim J. Jewett <jimjjew...@gmail.com>: ... >> I just worry that you may end up closing off even better optimizations >> later, if you make too many promises ab

Re: [Python-Dev] PyWeakref_GetObject() borrows its reference from... whom?

On Mon, Oct 10, 2016, at 14:04, MRAB wrote: > Instead of locking the object, could we keep the GIL, but have it > normally released? > A thread could then still call a function such as PyWeakref_GetObject() > that returns a borrowed reference, but only if it's holding the GIL. It > would be

[Python-Dev] startup time repeated? why not daemon

I agree that startup time is a problem, but I wonder if some of the pain could be mitigated by using a persistent process. For example, in https://mail.python.org/pipermail/python-dev/2017-July/148664.html Ben Hoyt mentions that the Google Cloud SDK (CLI) team has found it "especially problematic

[Python-Dev] PEP 550 v3 naming

Building on Brett's suggestion: FrameContext: used in/writable by one frame ContextStack: a FrameContext and its various fallbacks -jJ ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev

Re: [Python-Dev] PEP 550 leak-in vs leak-out, why not just a ChainMap

On Thu, Aug 24, 2017 at 1:12 AM, Yury Selivanov > On Thu, Aug 24, 2017 at 12:32 AM, Jim J. Jewett <jimjjew...@gmail.com> wrote: > The key requirement for using immutable datastructures is to make > "get_execution_context" operation fast. Do you really need the whole exe

Re: [Python-Dev] PEP 550 leak-in vs leak-out, why not just a ChainMap

On Aug 24, 2017 11:02 AM, "Yury Selivanov" <yselivanov...@gmail.com> wrote: On Thu, Aug 24, 2017 at 10:05 AM, Jim J. Jewett <jimjjew...@gmail.com> wrote: > On Thu, Aug 24, 2017 at 1:12 AM, Yury Selivanov > On Thu, Aug 24, 2017 > at 12:32 AM, Jim J. Jewett <jim

[Python-Dev] PEP 550 and other python implementations

Should PEP 550 discuss other implementations? E.g., the object space used in pypy? -jJ ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe:

[Python-Dev] Pep 550 and None/masking

Does setting an ImplicitScopeVar to None set the value to None, or just remove it? If it removes it, does that effectively unmask a previously masked value? If it really sets to None, then is there a way to explicitly unmask previously masked values? Perhaps the initial constructor should

[Python-Dev] Pep 550 module

I think there is general consensus that this should go in a module other than sys. (At least a submodule.) The specific names are still To Be Determined, but I suspect seeing the functions and objects as part of a named module will affect what works. So I am requesting that the next iteration

[Python-Dev] PEP 550 leak-in vs leak-out, why not just a ChainMap

In https://mail.python.org/pipermail/python-dev/2017-August/148869.html Nick Coghlan wrote: > * what we want to capture at generator creation time is > the context where writes will happen, and we also > want that to be the innermost context used for lookups So when creating a generator, we

[Python-Dev] PEP 560: bases classes / confusion

(1) I found the following (particularly "bases classes") very confusing: """ If an object that is not a class object appears in the bases of a class definition, then ``__mro_entries__`` is searched on it. If found, it is called with the original tuple of bases as an argument. The result of the

[Python-Dev] unfrozen dataclasses and __hash__ (subsets are OK)

I understand auto-generating the __hash__ (and __eq__) for a frozen container; that is just convenient. But why is there any desire to autogenerate a __hash__ for something that isn't frozen? Like a list or dict, the normal case would be for it not to have a hash at all, and the author *should*

[Python-Dev] Dataclasses, frozen and __post_init__

On Mon, Feb 19, 2018 at 5:06 PM, Chris Barker - NOAA Federal < chris.barker at noaa.gov> wrote: > If I have this right, on the discussion about frozen and hash, a use > case was brought up for taking a few steps to create an instance (and > thus wanting it not frozen) and then wanting it

[Python-Dev] Nickname Binding (PEP 572)

I think part of the disconnect is that this enhancement could very easily be abused, and it seems likely that it will be, because the problems aren't visible while writing the code -- only when reading it later. I therefore suggest making it very clear in the PEP -- and probably in PEP 8 -- how

  1   2   3   >