Re: [Python-ideas] Allow manual creation of DirEntry objects

On 16.08.16 22:35, Brendan Moloney wrote: I have a bunch of functions that operate on DirEntry objects, typically doing some sort of filtering to select the paths I actually want to process. The overwhelming majority of the time these functions are going to be operating on DirEntry objects

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_name.seta

[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

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

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]

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;

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

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

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? If n

[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

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

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

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

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

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

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

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 >wrote:

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

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

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

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

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

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

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

[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

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

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

01.06.17 12:49, Victor Stinner пише: 2017-06-01 8:47 GMT+02:00 Serhiy Storchaka <storch...@gmail.com>: 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

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

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

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

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

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

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] 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 <storch...@gmail.com <mailto:storch...@gmail.com>> wrote: [...] Calling __getattr__() will slow down the access to builtins. And there is a recursion problem if module's __geta

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

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

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

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

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

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

[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

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

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

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

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

Re: [Python-ideas] Repurpose `assert' into a general-purpose check

28.11.17 15:36, Nick Coghlan пише: * I'm opposed to making assert substantially different from the way it works now If sometimes we will change assert I would prefer to make it more similar to assert in pytest. Output values of the final and intermediate expressions. The hardest problem --

Re: [Python-ideas] Logging Levels

28.11.17 21:45, Guido van Rossum пише: These look like good improvements. I think you should make an issue on bugs.python.org describing your proposal and if you can submit a PR that implements it. See https://bugs.python.org/issue31732 It was discussed and rejected.

Re: [Python-ideas] Proposal: allow length_hint to specify infinite iterators

29.11.17 03:34, Steven D'Aprano пише: This wastes the opportunity to fail fast on operations which cannot possibly succeed, e.g. list(count()) must eventually fail with MemoryError. Or worse: if the OS starts thrashing trying to meet the memory requests, you can lock up the computer. I propose

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

29.11.17 08:08, Steven D'Aprano пише: Perl is hardly the only language with null-coalescing operators -- we might better describe ?? as being familiar to C#, PHP, Swift and Dart. That's two mature, well-known languages and two up-and-coming languages. What is the syntax of the ternary operator

[Python-ideas] Add a dict with the attribute access capability

In 3.7 I have removed an old-deprecated plistlib.Dict. [1] Actually it already was deprecated when the plistlib module was added to the regular stdlib in Python 2.6. This is a dict subclass which allows to access items as attributes. d = plistlib.Dict() d['a'] = 1 assert d.a == 1 d.b = 2

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

29.11.17 15:01, Stephan Houben пише: What about a more general: A if B else C which would allow A if is not None else C but also e.g. A if >= 1 else 0 This look the most "natural" to me. I.e. the least "unnatural". If we even will introduce a new special syntax I will prefer this

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

29.11.17 14:39, Nick Coghlan пише: "a if def else b" -> pronounced "a if defined, else b" I understand "a if defined, else b" as try: result = a except (NameError, AttributeError, LookupError): result = b The problem is that None is not undefined. This is a

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

29.11.17 11:45, Steven D'Aprano пише: On Wed, Nov 29, 2017 at 09:14:12AM +0200, Serhiy Storchaka wrote: 29.11.17 08:08, Steven D'Aprano пише: Perl is hardly the only language with null-coalescing operators -- we might better describe ?? as being familiar to C#, PHP, Swift and Dart. That's two

Re: [Python-ideas] How assignment should work with generators?

27.11.17 23:24, Guido van Rossum пише: Is this problem really important enough that it requires dedicated syntax? Isn't the itertools-based solution good enough? (Or failing that, couldn't we add something to itertools to make it more readable rather than going straight to new syntax?) I

Re: [Python-ideas] Repr of lambda

17.12.17 22:55, Terry Reedy пише: What if include the signature and the expression of the lambda in its repr?  >>> lambda x: x**2 Printing the return value requires adding a code or function attribute. Yes, this requires adding an optional constant code attribute. The return

[Python-ideas] Repr of lambda

Currently repr of doesn't contain much of information besides that it is a lambda. >>> lambda x: x**2 at 0x7f3479b74488> All lambdas have the same repr, different only by unreadable hexadecimal address. What if include the signature and the expression of the lambda in its repr? >>> lambda

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

17.11.17 00:09, MRAB пише: On 2017-11-16 21:44, Serhiy Storchaka wrote: 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

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",

Re: [Python-ideas] Allow additional separator character in variables

21.11.17 05:16, Mikhail V пише: my·variable myᝍvariable myㅡvariable myⵧvariable myㄧvariable myㆍvariable ^ Is this good idea *for Python*? I mean this is not Python that I knew. I don't know how it is possible. Looks like a result of some unlucky nuclear experment. Might be it will not cause any

Re: [Python-ideas] Adding a new function "zip_flat" to itertools (Re: Rewriting the "roundrobin" recipe in the itertools documentation)

21.11.17 01:00, Terry Reedy пише: On 11/20/2017 4:57 PM, Steven D'Aprano wrote: Is there a reason for calling reversed() instead of reversing the order of range in the first place? range(len(iterables)-1, -1, -1) Readability.  Accurately and automatically reversing ranges was one of the use

Re: [Python-ideas] Should Python have user-defined constants?

21.11.17 08:33, Saeed Baig пише: Hey guys I am thinking of perhaps writing a PEP to introduce user-defined constants to Python. Something along the lines of Swift’s “let” syntax (e.g. “let pi = 3.14”). Do you guys think it would be a good idea? Why or why not? Do you think there’s a better

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

21.11.17 04:20, Stephen J. Turnbull пише: Serhiy Storchaka writes: > I agree. But if there is a special part of the Unicode standard for > Pattern White Spaces which includes non-ASCII characters, perhaps there > is a need in them. I asked for the case if Python developers

Re: [Python-ideas] Star assignment in iterator way?

21.11.17 10:54, Kirill Balunov пише: Of course this version has drawbacks (the first that come to mind): 1. Will *b see change if rhs is some muttable sequence? 2. Will *b one way iterator or somethong like range? But still it seems to me that the "iterator way" has more useful applications.

Re: [Python-ideas] Rewriting the "roundrobin" recipe in the itertools documentation

The roundrobin() implementation in recipes has quadratic time for large number of iterables. As well as all other proposed implementations. This is a problem if you use it with hundreds or thousands of iterables. For example: list(roundrobin(*([[1]]*1000))) next(roundrobin(*([[]]*1000

Re: [Python-ideas] Star assignment in iterator way?

21.11.17 11:27, Kirill Balunov пише: Your implementation iterates seq multiple times. But iterable unpacking syntax works with an arbitrary iterable, and iterates it only once. Oh sorry, I know that my implementation iterates seq multiple times, I only provide this to show the

Re: [Python-ideas] Should Python have user-defined constants?

21.11.17 11:34, Saeed Baig пише: Serhiy asked, in relation to constants, “To do what? What problem do you need to solve?”. No problem in particular, to be honest. I just thought they’d be nice since they’d increase confidence that my variables-intended-to-be-constants wouldn’t get reassigned,

Re: [Python-ideas] Should Python have user-defined constants?

21.11.17 11:47, Paul Moore пише: -1. I don't see how this would improve any programs I've written or seen. Tools like mypy or linters might benefit from a feature to track constants and ensure they don't get changed, but I don't think it's needed as a language feature. Seriously, has anyone ever

Re: [Python-ideas] Rewriting the "roundrobin" recipe in the itertools documentation

21.11.17 11:44, Serhiy Storchaka пише: The roundrobin() implementation in recipes has quadratic time for large number of iterables. As well as all other proposed implementations. This is a problem if you use it with hundreds or thousands of iterables. For example:     list(roundrobin(*([[1

Re: [Python-ideas] Allow additional separator character in variables

19.11.17 04:01, Mikhail V пише: Python allows underscore character as a separator in variables. This is better than nothing, still it does not make the look much better. **Proposal**: allow additional separator, namely hyphen character. You already can use "separators" different from the

Re: [Python-ideas] Star assignment in iterator way?

21.11.17 13:53, Kirill Balunov пише: If I can not copy at Python level, I can 'tee' when 'star_pos' is reached. And tee() uses a real RAM for saving items. ___ Python-ideas mailing list Python-ideas@python.org

Re: [Python-ideas] Allow additional separator character in variables

21.11.17 22:03, Stephan Houben пише: If anybody is still worried about this, here is a 29-line proof-of-concept code checker which warns if your source file contains identifiers which are different but look the same. https://gist.github.com/stephanh42/61eceadc2890cf1b53ada5e48ef98ad1 Ha! I

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

[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

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%

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

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

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

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

Re: [Python-ideas] Is there a reason some of the PyLong_As* functions don't call an object's __int__?

08.12.17 13:36, Antoine Pitrou пише: On Fri, 8 Dec 2017 13:26:48 +0200 Serhiy Storchaka <storch...@gmail.com> wrote: Currently the following functions fall back on __int__ where available: PyLong_AsLong PyLong_AsLongAndOverflow PyLong_AsLongLong PyLong_AsLongLongAndOv

Re: [Python-ideas] Is there a reason some of the PyLong_As* functions don't call an object's __int__?

08.12.17 12:41, Erik Bray пише: IIUC, it seems to be carry-over from Python 2's PyLong API, but I don't see an obvious reason for it. In every case there's an explicit PyLong_Check first anyways, so not calling __int__ doesn't help for the common case of exact int objects; adding the fallback

Re: [Python-ideas] a sorting protocol dunder method?

04.12.17 01:06, Chris Barker пише: So: has this already been brought up and rejected? https://bugs.python.org/issue20632 Am I imagining the performance benefits? This will add an additional overhead. This will be even slower than passing the key function, since you will need to look up

Re: [Python-ideas] a sorting protocol dunder method?

04.12.17 13:06, Antoine Pitrou пише: On Mon, 4 Dec 2017 08:45:55 +0200 Serhiy Storchaka <storch...@gmail.com> wrote: 04.12.17 01:06, Chris Barker пише: So: has this already been brought up and rejected? https://bugs.python.org/issue20632 Am I imagining the performance be

Re: [Python-ideas] a sorting protocol dunder method?

04.12.17 14:25, Steven D'Aprano пише: On Mon, Dec 04, 2017 at 08:45:55AM +0200, Serhiy Storchaka wrote: But the idea of the class decorator looks more sane to me. The purpose of __key__ is to define a key function (not a comparison operator) for classes that aren't orderable and don't have

Re: [Python-ideas] Provide a way to import module without exec body

01.12.17 20:12, Neil Schemenauer пише: On 2017-12-01, Chris Angelico wrote: Can you elaborate on where this is useful, please? Introspection tools, for example, might want to look at the module without executing it. Also, it is a building block to make lazy loading of modules work. As Nick

Re: [Python-ideas] f-string literals by default?

05.12.17 23:22, Joseph Jevnik пише: This would break code that uses str.format everywhere for very little benefit. And many regular expressions. And string.Template patterns. And docstrings (silently). And ast.literal_eval, shelve, doctest. ___

Re: [Python-ideas] Inline assignments using "given" clauses

04.05.18 15:06, Nick Coghlan пише: Recapping the use cases where the inline assignment capability received the most agreement regarding being potentially more readable than the status quo: Sorry, but these examples don't look as good examples for inline assignments to me. I think that all

Re: [Python-ideas] Pattern Matching Syntax

05.05.18 09:23, Tim Peters пише: [Tim] ... I liked the way he _reached_ that conclusion: by looking at real- life Python code that may have been written instead to use constructs "like this". I find such examination far more persuasive than abstract arguments or made-up examples.

Re: [Python-ideas] Runtime assertion with no overhead when not active

05.05.18 15:54, Eloi Gaudry пише: I meant avoiding the overhead of the expression evaluation enclosed in the assert itself, not the active/disabled state (that comes at virtually no cost). ex: runtime_assert( { i:None for i in range( 1000 ) } ) By using the syntax you describe ('boolean

Re: [Python-ideas] Runtime assertion with no overhead when not active

07.05.18 12:58, Eloi Gaudry пише: I didn't mean to replace the current (debug) assert but I wanted to add another one that would allow to be switch on or off on production builds. The need for a new keyword (not syntax) comes from this difference.  I cannot think of another example that

Re: [Python-ideas] __dir__ in which folder is this py file

06.05.18 09:53, Yuval Greenfield пише: I often need to reference a script's current directory. I end up writing: import os SRC_DIR = os.path.dirname(__file__) But I would prefer to have a new dunder for that. I propose: "__dir__". I was wondering if others would find it convenient to

Re: [Python-ideas] __dir__ in which folder is this py file

07.05.18 17:42, Eric Snow пише: I'm not necessarily saying we should add ModuleSpec.dirname(), but it (or something like it) is what I'd advocate for *if* we were to add a convenient shortcut to the directory a module is in. FWIW, I'd probably use it. The question is *why* you need the

Re: [Python-ideas] Have a "j" format option for lists

09.05.18 15:39, Facundo Batista пише: authors = ["John", "Mary", "Estela"] "Authors: {:, j}".format(authors) 'Authors: John, Mary, Estela' In the case of the list of book or article authors it would be better to get "John, Mary and Estela" or "John, Mary, and Estela". In other cases "John,

Re: [Python-ideas] Runtime assertion with no overhead when not active

07.05.18 20:52, Guido van Rossum пише: He basically wants a macro so that   runtime_assert() expands to   if and ():   raise AssertionError In Lisp this would be easy. :-) Python is not Lisp (still). But there is the MacroPy project. And at end you always can use an external tool

  1   2   3   4   5   6   >