[Python-ideas] Re: A shortcut to load a JSON file into a dict : json.loadf

14.09.20 19:55, Chris Angelico пише: > I think not; unless there are API details to be hashed out or > counterarguments to be rebuffed, I think this is fairly simple and > non-controversial. I also considered this issue simple and non-controversial. But the discussion turned in an unexpected direc

[Python-ideas] Re: Suggestion: annotated exceptions

24.09.20 11:47, Sergio Fenoll пише: > In the same vein as adding type annotations to code, I think it'd be > very useful to have exception "raises" annotations, i.e. a way to > annotate what exceptions a function raises. Again, like type > annotations, it shouldn't be mandatory nor actually be enfo

[Python-ideas] Re: Improved Error Message for "Unhashable Type"

28.09.20 16:31, Samuel Freilich via Python-ideas пише: > The error message for using a mutable sequence as a set item or map key > seems to frequently confuse Python beginners. The current wording is: > {[1, 2, 3]: [4, 5, 6]} > TypeError: unhashable type: 'list' > > The first thing a Google

[Python-ideas] Re: Add the brotli & zstandard compression algorithms as modules

29.09.20 16:26, Omer Katz пише: > What are the use-cases for LZMA that make it qualify to be part of the > stdlib? Why was that library included? > I think we shouldn't discriminate. If there are a couple of use-cases users > need and the implementation is sufficiently stable, I see no reason not

[Python-ideas] Re: SupportsString Protocol Type Annotation

07.10.20 06:04, Guido van Rossum пише: > Ironically, complex numbers have a `__float__` > method that always fails, and floats don't have a `__complex__` method > but complex(x) succeeds if x is a float... I wonder why not remove complex.__float__ (and complex.__int__, complex.__floordiv__, etc)?

[Python-ideas] Re: SupportsString Protocol Type Annotation

