[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

[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] 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: 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 >

[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

[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

[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

[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

[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 >

[Python-Dev] Re: Do we still need a support of non-type objects in issubclass()?

On Sat, Oct 3, 2020, at 04:41, Serhiy Storchaka wrote: > Should we continue to support non-type objects with __bases__ in > issubclass()? If no, can we remove their support in 3.10 (it would fix a > crash in issue41909) or after passing a deprecation period? Er, to be clear, contrary to the

[Python-Dev] Re: Hygenic macros PEP.

On Tue, Sep 15, 2020, at 15:22, Mark Shannon wrote: > > Hi all, > > I'd like to propose a new PEP for hygienic macros. To be clear, "hygienic macros" doesn't *just* mean AST-rewriting macros, it also means being able to define variables within the macro expansion that can't possibly collide

[Python-Dev] Re: Memory address vs serial number in reprs

On Sun, Jul 19, 2020, at 13:02, Guido van Rossum wrote: > That looks expensive, esp. for objects implemented in Python — an extra > dict entry plus a new unique int object. What is the problem you are > trying to solve for these objects specifically? Just that the hex > numbers look distracting

[Python-Dev] Re: Recent PEP-8 change

On Thu, Jul 2, 2020, at 18:15, Antoine Pitrou wrote: > On Thu, 02 Jul 2020 17:58:44 -0400 > Random832 wrote: > > Why indeed? > > Because we're talking about PEP 8, and PEP 8 intends to cover the code > style used when writing code in the *Python standard library*. ok, firs

[Python-Dev] Re: Recent PEP-8 change

On Thu, Jul 2, 2020, at 05:20, Antoine Pitrou wrote: > We're not talking about posting "your own writing", we're talking about > comments (and presumably documentation) in a collective software > project. There's a need for consistency, however it's > specified and achieved. > > Otherwise why

[Python-Dev] Re: Emit a SyntaxWarning for unhashables literals in hashable dependant literals.

On Fri, Dec 13, 2019, at 02:20, mental na via Python-Dev wrote: > Guido van Rossum wrote: > > This is most definitely a language issue, not just a CPython issue -- the > > rules around hashability and (im)mutability are due to the language > > definition, not the whim of an implementer. > > I was

[Python-Dev] PEP 611 - saturating reference counts

as an aside in the portion of PEP 611 proposing a limit to the number of classes, the proposal also mentioned reducing the size of the reference count field to achieve part of its object size savings. one of the mechanisms proposed was to implement a "saturating" reference count, though it

[Python-Dev] Re: PEP proposal to limit various aspects of a Python program to one million.

On Tue, Dec 3, 2019, at 12:22, Steve Dower wrote: > > * The number of constants in a code object. > > SGTM. Two things... First, for this one in particular, the number of constants in a code object is hard to predict. For example, recently (I want to say 3.7), the number of constants

[Python-Dev] Re: Pass the Python thread state to internal C functions

On Mon, Nov 18, 2019, at 05:26, Antoine Pitrou wrote: > > For the first goal, I don't think this is possible, or desirable. > > Obviously if we remove the GIL somehow then at a minimum we'll need to > > make the global threadstate a thread-local. But I think we'll always > > have to keep it around

[Python-Dev] Re: Pass the Python thread state to internal C functions

On Thu, Nov 14, 2019, at 07:43, Antoine Pitrou wrote: > On Wed, 13 Nov 2019 14:52:32 +0100 > Victor Stinner wrote: > > > > #define _PyRuntimeState_GetThreadState(runtime) \ > > > > ((PyThreadState*)_Py_atomic_load_relaxed(&(runtime)->gilstate.tstate_current)) > > #define

[Python-Dev] Re: Migrate typing in builtin

On Mon, Oct 7, 2019, at 12:02, Philippe Prados wrote: > Because this PEP propose to accept, for all classes > assert isinstance("", int | str) > assert issubclass(int, int | str) > and add an operator __or__() for type type. > def f(list: List[int | str], param: int | None) -> float | str: >

[Python-Dev] Re: Migrate typing in builtin

On Mon, Oct 7, 2019, at 10:32, Philippe Prados wrote: > Hello, > > I try to implement a *proof of concept* of Pep-0604 > . > > To do this, the _GenericAlias must be in builtin, because I would like > to update issubclass() and isinstance() to accept

[Python-Dev] Re: An f-string issue [Was: Re: Re: What to do about invalid escape sequences]

On Sat, Aug 10, 2019, at 19:54, Glenn Linderman wrote: > Because of the "invalid escape sequence" and "raw string" discussion, > when looking at the documentation, I also noticed the following > description for f-strings: > > > Escape sequences are decoded like in ordinary string literals

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

On Mon, Aug 12, 2019, at 15:15, Terry Reedy wrote: > Please no more combinations. The presence of both legal and illegal > combinations is already a mild nightmare for processing and testing. > idlelib.colorizer has the following re to detest legal combinations > > stringprefix =

[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.

[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

[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

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

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

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] 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

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

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

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

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

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

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,

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 <random...@fastmail.com> wrote: > > > > Is there any practical for of having the flag off for one slot and on > > for another slot that's been added later? &

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

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

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

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)

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

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

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

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

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

Re: [Python-Dev] Need help to fix urllib(.parse) vulnerabilities

On Fri, Jul 21, 2017, at 08:43, Giampaolo Rodola' wrote: > It took me a while to understand the security implications of this > FTP-related bug, but I believe I got the gist of it here (I can > elaborate further if it's not clear): >

Re: [Python-Dev] Format strings, Unicode, and Py2.7: need clarification

On Thu, May 18, 2017, at 01:14, Hobson Lane wrote: > Because `.format()` is a method on an instantiated `str` object in e and > so > must return the same type That it *must* return the same type is overstating the matter. Split returns a list (and, rather like %, the list is of unicode or str

Re: [Python-Dev] PEP 544: Protocols

On Mon, Mar 20, 2017, at 14:07, Brett Cannon wrote: > What is a "trivial body"? I don't know of any such definition anywhere in > Python so this is too loosely defined. You also don't say what happens if > the body isn't trivial. Are tools expected to raise an error? My assumption would be that a

Re: [Python-Dev] PEP 538: Coercing the legacy C locale to a UTF-8 based locale

On Tue, Mar 14, 2017, at 10:17, Nick Coghlan wrote: > It's not that you *can't* run Python 3 in that kind of environment, and > it's not that there are never any valid reasons to do so. It's that lots > of > things that you'd typically expect to work are going to misbehave (one I > discovered

Re: [Python-Dev] Impoverished compare ...

On Thu, Mar 9, 2017, at 18:43, Erik wrote: > Hi. > > I'm looking at stuff proposed over on Python-Ideas, and I'd appreciate > some pointers as to the basics of how C-level objects are generally > compared in Python 3. > > The issue is related to the performance of PyObject_RichCompare. I got

Re: [Python-Dev] List mutation in list_repr?

On Tue, Dec 6, 2016, at 05:27, Patrick Westerhoff wrote: > Hey all, > > I just stumbled on the following comment in the C source of the repr > implementation for the list object: > > /* Do repr() on each element. Note that this may mutate the list, >so must refetch the list size on

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

Re: [Python-Dev] TextIO seek and tell cookies

On Mon, Sep 26, 2016, at 05:30, Ben Leslie wrote: > I think the case of JSON or SQL database is even more important though. > > tell/seek can return 129-bit integers (maybe even more? my maths might > be off here). > > The very large integers that can be returned by tell() will break >

Re: [Python-Dev] Drastically improving list.sort() for lists of strings/ints

On Tue, Sep 13, 2016, at 13:24, Nikolaus Rath wrote: > On Sep 11 2016, Terry Reedy wrote: > > Tim Peters investigated and empirically determined that an > > O(n*n) binary insort, as he optimized it on real machines, is faster > > than O(n*logn) sorting for up to around 64 items.

Re: [Python-Dev] (some) C99 added to PEP 7

On Thu, Sep 8, 2016, at 16:01, Chris Barker wrote: > Is there a "long" in there anywhere in the integer implementation? The python 2 long type is the python 3 int type. The python 2 int type is gone. > I don't have py3 running on win64 anywhere right now, but in win64 py2, > that would give you:

Re: [Python-Dev] PEP 529: Change Windows filesystem encoding to UTF-8

On Thu, Sep 8, 2016, at 13:10, Guido van Rossum wrote: > On Thu, Sep 8, 2016 at 9:57 AM, Brett Cannon wrote: > > Bash on Windows is just Linux, so it isn't affected by any of this. > > I don't know what that sentence means. It means that the so-called "bash" on windows 10 is

Re: [Python-Dev] (some) C99 added to PEP 7

On Thu, Sep 8, 2016, at 12:30, Chris Barker wrote: > That's why I said "based on" -- under the hood, a C type is used, and > IIUC, that type has been "long" for ages. And a long on Windows 64 > (with the MS compiler anyway) is 32 bit, and a long on *nix (with the > gnu compilers, at least) is 64

Re: [Python-Dev] PEP 528: Change Windows console encoding to UTF-8

On Tue, Sep 6, 2016, at 06:34, Martin Panter wrote: > Yes, that was basically it. Though I had only thought as far as simple > encodings like ASCII, where one byte corresponds to one character. I > wonder if you really need UTF-8 support. Are the encoding values > currently encountered for Windows

Re: [Python-Dev] PEP 467: last round (?)

On Sun, Sep 4, 2016, at 16:42, Koos Zevenhoven wrote: > On Sun, Sep 4, 2016 at 6:38 PM, Nick Coghlan wrote: > > > > There are two self-consistent sets of names: > > > > Let me add a few. I wonder if this is really used so much that > bytes.chr is too long to type (and you can

Re: [Python-Dev] PEP 467: last round (?)

On Sat, Sep 3, 2016, at 18:06, Koos Zevenhoven wrote: > I guess one reason I don't like bchr (nor chrb, really) is that they > look just like a random sequence of letters in builtins, but not > recognizable the way asdf would be. > > I guess I have one last pair of suggestions for the name of

Re: [Python-Dev] PEP 467: last round (?)

On Sat, Sep 3, 2016, at 08:08, Martin Panter wrote: > On 1 September 2016 at 19:36, Ethan Furman wrote: > > Deprecation of current "zero-initialised sequence" behaviour without removal > > > > > >

Re: [Python-Dev] PEP 467: last round (?)

On Fri, Sep 2, 2016, at 19:44, Ethan Furman wrote: > The problem with only having `bchr` is that it doesn't help with > `bytearray`; What is the use case for bytearray.fromord? Even in the rare case someone needs it, why not bytearray(bchr(...))? ___

Re: [Python-Dev] What should a good type checker do? (was: Please reject or postpone PEP 526)

On Fri, Sep 2, 2016, at 18:49, Koos Zevenhoven wrote: > Then again, (b) instead of that being working code, it might be an > error and spam only takes float. No problem, the type checker will > catch that. There are very few functions that should only take float and not int. > On Fri, Sep 2,

Re: [Python-Dev] PEP 528: Change Windows console encoding to UTF-8

On Thu, Sep 1, 2016, at 18:28, Steve Dower wrote: > This is a raw (bytes) IO class that requires text to be passed encoded > with utf-8, which will be decoded to utf-16-le and passed to the Windows APIs. > Similarly, bytes read from the class will be provided by the operating > system as

Re: [Python-Dev] Supported versions of OpenSSL

On Mon, Aug 29, 2016, at 04:09, M.-A. Lemburg wrote: > Hmm, that last part would mean that Python 3.7 will no longer compile > on e.g. Ubuntu 14.04 LTS which uses OpenSSL 1.0.1 as default version. > Since 14.04 LTS is supported until 2019, I think it would be better > to only start requiring 1.0.2

Re: [Python-Dev] Failures in test_site.py - how to debug?

On Fri, Aug 19, 2016, at 18:10, Chris Angelico wrote: > On Sat, Aug 20, 2016 at 8:07 AM, Sjoerd Job Postmus > wrote: > > I'd like to re-iterate my suggestion in case it was missed: split the > > current test in 2 tests: > > > > * Running with `-S` which is for checking that by

Re: [Python-Dev] Failures in test_site.py - how to debug?

On Fri, Aug 19, 2016, at 10:13, Chris Angelico wrote: > On my main dev system (Debian Stretch), I've had a single > long-standing test failure - test_site.py, > StartupImportTests.test_startup_imports. It's annoying (partly because > it's such a noisy failure), and doesn't appear to be happening

Re: [Python-Dev] stuck issue 26826

On Wed, Aug 3, 2016, at 16:32, Marcos Dione wrote: > (it needs to check the availability of the function and the suitability > for the parameters given; copy_file_range() only works on files on the > same filesystem[1]). Hmm... What is the benefit to using copy_file_range over sendfile in this

Re: [Python-Dev] Convert from unsigned long long to PyLong

On Fri, Jul 22, 2016, at 11:50, Eric Snow wrote: > On Fri, Jul 22, 2016 at 3:02 AM, Stefan Ring wrote: > > So to sum this up, you claim that PyLong_FromUnsignedLongLong can > > somehow produce a number larger than the value range of a 64 bit > > number (0x10180).

Re: [Python-Dev] Should we fix these errors?

On Fri, Jul 22, 2016, at 11:35, Victor Stinner wrote: > Oh, the first one is a regression that I introduced in the > implementation of the PEP 475 (retry syscall on EINTR). I don't think > that it can be triggered in practice, because socket handles on > Windows are small numbers, so unlikely to

Re: [Python-Dev] PEP 467: next round

On Mon, Jul 18, 2016, at 17:34, Alexander Belopolsky wrote: > On Mon, Jul 18, 2016 at 5:01 PM, Jonathan Goble > wrote: > > > full(), despite its use in numpy, is also unintuitive to me (my first > > thought is that it would indicate whether an object has room for more > >

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

On Mon, Jun 27, 2016, at 12:40, Ethan Furman wrote: > On 06/21/2016 01:48 PM, 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

Re: [Python-Dev] PEP 520: Preserving Class Attribute Definition Order (round 5)

On Fri, Jun 24, 2016, at 17:52, Eric Snow wrote: > - 2 open questions (__slots__? drop read-only requirement?) It's worth noting that __slots__ itself doesn't have a read-only requirement. It can be a tuple, any iterable of strings, or a single string (which means the object has a single slot).

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

On Wed, Jun 22, 2016, at 11:11, Guido van Rossum wrote: > This is done in order to force all mutations of the class dict to go > through attribute assignments on the class. The latter takes care of > updating the class struct, e.g. if you were to add an `__add__` method > dynamically it would

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

[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

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

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] 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] 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

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

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 >

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] 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

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

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

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

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

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.

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,

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] 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

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] 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. ;) > >

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] 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

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

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/fsdec

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   2   >