Re: [Python-Dev] What is the design purpose of metaclasses vs code generating decorators? (was Re: PEP 557: Data Classes)

On Fri, Oct 13, 2017, at 02:30, Nick Coghlan wrote: > Metaclasses currently tend to serve two distinct purposes: > > 1. Actually altering the runtime behaviour of a class and its children >in non-standard ways (e.g. enums, ABCs, ORMs) > 2. Boilerplate reduction in class definitions, reducing th

Re: [Python-Dev] iso8601 parsing

On Wed, Oct 25, 2017, at 16:32, Alexander Belopolsky wrote: > This is annoying when you deal with time > series where it is common to have text files with a mix of dates, > timestamps and numbers. You can write generic code to deal with ints > and floats, but have to special-case anything time rel

Re: [Python-Dev] The current dict is not an "OrderedDict"

On Tue, Nov 7, 2017, at 09:56, Steven D'Aprano wrote: > Don't let the perfect be the enemy of the good. > > For many applications, keys are never removed from the dict, so this > doesn't matter. If you never delete a key, then the remaining keys will > never be reordered. > > I think that Nick'

Re: [Python-Dev] Proposal: go back to enabling DeprecationWarning by default

On Tue, Nov 7, 2017, at 07:22, Nick Coghlan wrote: > My suggestion for that definition is to have the *default* meaning of > "third party code" be "everything that isn't __main__". What is __main__? Or, rather, how do you determine when it is to blame? For syntax it's easy, but any deprecated func

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

On Tue, Nov 28, 2017, at 15:31, Raymond Hettinger wrote: > > > I also cc python-dev to see if anybody here is strongly in favor or against > > this inclusion. > > Put me down for a strong -1. The proposal would occasionally save a few > keystokes but comes at the expense of giving Python a mor

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

On Thu, Nov 30, 2017, at 11:08, Eric Fahlgren wrote: > On Thu, Nov 30, 2017 at 2:48 AM, Andrea Griffini wrote: > > > Not really related but the PEP says that arguments in Python are evaluated > > before the function (as a reason to reject the idea of None-aware function > > call) but this is not

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

On Thu, Nov 30, 2017, at 17:26, Greg Ewing wrote: > Eric Fahlgren wrote: > > ​I think you're missing something here, since it seems clear to me that > > indeed the arguments are evaluated prior to the function call.​ > > I think the OP may be confusing "evaluating the function" with > "calling th

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

On Fri, Dec 1, 2017, at 05:31, Steven D'Aprano wrote: > I'm more confused than ever. You seem to be arguing that Python > functions CAN short-circuit their arguments and avoid evaluating them. > Is that the case? > If this is merely about when the name "function" is looked up, then I > don't se

Re: [Python-Dev] Usefulness of binary compatibility accross Python versions?

On Sat, Dec 16, 2017, at 08:22, Antoine Pitrou wrote: > Typically, when adding a tp_XXX slot, you also need to add a > Py_TPFLAGS_HAVE_XXX type flag to signal those static type structures > that have been compiled against a recent enough PyTypeObject > definition. This way, extensions compiled aga

Re: [Python-Dev] Usefulness of binary compatibility accross Python versions?

On Mon, Dec 18, 2017, at 05:23, Antoine Pitrou wrote: > On Sun, 17 Dec 2017 21:07:02 -0500 > Random832 wrote: > > > > Is there any practical for of having the flag off for one slot and on > > for another slot that's been added later? > > > > Could thi

Re: [Python-Dev] Whatever happened to 'nonlocal x = y'?

On Fri, Jan 5, 2018, at 10:47, Guido van Rossum wrote: > I don't recall (though someone with more time might find the discussion in > the archives or on the tracker). It was never implemented and I think it > shouldn't be. So we might as well update the PEP. It wouldn't be > particularly useful, si

Re: [Python-Dev] Whatever happened to 'nonlocal x = y'?

On Fri, Jan 5, 2018, at 14:07, Guido van Rossum wrote: > Yeah, but I've changed my mind on this -- I think it's needless added > complexity that helps save one line of code in very few use cases. And you > don't really think the PEP endorses `nonlocal foo += 1` do you? The PEP itself is very clear

Re: [Python-Dev] subprocess not escaping "^" on Windows