07.10.20 18:43, Guido van Rossum пише: > Usability in a different context. > ``` z = 1j float(z) > Traceback (most recent call last): >   File "", line 1, in > TypeError: can't convert complex to float float(object()) > Traceback (most recent call last): >   File "", line 1, in > T

[Python-ideas] Re: New feature

13.10.20 09:07, ankith abhayan пише: > I would like to request a new feature that allows you to clear the > console screen. > Like in c++, the CLS function There is no the CLS function in C++. ___ Python-ideas mailing list -- python-ideas@python.org To u

[Python-ideas] Re: Add _KB, _MB, _GB to numeric literals

13.10.20 08:06, malin...@163.com пише: > PEP 515 added underscore to numeric literals, it brings better readability. > > PEP 515 -- Underscores in Numeric Literals > https://www.python.org/dev/peps/pep-0515/ > > Is it possible to add _KB, _MB, _GB to numeric literals, for example: > >

[Python-ideas] Re: Weakrefs for lru_cache?

15.10.20 20:49, Ram Rachum пише: > Hi everyone, > > For many years, I've used a `cache` decorator that I built > > for caching Python functions. Then `functools.lru_cache` was > implemented, which is m

[Python-ideas] Optimize out setting unused underscored local variables

It is common to use _ as a placeholder for variable whose value is not used. For example: for _ in range(n) head, _, tail = name.partition(':') first, *_, last = items I though about optimizing out unnecessary assignments. Actually I wrote a patch half year ago and tested it. It did n

[Python-ideas] Re: Bringing the print statement back

20.10.20 12:54, J. Pic пише: > At the same time, Guido says he can remove that cost for no extra > cost, so there's that: how do we find a good reason to not remove a > cost for free ? Sounds like a win/win situation, both for most users > and for the new pegparser. It may have closer to zero cost

[Python-ideas] Re: Call a function at invocation

21.10.20 05:05, Michael Smith пише: > There are many ways to invoke a function from the commandline. You can > use setuptools' console_scripts entrypoint. You can use a decorator > from click. And of course you can always do the classic > > if __name__ == "__main__": > main() > > to call whatev

[Python-ideas] Re: Optimize out setting unused underscored local variables

20.10.20 19:35, Guido van Rossum пише: > I think it's a micro-optimization that's probably not worth it for most > code and more likely to occasionally disappoint people who are using the > debugger. I thought so too. But these reasons make PEP 640 even more useless. __

[Python-ideas] Re: Optimize out setting unused underscored local variables

20.10.20 20:13, Steven D'Aprano пише: > On Tue, Oct 20, 2020 at 05:30:54PM +0300, Serhiy Storchaka wrote: > >> I do not want to create tens of alternate PEPs with minor variations, >> and this issue is not worth a PEP. What is your opinion about this? Is >> it worth

[Python-ideas] Re: Optimize out setting unused underscored local variables

21.10.20 05:23, Steve Barnes пише: > Of course there is also the problem of detecting any functions assigned > to _ or _T that may be called - otherwise there is a risk of breaking > the typical gettext usage in I18n! gettext is usually mapped to global _, so it is not affected. Also, even if eli

[Python-ideas] Re: Use __bytes__ to access buffer-protocol from "user-land"

15.11.20 21:19, Ben Rudiak-Gould пише: > I don't think __bytes__ is necessarily a bad idea, but I want to point > out a couple of things you may be unaware of. First, slicing a > memoryview object creates a subview, so you can wrap your mmap object in > a memoryview and then create slices for each

[Python-ideas] Re: Circular Indexing and FOR loop minimization

25.11.20 06:29, Mathew M. Noel via Python-ideas пише: > 2.) If circular indexing is used then instead of using a double FOR loop > to go through a loop twice we can iterate from 0 to 2n ! If you just need to iterate list indices twice, iterate range(-n, n) instead of range(n).

[Python-ideas] Re: Move semantics

26.11.20 19:07, Guido van Rossum пише: > This reminds me of something in C++. Does it exist in other languages? Indeed, this is a term from C++. In older C++ you could pass argument by value, which makes a copy, and by reference, which is equivalent to passing a pointer by value plus syntax sugar.

[Python-ideas] Re: Move semantics

27.11.20 13:25, Ned Batchelder пише: > On 11/26/20 11:45 PM, Guido van Rossum wrote: > Yes, I see that now.  As Chris points out elsewhere in the thread, this > proposal would have the type annotations change the actual behavior of > the code. No, it will not change the runtime behavior. But it can

[Python-ideas] Re: Move semantics

26.11.20 13:44, 3mi...@gmail.com пише: > Add something like Move type hint to typing module. It will tell the analyzer > that the input parameter of the function is moved and can not be used after. > For example: > ``` > def f(d: Move[dict]) -> dict: > d['a'] = 2 > return d > > d = {1: 2

[Python-ideas] Re: [PoC] Implementing block-scope for the "for" statement variables

29.11.20 18:27, Paul Sokolovsky пише: > Here's example of it in action: > > $ cat example_for1.py > def fun(): > x = 123 > for x in range(5): > print(x) > print("old x:", x) > > fun() I am strong -1. 1. It will break existing code. Including a lot of code written by me. 2

[Python-ideas] Re: adding a timeit.Timer context manager and decorator to time code/functions

29.11.20 22:44, sdemen...@gmail.com пише: > The feature I am looking for is more about timing a code block or a function > while running the code in dev/production. Not about timing it for > benchmarking purposes. > To use timeit (or the current Timer class), one has to write the stmt as a > str

[Python-ideas] Re: Make for/while loops nameable.

03.12.20 15:59, Chris Angelico пише: > well... uhhh Technically you can do that already > > for a in aaa: > for b in bbb: > if condition(a, b): > break > else: > continue # We didn't break from b, so continue a > break # We did break b, so break a >

[Python-ideas] Re: __init__ in module names

08.12.20 21:47, Gregory Szorc пише: > PyOxidizer's pure Rust implementation of a meta path importer > (https://pyoxidizer.readthedocs.io/en/stable/oxidized_importer_oxidized_finder.html) > has been surprisingly effective at finding corner cases and behavior > quirks in Python's importing mechanisms

[Python-ideas] Re: __init__ in module names

08.12.20 22:14, M.-A. Lemburg пише: > On 08.12.2020 20:47, Gregory Szorc wrote: >> Anyway, I was encouraged by Brett Cannon to email this list to assess the >> appetite for introducing a backwards incompatible change to this behavior. So >> here's my strawman/hardline proposal: >> >> 1. 3.10 introd

[Python-ideas] Re: __init__ in module names

09.12.20 22:39, Steven D'Aprano пише: > On Wed, Dec 09, 2020 at 01:56:01PM +0200, Serhiy Storchaka wrote: > >> Thank you for good explanation of the problem. > > I'm sorry Serhiy, I disagree that this has been a "good explanation of > the problem". &

[Python-ideas] Re: __init__ in module names

10.12.20 16:40, Steven D'Aprano пише: > On Thu, Dec 10, 2020 at 03:46:37PM +0200, Serhiy Storchaka wrote: > >> Maybe it is just me, because I read the original issue. But Gregory's >> message looks to me well organized and answering questions that were >> asked

[Python-ideas] Re: @classproperty, @abc.abstractclasspropery, etc.

04.01.11 02:56, Guido van Rossum пише: > That said, I am sure there are use cases for static property and class > property -- I've run into them myself. > > An example use case for class property: in App Engine, we have a Model > class (it's similar to Django's Model class). A model has a "kind" >

[Python-ideas] Re: @classproperty, @abc.abstractclasspropery, etc.

03.01.11 23:09, K. Richard Pixley пише: > There's a whole matrix of these and I'm wondering why the matrix is > currently sparse rather than implementing them all.  Or rather, why we > can't stack them as: > > class foo(object): >     @classmethod >     @property >     def bar(cls, ...): >    

[Python-ideas] Three ways of paths canonization

Before removing provisional state from the pathlib module, we should resolve the issue with Path.resolve(). It corresponds to os.path.realpath(), but behaves differently in case of non-existent path. Actually we can't say that any of these functions is wrong. Both behaviors make sense in differ

Re: [Python-ideas] Add sorted (ordered) containers

On 13.10.16 23:36, Марк Коренберг wrote: I think it should be one standardized implementation of such containers in CPython. For example, C++ has both ordered_map and unorderd_map. Instead of trees, implementation may use SkipList structure, but this is just implementation details. Such struct

Re: [Python-ideas] Proposal for default character representation

On 13.10.16 17:50, Chris Angelico wrote: Solution: Abolish most of the control characters. Let's define a brand new character encoding with no "alphabetical garbage". These characters will be sufficient for everyone: * [2] Formatting characters: space, newline. Everything else can go. * [8] Digi

Re: [Python-ideas] Show more info when `python -vV`

On 14.10.16 10:40, INADA Naoki wrote: When reporting issue to some project and want to include python version in the report, python -V shows very limited information. $ ./python.exe -V Python 3.6.0b2+ sys.version is more usable, but it requires one liner. $ ./python.exe -c 'import sys; print(s

Re: [Python-ideas] Enhancing vars()

On 13.12.16 01:45, Steven D'Aprano wrote: One of the lesser-known ones is vars(obj), which should be used in place of obj.__dict__. Unfortunately, vars() is less useful than it might be, since not all objects have a __dict__. Some objects have __slots__ instead, or even both. That is considered

Re: [Python-ideas] "Immutable Builder" Pattern and Operator

On 23.01.17 00:45, Soni L. wrote: I've been thinking of an Immutable Builder pattern and an operator to go with it. Since the builder would be immutable, this wouldn't work: long_name = mkbuilder() long_name.seta(a) long_name.setb(b) y = long_name.build() I think the more pythonic way is: y =

Re: [Python-ideas] "Immutable Builder" Pattern and Operator

On 23.01.17 01:30, Soni L. wrote: On 22/01/17 08:54 PM, Serhiy Storchaka wrote: On 23.01.17 00:45, Soni L. wrote: I've been thinking of an Immutable Builder pattern and an operator to go with it. Since the builder would be immutable, this wouldn't work: long_name = mkbuilder() long

Re: [Python-ideas] Make Path objects iterable

On 26.02.17 15:39, Vamsi Krishna Avula wrote: This is somewhere between a question and a proposal. I'm just trying to understand why Path objects use an explicit iterdir method. Why not make them iterable? Because this is ambiguous. Iterating can mean many different things: 1. Iterate charact

Re: [Python-ideas] Positional-only parameters

On 28.02.17 23:17, Victor Stinner wrote: My question is: would it make sense to implement this feature in Python directly? If yes, what should be the syntax? Use "/" marker? Use the @positional() decorator? I'm strongly +1 for supporting positional-only parameters. The main benefit to me is th

Re: [Python-ideas] suggestion about the sort() function of the list instance

On 01.03.17 11:31, Paul Moore wrote: On 1 March 2017 at 01:31, qhlonline wrote: My code example is not proper, Yes, may be this is better: list.sort().revers( We can already do this - reversed(sorted(lst)) Or just sorted(lst, reverse=True). __

Re: [Python-ideas] __repr__: to support pprint

On 01.03.17 16:35, Paul Moore wrote: On 1 March 2017 at 13:50, Steven D'Aprano wrote: It is possible that we could come up with a pretty-printing protocol, but that wouldn't be a trivial job. I'd be inclined to do this via simplegeneric. Let pprint do what it currently does, but allow users t

[Python-ideas] Optional parameters without default value

Function implemented in Python can have optional parameters with default value. It also can accept arbitrary number of positional and keyword arguments if use var-positional or var-keyword parameters (*args and **kwargs). But there is no way to declare an optional parameter that don't have defa

Re: [Python-ideas] Optional parameters without default value

On 02.03.17 10:36, M.-A. Lemburg wrote: Why a new syntax ? Can't we just have a pre-defined sentinel singleton NoDefault and use that throughout the code (and also special case it in argument parsing/handling)? def get(store, key, default=NoDefault): if store.exists(key): return stor

Re: [Python-ideas] Optional parameters without default value

On 02.03.17 12:04, M.-A. Lemburg wrote: This is not new syntax, nor is it a keyword. It's only a new singleton and it is well usable outside of function declarations as well, e.g. for class attributes which are not yet initialized (and which can accept None as value). If it is not a keyword, it

Re: [Python-ideas] Optional parameters without default value

On 02.03.17 14:20, Paul Moore wrote: So I guess I'm +0.5 on the proposed "positional only parameters" syntax, and -1 on any form of new language-defined sentinel value. My proposition is not about "positional-only parameters". ___ Python-ideas maili

Re: [Python-ideas] Add pathlib.Path.write_json and pathlib.Path.read_json

On 27.03.17 15:50, Ram Rachum wrote: Hi guys, What do you think about adding methods pathlib.Path.write_json and pathlib.Path.read_json , similar to write_text, write_bytes, read_text, read_bytes? This would make writing / reading JSON to a file a one liner instead of a two-line with clause.

Re: [Python-ideas] What about regexp string litterals : re".*" ?

On 27.03.17 18:17, Simon D. wrote: After some french discussions about this idea, I subscribed here to suggest adding a new string litteral, for regexp, inspired by other types like : u"", r"", b"", br"", f""… The regexp string litteral could be represented by : re"" It would ease the use of re

Re: [Python-ideas] Add pathlib.Path.write_json and pathlib.Path.read_json

On 28.03.17 02:35, Greg Ewing wrote: Paul Moore wrote: Is this a well-defined idea? ... There's nothing describing how multiple values would be stored in the same file/transmitted in the same stream. I think this is something that's outside the scope of the spec. But since the grammar makes i

[Python-ideas] Thread-safe generators

When use a generator from different threads you can get a ValueError "generator already executing". Getting this exception with the single thread is a programming error, it in case of different threads it could be possible to wait until other thread finish executing the generator. The generator

Re: [Python-ideas] Thread-safe generators

On 15.04.17 01:42, Greg Ewing wrote: Serhiy Storchaka wrote: but should not affect performance since locking is used only when you faced with a generator running in other thread. I don't think that's true, because the first thread to use a generator has to lock it as well. And eve

Re: [Python-ideas] Thread-safe generators

On 15.04.17 11:55, Stephen J. Turnbull wrote: Serhiy Storchaka writes: > The first thread just sets the running flag (as in current code). Due to > GIL this doesn't need additional synchronization. Can we assume this lack of additional synchronization for other implementations?

Re: [Python-ideas] Suggestion: Add shutil.get_dir_size

On 02.05.17 22:07, Ram Rachum wrote: I have a suggestion: Add a function shutil.get_dir_size that gets the size of a directory, including all the items inside it recursively. I currently need this functionality and it looks like I'll have to write my own function for it. The comprehensive imple

Re: [Python-ideas] Add shutil.ignore_patterns() to shutil.rmtree()

On 05.05.17 10:58, George Fischhof wrote: I have a task to synchronize folders but some files should be remained untouched. I think this is a very common task. I found that shutil.copytree() has ignore_patterns() but rmtree() has not. So here comes my idea: add ignore_patterns() to rmtree() it

Re: [Python-ideas] Tighten up the formal grammar and parsing a bit?

On 15.05.17 16:00, Steven D'Aprano wrote: There's also cases where if x > y: pass else: code is *not necessarily* the same as if not (x > y): code This is not true. if not cond: stmt1 else: stmt2 always is equivalent to if co

Re: [Python-ideas] Tighten up the formal grammar and parsing a bit?

On 15.05.17 18:46, Ryan Gonzalez wrote: I guess maybe if you overload the operators to return broken objects, maybe then they would be different? No. The compiler generates an equivalent bytecode for both cases. ___ Python-ideas mailing list Python-i

Re: [Python-ideas] tweaking the file system path protocol

23.05.17 20:04, Brett Cannon пише: On Tue, 23 May 2017 at 03:13 Wolfgang Maier > wrote: My proposal is to change this to: 1) check whether the type of the argument is str or bytes *exactly*; if so, return the argument unchanged 2) c

Re: [Python-ideas] tweaking the file system path protocol

29.05.17 00:33, Wolfgang Maier пише: The path protocol does *not* use __fspath__ as an indicator that an object's str-representation is intended to be used as a path. If you had wanted this, the PEP should have defined __fspath__ not as a method, but as a flag and have the protocol check that

[Python-ideas] π = math.pi

What you are think about adding Unicode aliases for some mathematic names in the math module? ;-) math.π = math.pi math.τ = math.tau math.Γ = math.gamma math.ℯ = math.e Unfortunately we can't use ∞, ∑ and √ as identifiers. :-( ___ Python-ideas mailin

Re: [Python-ideas] π = math.pi

01.06.17 10:03, David Mertz пише: It's awfully easy to add in your own code. Since they are simply aliases, I don't see why bother put the duplication in the standard library. You can even monkey patch if you want it in the 'math' namespace. I'd prefer a bare 'π' in my own code though. As wel

Re: [Python-ideas] π = math.pi

01.06.17 10:53, Stephan Houben пише: Tau was kind of a joke. math.π is a kind of joke too. Honest, it is strange, that Python allows Unicode identifiers, but doesn't have the one in its stdlib! ___ Python-ideas mailing list Python-ideas@python.org

Re: [Python-ideas] π = math.pi