On Sun, Jan 7, 2018, at 19:50, Steve Dower wrote: > Considering there is no cross-platform compatibility here anyway, I > don’t think it’s that bad an option to let users do their own escaping, > especially since those who are successfully using this feature already > do. I don't really think w

Re: [Python-Dev] Best Python API for exposing posix_spawn

On Mon, Jan 8, 2018, at 18:05, Gregory P. Smith wrote: > i agree with just a list of tuples, but i suggest creating namedtuple > instances in the posix module for the purpose (one each for close, dup2, > open) . Don't put a reference to a function in the tuple as Serhiy > suggested as, while obvio

Re: [Python-Dev] Deprecate PEP 370 Per user site-packages directory?

On Sat, Jan 13, 2018, at 12:06, Christian Heimes wrote: > Hi, > > PEP 370 [1] was my first PEP that got accepted. I created it exactly one > decade and two days ago for Python 2.6 and 3.0. Back then we didn't have > virtual environment support in Python. Ian Bicking had just started to > create th

Re: [Python-Dev] Exposing different versions of a system call in Python

On Fri, Jan 19, 2018, at 04:28, Pablo Galindo Salgado wrote: > On the other side, we have pipe and pipe2 as an example of exposing two > versions when this situation happens. > > The question is: > > What is preferable, exposing both functions or augment the old one? A large number, possibly a m

Re: [Python-Dev] PEP 495 Was: PEP 498: Literal String Interpolation is ready for pronouncement

Alexander Belopolsky writes: > There is no "earlier" or "later". There are "lesser" and "greater" > which are already defined for all pairs of aware datetimes. PEP 495 > doubles the set of possible datetimes That depends on what you mean by "possible". > and they don't fit in one > straight line

Re: [Python-Dev] PEP 495 Was: PEP 498: Literal String Interpolation is ready for pronouncement

Alexander Belopolsky writes: > Yes, but it does that at the cost of introducing the second local > "01:30" which is "later" than the first "01:40" while "obviously" (and > according to the current datetime rules) "01:30" < "01:40". The current datetime rules, such as they are, as far as I am awar

Re: [Python-Dev] PEP 495 Was: PEP 498: Literal String Interpolation is ready for pronouncement

MRAB writes: > What would happen if it's decided to stay on DST and then, later on, to > reintroduce DST? > > Or what would happen in the case of "British Double Summer Time" (go > forward twice in the spring and backward twice in the autumn)? > > https://en.wikipedia.org/wiki/British_Summer_Time

Re: [Python-Dev] Rationale behind lazy map/filter

"R. David Murray" writes: > On Tue, 13 Oct 2015 14:59:56 +0300, Stefan Mihaila > wrote: >> Maybe it's just python2 habits, but I assume I'm not the only one >> carelessly thinking that "iterating over an input a second time will >> result in the same thing as the first time (or raise an error)"

Re: [Python-Dev] Rationale behind lazy map/filter

"R. David Murray" writes: > On Tue, 13 Oct 2015 11:26:09 -0400, Random832 wrote: >> It does raise the question though of what working code it would actually >> break to have "exhausted" iterators raise an error if you try to iterate >> them again rather

Re: [Python-Dev] PEP 0484 - the Numeric Tower

> From Lib/numbers.py: > > ## Notes on Decimal > ## > ## Decimal has all of the methods specified by the Real abc, but it should > ## not be registered as a Real because decimals do not interoperate with > ## binary floats (i.e. Decimal('3.14') + 2.71828 is undefined). But, > ##

Re: [Python-Dev] Rationale behind lazy map/filter

Chris Angelico writes: > A well-behaved iterator is supposed to continue raising StopIteration > forever once it's been exhausted. Yes, and that is *precisely* the behavior that causes the problem under discussion. My question was what code depends on this. > Play with that, and see where Runtim

Re: [Python-Dev] PEP 0484 - the Numeric Tower

Steven D'Aprano writes: > On Tue, Oct 13, 2015 at 04:37:43PM -0700, Raymond Hettinger wrote: > >> We could have (and still could) make the choice to always coerce to >> decimal (every float is exactly representable in decimal). Further, >> any decimal float or binary float could be losslessly

Re: [Python-Dev] PEP 506 secrets module