01.06.17 12:49, Victor Stinner пише: 2017-06-01 8:47 GMT+02:00 Serhiy Storchaka : What you are think about adding Unicode aliases for some mathematic names in the math module? ;-) math.π = math.pi How do you write π (pi) with a keyboard on Windows, Linux or macOS? This shouldn't

Re: [Python-ideas] π = math.pi

01.06.17 12:32, Stephan Houben пише: math.π is a kind of joke too. The point is that tau, being a joke, should not be considered as setting a precedent. If add one joke feature per release, this one looks enough harmless. ___ Python-ideas mailing l

Re: [Python-ideas] π = math.pi

03.06.17 03:31, Guido van Rossum пише: OK, I think this discussion is pretty much dead then. We definitely shouldn't allow math operators in identifiers, otherwise in Python 4 or 5 we couldn't introduce them as operators. Sorry. I proposed this idea as a joke. math.π is useless, but mostly ha

Re: [Python-ideas] π = math.pi

03.06.17 20:45, Brett Cannon пише: Since this regularly comes up, why don't we add a note to the math module that you can do the above import(s) to bind various mathematical constants to their traditional symbol counterparts? The note can even start off with something like "While Python's stand

Re: [Python-ideas] π = math.pi

07.06.17 08:34, Greg Ewing пише: Mikhail V wrote: I find actually symbols ≤ ≥ (inclusive comparison) nice. Yes, there are a few symbols it would be nice to have. A proper ≠ symbol would have avoided the wars between <> and !=. :-) But this would start the war between ≤ and ⩽ (symbols used by

Re: [Python-ideas] Run length encoding

11.06.17 05:20, Neal Fultz пише: I am very new to this, but on a different forum and after a couple conversations, I really wished Python came with run-length encoding built-in; after all, it ships with zip, which is much more complicated :) The general idea is to be able to go back and forth

Re: [Python-ideas] Run length encoding

11.06.17 09:17, Neal Fultz пише: * other people have been false positive and wanted a SQL-type group by, but got burned * hence the warnings in the docs. This wouldn't help if people don't read the docs. Also, if someone rewrote zip in pure python, would many people actually notic

Re: [Python-ideas] A suggestion for a do...while loop

25.06.17 14:58, Markus Meskanen пише: I'm a huge fan of the do...while loop in other languages, and it would often be useful in Python too, when doing stuff like: while True: password = input() if password == ...: break In this particular case you could write: for pass

Re: [Python-ideas] + operator on generators

25.06.17 15:06, lucas via Python-ideas пише: I often use generators, and itertools.chain on them. What about providing something like the following: a = (n for n in range(2)) b = (n for n in range(2, 4)) tuple(a + b) # -> 0 1 2 3 This, from user point of view, is just as how the

Re: [Python-ideas] + operator on generators

26.06.17 13:47, Joao S. O. Bueno пише: On 25 June 2017 at 20:55, Danilo J. S. Bellini > wrote: On Sun, Jun 25, 2017 at 3:06 PM, lucas via Python-ideas mailto:python-ideas@python.org>>wrote: I often use generators, and itertools.chain on them.

Re: [Python-ideas] tempfile.TemporaryDirectory() should be able to create temporary directory at a given arbitrary place