Brian Gladman writes: >> On Sat, Oct 17, 2015 at 03:26:46AM +1100, Steven D'Aprano wrote: > I hence support your conclusion that the module should offer randbelow > alone. I would oppose offering randomrange (or offering more than one > of them) since this will pretty well guarantee that, sooner

Re: [Python-Dev] PEP 506 secrets module

Guido van Rossum writes: > On Sat, Oct 17, 2015 at 2:50 AM, Steven D'Aprano > wrote: > > [...] > So you can see there is nothing even close to consensus as to > which API > is best, which is an argument for keeping all three functions. > > No, that's not how we do it in Python. :

Re: [Python-Dev] [Python-checkins] Daily reference leaks (d7e490db8d54): sum=61494

Raymond Hettinger writes: > Thanks for hunting this down. I had seen the automated reference leak > posts but didn't suspect that a pure python class would have caused > the leak. > > I'm re-opening > https://mail.python.org/pipermail/python-dev/2015-October/141993.html > and will take a look at

Re: [Python-Dev] PEP 484 -- proposal to allow @overload in non-stub files

Guido van Rossum writes: > The proposal is to allow this to be written as follows in > implementation (non-stub) modules: > > class Foo(Generic[T]): > @overload > def __getitem__(self, i: int) -> T: ... > @overload > def __getitem__(self, s: slice) -> Foo[T]: ... > def __getitem__(self, x): > > >

Re: [Python-Dev] Support of UTF-16 and UTF-32 source encodings

Victor Stinner writes: > These encodings are rarely used. I don't think that any text editor > use them. MS Windows' Notepad can be made to use UTF-16. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-de

Re: [Python-Dev] Support of UTF-16 and UTF-32 source encodings

Chris Angelico writes: > Can the py.exe launcher handle a UTF-16 shebang? (I'm pretty sure Unix > program loaders won't.) A lot of them can't handle UTF-8 with a BOM, either. > That alone might be a reason for strongly encouraging ASCII-compat > encodings. A "python" or "python3" or "env" execu

Re: [Python-Dev] Support of UTF-16 and UTF-32 source encodings

Glenn Linderman writes: > On 11/14/2015 5:37 PM, Chris Angelico wrote: > > Thanks. Is "ANSI" always an eight-bit ASCII-compatible encoding? > > I wouldn't trust an answer to this question that didn't come from > someone that used Windows with Chinese, Japanese, or Korean, as their > default langua

Re: [Python-Dev] Support of UTF-16 and UTF-32 source encodings

"Stephen J. Turnbull" writes: > I don't see any good reason for allowing non-ASCII-compatible > encodings in the reference CPython interpreter. There might be a case for having the tokenizer not care about encodings at all and just operate on a stream of unicode characters provided by a different

Re: [Python-Dev] Reading Python source file