18.07.17 14:55, George Fischhof пише: I used tempfile.TemporaryDirectory(). On first usage it was good, but on second one there was a need to create tempopray directory and files in it a given place. (It needed for a test). And I found that TemporaryDirectory() is not able to do this. So my id

Re: [Python-ideas] namedtuple with ordereddict

19.07.17 01:33, Greg Ewing пише: Jim J. Jewett wrote: is there any reason not to simply define it as a view on a dict, or at least as a limited proxy to one? Some valuable characteristics of namedtuples as they are now: * Instances are very lightweight * Access by index is fast * Can be used

Re: [Python-ideas] namedtuple from ordereddict

20.07.17 23:17, Jim J. Jewett пише: Several of the replies seemed to suggest that re-using the current dict structure for a tuple wouldn't work. Since I'm not sure whether people are still thinking of the old structure, or I'm missing something obvious, I'll be more explicit. Per https://github

Re: [Python-ideas] namedtuple literals [Was: RE a new namedtuple]

20.07.17 04:35, Alexander Belopolsky пише: On Wed, Jul 19, 2017 at 9:08 PM, Guido van Rossum wrote: The proposal in your email seems incomplete The proposal does not say anything about type((x=1, y=2)). I assume it will be the same as the type currently returned by namedtuple(?, 'x y'), but

Re: [Python-ideas] Mimetypes Include application/json

09.08.17 21:17, Brett Cannon пише: On Wed, 9 Aug 2017 at 10:43 Nate. > wrote: A friend and I have hit a funny situation with the `mimetypes.py` library guessing the type for a '.json' file. Is there a reason why '.json' hasn't been added to the mapp

Re: [Python-ideas] tarfile.extractall progress

01.09.17 14:50, Tarek Ziadé пише: For large archives, I want to display a progress bar while the archive is being extracted with: https://docs.python.org/3/library/tarfile.html#tarfile.TarFile.extractall I could write my own version of extractall() to do this, or maybe we could introduce a call

[Python-ideas] Hexadecimal floating literals

The support of hexadecimal floating literals (like 0xC.68p+2) is included in just released C++17 standard. Seems this becomes a mainstream. In Python float.hex() returns hexadecimal string representation. Is it a time to add more support of hexadecimal floating literals? Accept them in float c

Re: [Python-ideas] LOAD_NAME/LOAD_GLOBAL should be use getattr()

12.09.17 19:17, Neil Schemenauer пише: This is my idea of making module properties work. It is necessary for various lazy-loading module ideas and it cleans up the language IMHO. I think it may be possible to do it with minimal backwards compatibility problems and performance regression. To me

Re: [Python-ideas] LOAD_NAME/LOAD_GLOBAL should be use getattr()

13.09.17 23:07, Lucas Wiman пише: On Wed, Sep 13, 2017 at 11:55 AM, Serhiy Storchaka <mailto:storch...@gmail.com>> wrote: [...] Calling __getattr__() will slow down the access to builtins. And there is a recursion problem if module's __getattr__() uses builtins. T

Re: [Python-ideas] Move some regrtest or test.support features into unittest?

13.09.17 16:42, Victor Stinner пише: * skip a test if it allocates too much memory, command line argument to specify how many memory a test is allowed to allocate (ex: --memlimit=2G for 2 GB of memory) Instead of just making checks before running some tests it would be worth to limit the memor

Re: [Python-ideas] Hexadecimal floating literals

21.09.17 18:23, Victor Stinner пише: My vote is now -1 on extending the Python syntax to add hexadecimal floating literals. While I was first in favor of extending the Python syntax, I changed my mind. Float constants written in hexadecimal is a (very?) rare use case, and there is already float.

Re: [Python-ideas] allow overriding files used for the input builtin