MRAB writes: > As I understand it, *nix expects the shebang to be b'#!', > which means that the first line should be ASCII-compatible > (it's possible that the UTF-8 BOM might be present). The UTF-8 BOM interferes with it on Mac OSX and Linux, at least. __

Re: [Python-Dev] Deleting with setting C API functions

On 2015-12-02, M.-A. Lemburg wrote: > A first step would be to replace the macro with a proper function > to avoid false positive warnings, even when using the correct API. > > Then we could add a warning to the PyObject_SetAttr() function and > hope that not too many projects use the stable ABI a

Re: [Python-Dev] Deleting with setting C API functions

On 2015-12-02, Victor Stinner wrote: >> Are there plans for a Python 4? > > No. Don't. Don't schedule any "removal" or *any* kind of "break > backward compatibility" anymore, or you will definetly kill the Python > community. I feel like I should note that I agree with your position here, I was j

Re: [Python-Dev] Deleting with setting C API functions

On 2015-12-02, Andrew Barnert wrote: > Python could just go from 3.9 to 4.0, as a regular dot release, just > to dispel the idea of an inevitable backward-incompatible "Python 4". > (That should be around 2 years after the expiration of 2.7 support, > py2/py3 naming, etc., right?) Why bother with

Re: [Python-Dev] Python Language Reference has no mention of list comÃprehensions

On 2015-12-03, Laura Creighton wrote: > Who came up with the word 'display' and what does it have going for > it that I have missed? Right now I think its chief virtue is that > it is a meaningless noun. (But not meaningless enough, as I > associate displays with output, not construction). In a

Re: [Python-Dev] New poll about a macro for safe reference replacing

Serhiy Storchaka writes: > I'm bringing this up again, since the results of the previous poll did > not give an unambiguous result. Related links: [1], [2], [3], [4]. > > Let me remind you that we are talking about adding the following > macro. It is needed for safe replacement links. For now ther

Re: [Python-Dev] New poll about a macro for safe reference replacing

Serhiy Storchaka writes: >> I'm not entirely sure of the benefit of a macro over an inline >> function. > > Because the first argument is passed by reference (as in Py_INCREF > etc). Then a macro implemented using an inline function, e.g., #define Py_REPLACE(p, x) Py_REPLACE_impl(&(p), x). Were

Re: [Python-Dev] Change the repr for datetime.timedelta (was Re: Asynchronous context manager in a typical network server)

Guido van Rossum writes: > I'm sure that one often catches people by surprise. However, I don't > think we can fix that one without also fixing the values of the > attributes -- in that example days is -1 and seconds is 86340 (which > will *also* catch people by surprise). And changing that would

Re: [Python-Dev] New poll about a macro for safe reference replacing

Nick Coghlan writes: > Avoiding those misleading associations is a good argument in favour of > Py_REPLACE over Py_SETREF - they didn't occur to me before casting my > votes, and I can definitely see them causing confusion in the future. > > So perhaps the combination that makes the most sense is

Re: [Python-Dev] do people use sys._mercurial?

Brett Cannon writes: > (and no, we are not going to adopt a generic one; already had that > debate). Do you have a link to the relevant discussions? ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev U

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

On Mon, Apr 11, 2016, at 13:36, Brett Cannon wrote: > How about we take something from the "explicit is better than implicit" > playbook and add a keyword argument to os.fspath() to allow bytes to pass > through? Except, we already know how to convert a bytes-path into a str (and vice versa) with

Re: [Python-Dev] Maybe, just maybe, pathlib doesn't belong.

On Mon, Apr 11, 2016, at 16:48, Sven R. Kunze wrote: > On 11.04.2016 22:33, Alexander Walters wrote: > > If there is headway being made, I do not see it. > > Funny that you brought it up. I was about posting something myself. I > cannot agree completely. But starting with a comment from Paul, I

Re: [Python-Dev] Maybe, just maybe, pathlib doesn't belong.

On Mon, Apr 11, 2016, at 17:04, Sven R. Kunze wrote: > PS: The only way out that I can imagine is to fix pathlib. I am not in > favor of fixing functions of "os" and "os.path" to except "path" > objects; Why not? ___ Python-Dev mailing list Python-Dev@

Re: [Python-Dev] Maybe, just maybe, pathlib doesn't belong.

On Mon, Apr 11, 2016, at 17:15, Ethan Furman wrote: > So we're trying to make option 2 work before falling back to option 1. > > If you have a way to make pathlib work with the stdlib that doesn't > involve "fixing" os and os.path, now is the time to speak up. Fully general re-dispatch from argu

Re: [Python-Dev] Maybe, just maybe, pathlib doesn't belong.

On Tue, Apr 12, 2016, at 10:52, Sven R. Kunze wrote: > On 12.04.2016 00:56, Random832 wrote: > > Fully general re-dispatch from argument types on any call to a function > > that raises TypeError or NotImplemented? [e.g. call > > Path.__missing_func__(os.open, path, mode)]

Re: [Python-Dev] pathlib - current status of discussions

On Tue, Apr 12, 2016, at 12:40, Chris Barker wrote: > Ah -- there's the fatal flaw -- even Windows needs bytes at the lowest > level, Only in the sense that literally everything's bytes at the lowest level. But the bytes Windows needs are not in an ASCII-compatible encoding so it's not reasonable

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

On Wed, Apr 13, 2016, at 10:21, Nick Coghlan wrote: > I'd expect the main consumers to be os and os.path, and would honestly > be surprised if we needed many explicit invocations above that layer, > other than in pathlib itself. I made a toy implementation to try this out, and making os.open suppo

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

On Wed, Apr 13, 2016, at 11:28, Ethan Furman wrote: > On 04/13/2016 08:17 AM, Random832 wrote: > > On Wed, Apr 13, 2016, at 10:21, Nick Coghlan wrote: > > >> I'd expect the main consumers to be os and os.path, and would honestly > >> be surprised if we needed m

Re: [Python-Dev] pathlib - current status of discussions

On Wed, Apr 13, 2016, at 15:24, Chris Angelico wrote: > Is that the intention, or should the exception catching be narrower? I > know it's clunky to write it in Python, but AIUI it's less so in C: How is it less so in C? You lose the ability to PyObject_CallMethod.

Re: [Python-Dev] pathlib - current status of discussions

On Wed, Apr 13, 2016, at 16:39, Chris Barker wrote: > so are we worried that __fspath__ will exist and be callable, but might > raise an AttributeError somewhere inside itself? if so isn't it broken > anyway, so should it be ignored? Well, if you're going to say "ignore the protocol because it's

Re: [Python-Dev] pathlib - current status of discussions

On Apr 13, 2016 20:06, Chris Barker wrote: > > In this case, I don't know that we need to be tolerant of buggy __fspathname__() implementations -- they should be tested outside these checks, and not be buggy. So a buggy implementation may raise and may be ignored, depending on what Exception the

Re: [Python-Dev] pathlib - current status of discussions

On Apr 13, 2016 19:06, Brett Cannon wrote: > On Wed, 13 Apr 2016 at 15:46 Nikolaus Rath wrote: >> When passing an object that is of type str and has a __fspath__ >> attribute, all approaches return the value of __fspath__(). >> >> However, when passing something of type bytes, the second approac

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

On Wed, Apr 13, 2016, at 23:17, Nick Coghlan wrote: > - os.fspath -> str (no coercion) > - os.fsdecode -> str (with coercion from bytes) > - os.fsencode -> bytes (with coercion from str) > - os._raw_fspath -> str-or-bytes (no coercion) > > (with "coercion" referring to how the result of __fspath_

Re: [Python-Dev] pathlib - current status of discussions

On Wed, Apr 13, 2016, at 23:27, Nick Coghlan wrote: > In this kind of case, inheritance tends to trump protocol. For > example, int subclasses can't override operator.index: ... > The reasons for that behaviour are more pragmatic than philosophical: > builtins and their subclasses are extensively s

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

On Thu, Apr 14, 2016, at 02:00, Nick Coghlan wrote: > > If the protocol can return bytes, then that means that types (DirEntry? > > someone had an alternate path library with a bPath?) which return bytes > > via the protocol will proliferate, and cannot be safely passed to > > anything that uses os

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

On Thu, Apr 14, 2016, at 03:02, Stephen J. Turnbull wrote: > I have a strong preference for str only, because I still don't see a > use case for polymorphic __fspath__. Ultimately we're talking about redundancy and performance here. The "use case" such as there is one, is if there's a class (be it

Re: [Python-Dev] pathlib - current status of discussions

On Thu, Apr 14, 2016, at 09:40, Nick Coghlan wrote: > That's not a *new* problem though, it already exists if you pass in a > mix of bytes and str: > > There's also already a solution (regardless of whether you want bytes > or str as the result), which is to explicitly coerce all the arguments > t

Re: [Python-Dev] pathlib - current status of discussions

On Thu, Apr 14, 2016, at 09:50, Chris Angelico wrote: > Adding integers and floats is considered "safe" because most people's > use of floats completely compasses their use of ints. (You'll get > OverflowError if it can't be represented.) But float and Decimal are > considered "unsafe": > > >>> 1.

Re: [Python-Dev] pathlib - current status of discussions

On Thu, Apr 14, 2016, at 12:05, Stephen J. Turnbull wrote: > Random832 writes: > > > And what such incompatibilities exist between bytes and str for the > > purpose of representing file paths? > > A plethora of encodings. Only one encoding, fsencode/fsdecode. All oth

Re: [Python-Dev] MAKE_FUNCTION simplification

On Thu, Apr 14, 2016, at 12:56, Terry Reedy wrote: > https://docs.python.org/3/library/dis.html#module-dis > CPython implementation detail: Bytecode is an implementation detail of > the CPython interpreter. No guarantees are made that bytecode will not > be added, removed, or changed between vers

Re: [Python-Dev] pathlib - current status of discussions

On Thu, Apr 14, 2016, at 13:56, Koos Zevenhoven wrote: > (1) Code that has access to pathname/filename data and has some level > of control over what data type comes in. This code may for instance > choose to deal with either bytes or str > > (2) Code that takes the path or file name that it happe

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

On Fri, Apr 15, 2016, at 16:41, Victor Stinner wrote: > If the dictionary values are modified during the loop, the dict > version is increased. But it's allowed to modify values when you > iterate on *keys*. Why is iterating over items different from iterating over keys? in other words, why do I

Re: [Python-Dev] PEP 8 updated on whether to break before or after a binary update

On Fri, Apr 15, 2016, at 23:46, Peter Ludemann via Python-Dev wrote: > If Python ever adopts the BCPL rule for implicit line continuation if > the last thing on a line is an operator (or if there's an open > parentheses), then the break-after-an-operator rule would be more > persuasive. ;) > > [IIR

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

On Mon, Apr 18, 2016, at 15:26, Stephen J. Turnbull wrote: > in > particular it is not true for DirEntry (which is a "enhanced > degenerate" path containing only one path segment but also other > useful information abot the filesystem object addressed) DirEntry contains multiple path segments -

Re: [Python-Dev] Inconsistency of PyModule_AddObject()

On Thu, Apr 28, 2016, at 05:05, Stefan Krah wrote: > $ valgrind --suppressions=Misc/valgrind-python.supp ./python -c "import > decimal" > > [...] > ==16945== LEAK SUMMARY: > ==16945==definitely lost: 0 bytes in 0 blocks > Well, the obvious fla

Re: [Python-Dev] Inconsistency of PyModule_AddObject()

On Thu, Apr 28, 2016, at 10:11, Stefan Krah wrote: > For actual users of Valgrind this is patently obvious and was > pretty much the point of my post. A more relevant point would be that _decimal does *not* use the API in a way *which would be broken by the proposed change*, regardless of whether

Re: [Python-Dev] Convert int() to size_t in Python/C

On Fri, Apr 29, 2016, at 10:45, Marcos Dione wrote: > One possible solution hat was suggested to me in the #python IRC > channel was to use that, then test if the resulting value is negative, > and adjust accordingly, but I wonder if there is a cleaner, more general > solution (for instance, wh

Re: [Python-Dev] Convert int() to size_t in Python/C

On Fri, Apr 29, 2016, at 14:11, Marcos Dione wrote: > These are not output parameters, even if they're pointers. they'r > using the NULL pointer to signal that the current offsets should not be > touched, to differentiate from a offset of 0. Something that in Python we > would use None. That's

Re: [Python-Dev] File system path PEP, part 2

On Fri, May 13, 2016, at 07:00, Steven D'Aprano wrote: > - but os.fspath() will only return str; > > - and os.fspathb() will only return bytes; And raise an exception if __fspath__ returns the other, I suppose. What's the use case for these functions? When would I call them rather than fsdecode a

Re: [Python-Dev] Why does PEP 7/8 explicitly suggest 2 spaces after a period?

On Sun, May 22, 2016, at 11:15, Peter Ludemann via Python-Dev wrote: > I just tried a re-flow in emacs (M-q or fill-paragraph) and it didn't > change my single space to two (it also changed 3 spaces after a period > to 2; and it preserved my hanging indents). It won't change a single space to two,

Re: [Python-Dev] C99

On Mon, Jun 6, 2016, at 07:23, Sturla Molden wrote: > Ok, but if third-party developers shall be free to use a C89 compiler for > their own code, we cannot have C99 in the include files. Otherwise the > include files will taint the C89 purity of their source code. > > Personally I don't think we n

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

On Wed, Jul 11, 2018, at 20:10, Guido van Rossum wrote: > As anticippated, after a final round of feedback I am hereby accepting PEP > 572, Assignment Expressions: https://www.python.org/dev/peps/pep-0572/ I know everyone else is probably sick of discussing this (I somehow completely missed the d

Re: [Python-Dev] PEP 594: Removing dead batteries from the standard library

On Tue, May 21, 2019, at 14:17, Christian Heimes wrote: > thanks for bringing this topic up. Initially I considered http.server, > too. But as Guido put it, it's both used and useful for local testing > and quick hacks. I'm already facing opposition for modules that are > less controversial and

Re: [Python-Dev] PEP 594: update 1

On Thu, May 23, 2019, at 15:27, Steve Holden wrote: > Besides which, it would be lovely to have a major release that didn't > involve any pain at all for the majority of users! > > Our erstwhile BDFL always eschewed two-digit version identifiers- due > to the possibility for confusion about coll

Re: [Python-Dev] [PEP 558] thinking through locals() semantics

On Wed, May 29, 2019, at 01:25, Nick Coghlan wrote: > Having a single locals() call de-optimize an entire function would be > far from ideal. What if there were a way to explicitly de-optimize a function, rather than guessing the user's intent based on looking for locals and exec calls (both of

[Python-Dev] Re: Comparing dict.values()

On Fri, Jul 26, 2019, at 00:22, Ivan Pozdeev via Python-Dev wrote: > Since a hash table is an unordered container and keys(), items() and > values() are iterators over it, *I would expect the results of any of > the comparisons to be undefined.* keys, items, and values are not iterators. They ar

[Python-Dev] Re: Comparing dict.values()

On Fri, Jul 26, 2019, at 05:45, Steven D'Aprano wrote: > Nor should we make too much of the fact that Python sets require > elements to be hashable. As Java TreeSet demonstrates, we could get an > efficient set of unhashable items if we required orderability; and we > can get sets of unhashable,

[Python-Dev] Re: What to do about invalid escape sequences

On Mon, Aug 5, 2019, at 00:29, raymond.hettin...@gmail.com wrote: > The warning crops up frequently, often due to > third-party packages (such as docutils and bottle) that users can't > easily do anything about. And during live demos and student workshops, > it is especially distracting. Maybe

[Python-Dev] Re: os.scandir bug in Windows?

On Mon, Oct 19, 2020, at 07:42, Steve Dower wrote: > On 15Oct2020 2239, Rob Cliffe via Python-Dev wrote: > > TLDR: In os.scandir directory entries, atime is always a copy of mtime > > rather than the actual access time. > > Correction - os.stat() updates the access time to _now_, while > os.scan

[Python-Dev] Re: PEP 638: Syntactic macros

On Fri, Oct 16, 2020, at 18:59, Dan Stromberg wrote: > The complexity of a language varies with the square of its feature > count, Says who? I'd assume the orthogonality and regularity of features matters at least as much if not more than the number of features, and providing a system like this

[Python-Dev] Re: os.scandir bug in Windows?

On Tue, Oct 20, 2020, at 07:42, Steve Dower wrote: > On 20Oct2020 0520, Rob Cliffe wrote: > > On 19/10/2020 12:42, Steve Dower wrote: > >> On 15Oct2020 2239, Rob Cliffe via Python-Dev wrote: > >>> TLDR: In os.scandir directory entries, atime is always a copy of > >>> mtime rather than the actual a

[Python-Dev] Re: os.scandir bug in Windows?

On Fri, Oct 23, 2020, at 02:14, Random832 wrote: > What correction, exactly, do you mean? The post I saw with the word > "Correction" on it is the one that *makes* the claim people are taking > issue with. okay, sorry, I see the other correction post now... My issue I gu

[Python-Dev] Re: New sys.module_names attribute in Python 3.10: list of all stdlib modules

On Mon, Jan 25, 2021, at 18:44, Chris Jerdonek wrote: > But to issue a warning when a standard module is being overridden like > I was suggesting, wouldn’t you also need to know whether the name of > the module being imported is a standard name, which is what > says.module_names provides? I don

[Python-Dev] Re: Why aren't we allowing the use of C11?

On Thu, Jan 28, 2021, at 22:57, Emily Bowman wrote: > > On Thu, Jan 28, 2021 at 1:31 PM MRAB wrote: > > I have Microsoft Visual Studio Community 2019 Version 16.8.4 (it's free) > > and it supports C11 and C17. > > While an upgrade for Community is free, for Pro/Enterprise without an > annual

[Python-Dev] Have virtual environments led to neglect of the actual environment?

I was reading a discussion thread about various issues with the Debian packaged version of Python, and the following statement stood out for me as shocking: Christian Heimes wrote: > Core dev and PyPA has spent a lot of effort in

[Python-Dev] Re: Have virtual environments led to neglect of the actual environment?

On Wed, Feb 24, 2021, at 06:27, Christian Heimes wrote: > Separate directories don't prevent clashes and system breakage. But they > provide an easy way to *recover* from a broken system. I think it could be turned into a way to prevent them by A) having site-packages always take precedence over

[Python-Dev] Re: [Python-ideas] Re: Re: Have virtual environments led to neglect of the actual environment?

On Wed, Feb 24, 2021, at 09:08, Paul Moore wrote: > I don't use Linux much, and I'm definitely not familiar with Linux > distribution tools, but from what I can gather Linux distributions > have made the choices: > > 1. Write key operating system utilities in Python. > 2. Share the Python interpre

Re: [Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits?

On Fri, Jun 10, 2016, at 15:54, Theodore Ts'o wrote: > So even on Python pre-3.5.0, realistically speaking, the "weakness" of > os.random would only be an issue (a) if it is run within the first few > seconds of boot, and (b) os.random is used to directly generate a > long-term cryptographic secret

Re: [Python-Dev] Stop using timeit, use perf.timeit!

On Fri, Jun 10, 2016, at 21:45, Steven D'Aprano wrote: > If you express your performances as speeds (as "calculations per > second") then the harmonic mean is the right way to average them. That's true in so far as you get the same result as if you were to take the arithmetic mean of the times an

Re: [Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits?

On Sat, Jun 11, 2016, at 22:37, Theodore Ts'o wrote: > On Fri, Jun 10, 2016 at 05:14:50PM -0400, Random832 wrote: > > So, I have a question. If this "weakness" in /dev/urandom is so > > unimportant to 99% of situations... why isn't there a flag that can be >

Re: [Python-Dev] Why does base64 return bytes?

On Tue, Jun 14, 2016, at 13:05, Joao S. O. Bueno wrote: > Sorry, it is 2016, and I don't think at this point anyone can consider > an ASCII string > as a representative pattern of textual data in any field of application. > Bytes are not text. Bytes with an associated, meaningful, encoding are > te

Re: [Python-Dev] Why does base64 return bytes?

On Tue, Jun 14, 2016, at 13:19, Paul Sokolovsky wrote: > Well, it's easy to remember the conclusion - it was decided to return > bytes. The reason also wouldn't be hard to imagine - regardless of the > fact that base64 uses ASCII codes for digits and letters, it's still > essentially a binary data.

Re: [Python-Dev] Why does base64 return bytes?

On Tue, Jun 14, 2016, at 22:58, Stephen J. Turnbull wrote: > The RFC is unclear on this point, but I read it as specifying the > ASCII coded character set, not the ASCII repertoire of (abstract) > characters. Therefore, it specifies an invertible mapping from a > particular set of integers to char

Re: [Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits?

On Thu, Jun 16, 2016, at 04:03, Barry Warsaw wrote: > *If* we can guarantee that os.urandom() will never block or raise an > exception when only poor entropy is available, then it may be indeed > indistinguishably backward compatible for most if not all cases. Why can't we exclude cases when only

Re: [Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits?

On Thu, Jun 16, 2016, at 10:04, Barry Warsaw wrote: > On Jun 16, 2016, at 09:51 AM, Random832 wrote: > > >On Thu, Jun 16, 2016, at 04:03, Barry Warsaw wrote: > >> *If* we can guarantee that os.urandom() will never block or raise an > >> exception when only poor ent

Re: [Python-Dev] Our responsibilities (was Re: BDFL ruling request: should we block forever waiting for high-quality random bits?)

On Thu, Jun 16, 2016, at 07:34, Donald Stufft wrote: > python-dev tends to favor not breaking “working” code over securing > existing APIs, even if “working” is silently doing the wrong thing > in a security context. This is particularly frustrating when it > comes to security because

[Python-Dev] Why are class dictionaries not accessible?

The documentation states: """Objects such as modules and instances have an updateable __dict__ attribute; however, other objects may have write restrictions on their __dict__ attributes (for example, classes use a dictproxy to prevent direct dictionary updates).""" However, it's not clear from tha

Re: [Python-Dev] When to use EOFError?

On Tue, Jun 21, 2016, at 16:48, Serhiy Storchaka wrote: > There is a design question. If you read file in some format or with some > protocol, and the data is ended unexpectedly, when to use general > EOFError exception and when to use format/protocol specific exception? > > For example when loa

  1   2   >