29.09.17 08:53, Wren Turkal пише: This is meant to turn code like the following: orig_stdin = sys.stdin orig_stdout = sys.stdout with open('/dev/tty', 'r+') as f:     sys.stdin = f     sys.stdout = f     name = input('Name? ') sys.stdin = orig_stdin sys.stdout = orig_stdout print(name

Re: [Python-ideas] allow overriding files used for the input builtin

29.09.17 14:40, Steven D'Aprano пише: Because the two-liner doesn't do what input() does. Testing it at the interactive interpreter gives me: py> def myinput(): sys.stdout.write("Name? ") return sys.stdin.readline() py> x = myinput() Steve py> ? py> The output isn't displ

Re: [Python-ideas] Add pop_callback to deque signature

04.10.17 07:58, Nick Coghlan пише: For deque specifically, I like Steven D'Aprano's suggestion of a "__dropped__" or "__discard__" subclassing API that makes it straightforward to change the way that queue overruns are handled (especially if raising an exception from the new subclass method can p

Re: [Python-ideas] Add time.time_ns(): system clock with nanosecond resolution

13.10.17 17:12, Victor Stinner пише: I would like to add new functions to return time as a number of nanosecond (Python int), especially time.time_ns(). It would enhance the time.time() clock resolution. In my experience, it decreases the minimum non-zero delta between two clock by 3 times, new

Re: [Python-ideas] Membership of infinite iterators

17.10.17 09:42, Nick Coghlan пише: On 17 October 2017 at 16:32, Nick Coghlan > wrote: So this sounds like a reasonable API UX improvement to me, but you'd need to ensure that you don't inadvertently change the external behaviour of *successful* containment

Re: [Python-ideas] Membership of infinite iterators

17.10.17 14:10, Nick Coghlan пише: 1. It's pretty easy to write "for x in y in y" when you really meant to write "for x in y", and if "y" is an infinite iterator, the "y in y" part will become an unbreakable infinite loop when executed instead of the breakable one you intended (especially annoy

Re: [Python-ideas] Membership of infinite iterators

17.10.17 17:06, Nick Coghlan пише: Keep in mind we're not talking about a regular loop you can break out of with Ctrl-C here - we're talking about a tight loop inside the interpreter internals that leads to having to kill the whole host process just to get out of it. And this is the root of t

Re: [Python-ideas] Membership of infinite iterators

18.10.17 13:22, Nick Coghlan пише: 2.. These particular cases can be addressed locally using existing protocols, so the chances of negative side effects are low Only the particular case `count() in count()` can be addressed without breaking the following examples: >>> class C: ... def __

Re: [Python-ideas] Membership of infinite iterators

18.10.17 17:48, Nick Coghlan пише: 1. It will make those loops slower, due to the extra overhead of checking for signals (even the opcode eval loop includes all sorts of tricks to avoid actually checking for new signals, since doing so is relatively slow) 2. It will make those loops harder to m

Re: [Python-ideas] Membership of infinite iterators

18.10.17 22:21, Koos Zevenhoven пише: ​Nice! Though I'd really like a general ​solution that other code can easily adopt, even third-party extension libraries. What is the more general solution? For interrupting C code you need to check signals manually, either in every loop, or in every itera

Re: [Python-ideas] About the efficiency of range()

05.11.17 20:49, Juancarlo Añez пише: I found this interesting: https://stackoverflow.com/a/46996392 Please explain your suggestion. ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/

Re: [Python-ideas] Proposal to change Python version release cycle

04.11.17 17:29, Wolfgang пише: A good point but two digits minor version numbers have the possibility to break a lot code. There is a lot of stuff out where a single digit major version is assumed. Even the official Python build for windows with python27.dll, python36.dll can be problematic becau

Re: [Python-ideas] Proposal to change Python version release cycle

05.11.17 21:53, Stephan Houben пише: After python39.dll I'd expect python3A.dll . The problem will return in 3.36. Or possibly python3⑽.dll >>> len("python3⑽.dll") == len("python39.dll") True No worries, then. But len(os.fsencode("python3⑽.dll")) != len(os.fsencode("python39.dll")). ___

Re: [Python-ideas] array.array.index() and Sequence ABC

06.11.17 11:17, Niki Spahiev пише: I noticed that array.index() method takes single argument in python 3.6, while Sequence protocol specifies 2 optional arguments after the first. example from list: L.index(value, [start, [stop]]) -> integer -- return first index of value. I propose adding st

Re: [Python-ideas] Any chance on (slowly) deprecating `eval` and `exec` as builtins?

07.11.17 12:29, אלעזר пише: Also, it is unfortunate that `ast.literal_eval` is less accessible than `builtins.eval`. Giving it an alias in builtins might make it easier for programmers (and less scary - "ast" might sound like I need a PhD to use it). ast.literal_eval is not so safe as you thi

Re: [Python-ideas] Any chance on (slowly) deprecating `eval` and `exec` as builtins?

07.11.17 16:41, Steven D'Aprano пише: On Tue, Nov 07, 2017 at 03:35:58PM +0200, Serhiy Storchaka wrote: 07.11.17 12:29, אלעזר пише: Also, it is unfortunate that `ast.literal_eval` is less accessible than `builtins.eval`. Giving it an alias in builtins might make it easier for programmers

Re: [Python-ideas] PEP 562

10.09.17 21:48, Ivan Levkivskyi пише:   # lib.py   from warnings import warn   deprecated_names = ["old_function", ...]   def _deprecated_old_function(arg, other):       ...   def __getattr__(name):       if name in deprecated_names:           warn(f"{name} is deprecated", Deprecation

Re: [Python-ideas] Modules as global namespaces rather than dicts

14.11.17 22:34, Neil Schemenauer пише: This is an idea I have been playing with and seems to hold some promise. I think we should use a module instance as the standard global namespace rather than directly using its dict. I have a prototype version of CPython that does this, not working 100% ye

[Python-ideas] Ignorable whitespaces in the re.VERBOSE mode

Currently the re module ignores only 6 ASCII whitespaces in the re.VERBOSE mode: U+0009 CHARACTER TABULATION U+000A LINE FEED U+000B LINE TABULATION U+000C FORM FEED U+000D CARRIAGE RETURN U+0020 SPACE Perl ignores characters that Unicode calls "Pattern White Space

Re: [Python-ideas] Ignorable whitespaces in the re.VERBOSE mode

16.11.17 19:38, Guido van Rossum пише: Who would benefit from changing this? Let's not change things just because we can, or because Perl 6 does it. I don't know. I know the disadvantages of making this change, and I ask what is the benefit. If there is a benefit, and it is important for Pyth

<    1   2   3   4   5   6   >