Re: [Python-Dev] Compact GC Header

29.05.18 17:15, Steve Dower пише: Looks like it breaks the 3.7 ABI, which is certainly not allowed at this time. But it’s not a limited API structure, so no problem for 3.8. Looks like it breaks only extensions that use private macros _PyObject_GC_TRACK, _PyObject_GC_UNTRACK and

Re: [Python-Dev] The history of PyXML

28.05.18 23:11, Jeremy Kloth пише: On Thu, May 17, 2018 at 6:18 AM, Serhiy Storchaka wrote: Does anyone has the full copy of the PyXML repository, with the complete history? This library was included in Python 2.1 as the xml package and is not maintained as a separate project since 2004. It's

[Python-Dev] When tp_clear returns non-zero?

The tp_clear field of PyTypeObject has type inquiry. It is a pointer to a function that takes PyObject * and return int. typedef int (*inquiry)(PyObject *); I'm interesting what the result of this function means. In what cases it can return non-zero, and can it set an exception? Currently

Re: [Python-Dev] The history of PyXML

25.05.18 05:09, Jan Claeys пише: On Thu, 2018-05-17 at 15:18 +0300, Serhiy Storchaka wrote: Does anyone has the full copy of the PyXML repository, with the complete history? This library was included in Python 2.1 as the xml package and is not maintained as a separate project since 2004. It's

Re: [Python-Dev] [python-committers] FINAL WEEK FOR 3.7.0 CHANGES!

24.05.18 19:02, Ned Deily пише: On May 24, 2018, at 11:35, Serhiy Storchaka <storch...@gmail.com> wrote: I have doubts about two issues. I feel the responsibility for them because I had the opportunity to solve them before, but I lost it. [...] Serhiy, what are the bugs.python.org

Re: [Python-Dev] [python-committers] FINAL WEEK FOR 3.7.0 CHANGES!

24.05.18 10:23, Ned Deily пише: So this *is* really your last chance: if you know of any true releasing blocking issues for 3.7.0, you have about 12 more hours to log it in the bug tracker as a "release blocker". I'll send out an email once we start the release manufacturing. Any merges to the

Re: [Python-Dev] [python-committers] FINAL WEEK FOR 3.7.0 CHANGES!

15.05.18 14:51, Ned Deily пише: This is it! We are down to THE FINAL WEEK for 3.7.0! Please get your feature fixes, bug fixes, and documentation updates in before 2018-05-21 ~23:59 Anywhere on Earth (UTC-12:00). That's about 7 days from now. We will then tag and produce the 3.7.0 release

Re: [Python-Dev] Procedure for adding new public C API

21.05.18 16:27, Paul Moore пише: On 21 May 2018 at 13:41, Serhiy Storchaka <storch...@gmail.com> wrote: * Add it in PC/python3.def. I thought python3.def should only contain symbols in the limited ABI (it defines the API of python3.dll, doesn't it?) Thank you for correction. Yes, an

[Python-Dev] Procedure for adding new public C API

Please don't forgot to perform the following steps when add a new public C API: * Document it in Doc/c-api/. * Add an entry in the What's New document. * Add it in Doc/data/refcounts.dat. * Add it in PC/python3.def. If you want to include it in the limited API, wrap its declaration with:

Re: [Python-Dev] [python-committers] FINAL WEEK FOR 3.7.0 CHANGES!

17.05.18 21:39, Brett Cannon пише: Maybe we should start thinking about flagging PRs or issues as needing a What's New entry to help track when they need one, or always expect it in a PR and ignore that requirement when a 'skip whats new' label is applied. That would at least make it easier to

Re: [Python-Dev] [python-committers] FINAL WEEK FOR 3.7.0 CHANGES!

17.05.18 21:43, Elvis Pranskevichus пише: I'm working on the What's New document. Will start putting PRs in the next few days. Great! ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev

Re: [Python-Dev] [python-committers] FINAL WEEK FOR 3.7.0 CHANGES!

15.05.18 14:51, Ned Deily пише: This is it! We are down to THE FINAL WEEK for 3.7.0! Please get your feature fixes, bug fixes, and documentation updates in before 2018-05-21 ~23:59 Anywhere on Earth (UTC-12:00). That's about 7 days from now. We will then tag and produce the 3.7.0 release

[Python-Dev] The history of PyXML

Does anyone has the full copy of the PyXML repository, with the complete history? This library was included in Python 2.1 as the xml package and is not maintained as a separate project since 2004. It's home on SourceForge was removed. I have found sources of the last PyXML version (0.8.4),

Re: [Python-Dev] What is the rationale behind source only releases?

16.05.18 07:35, Alex Walters пише: [1]: https://en.wikipedia.org/wiki/Wikipedia:Chesterton%27s_fence And I wish that every author who suggested the idea for Python was familiar with the Chesterton's fence principle. ___ Python-Dev mailing list

Re: [Python-Dev] What is the rationale behind source only releases?

16.05.18 07:35, Alex Walters пише: In the spirit of learning why there is a fence across the road before I tear it down out of ignorance [1], I'd like to know the rationale behind source only releases of cpython. I have an opinion on their utility and perhaps an idea about changing them, but

Re: [Python-Dev] bpo-28055: Fix unaligned accesses in siphash24(). (GH-6123)

13.05.18 20:42, Christian Heimes пише: I was against the approach a good reason. The PR adds additional CPU instructions and changes memory access pattern in a critical path of CPython. There is no reason to add additional overhead for the majority of users or X86 and X86_64 architectures. The

Re: [Python-Dev] PEP 554 - strange random boldface

12.05.18 17:48, Steve Holden пише: It's certainly true that when I split any of those left-hand cells the bizarre emphasis occurs. Still looking for a workaround. Remove an extra indentation of the second line. ___ Python-Dev mailing list

Re: [Python-Dev] Slow down...

09.05.18 14:35, Antoine Pitrou пише: I proposed the idea in another thread that Python had reached "peak syntax" and maybe it was time to consider the core language essentially mature. Of course, we don't know what the future will bring and perhaps some fundamentally new programming idiom will

Re: [Python-Dev] Slow down...

09.05.18 07:25, Steven D'Aprano пише: If we could look forward to 2028, when we're running Python 3.14 or so (4.7 if you prefer), how many fantastic language features that we cannot bear to give up would we be missing out on? Like tab-delimited tables.

Re: [Python-Dev] Process to remove a Python feature

08.05.18 19:10, Ethan Furman пише: X.Y+1: added a deprecation warning. Many users need to support only two recent versions and can move to using the replacement now. I'm curious how you arrived at this conclusion?  I know I've only worked at two different Python-using companies, but neither

Re: [Python-Dev] Process to remove a Python feature

04.05.18 22:08, Matthias Bussonnier пише: Maybe to push people forward, but from experience it is hard to predict future, so saying when it _will_ be remove is hard. Right. But the data of removing is usually specified when the code for removing already is written, or even merged in the next

Re: [Python-Dev] Process to remove a Python feature

08.05.18 18:51, Joni Orponen пише: If one can import from the future can one can also import from the past? One can move removed feature to a third-party module and import them from it. ___ Python-Dev mailing list Python-Dev@python.org

Re: [Python-Dev] Slow down...

07.05.18 16:50, Joao S. O. Bueno пише: May it is important to note that Python 3.7 already has very little syntactic changes. Actually, there are no new syntac changes with PEP 563 - (Postponed Evaluation of Annotations) being maybe the only change to existing behavior, and PEP 562 as new

Re: [Python-Dev] Slow down...

07.05.18 14:19, Nick Coghlan пише: And as the current python-ideas discussion about accessing paths relative to __file__ shows, I can't believe this is discussed seriously. Forgot about the Python 2 legacy, just use importlib. ___ Python-Dev

Re: [Python-Dev] Process to remove a Python feature

04.05.18 20:57, Matthias Bussonnier пише: But when I hit a DeprecationWarning message there is one crucial piece of information missing most of the time: Since which version number it's deprecated (and sometime since when the replacement is available could be good if overlap between

Re: [Python-Dev] Process to remove a Python feature

04.05.18 16:14, Steven D'Aprano пише: Have there been many features removed since 3.1? I know there were some features removed in 3.0, like callable(), which were later put back in, but I can't think of anythin removed since then. If there were, the pace of it is pretty slow. Read "What's New"

Re: [Python-Dev] (Looking for) A Retrospective on the Move to Python 3

27.04.18 13:25, Nick Coghlan пише: and PEP 3099 (explicitly rejected ideas that also didn't get their own PEPs). "There will be no alternative binding operators such as :=." ___ Python-Dev mailing list Python-Dev@python.org

Re: [Python-Dev] Boundaries between numbers and identifiers

26.04.18 22:02, Lukasz Langa пише: On Apr 26, 2018, at 11:37 AM, Serhiy Storchaka <storch...@gmail.com> wrote: I propose to change the Python syntax by adding a requirement that there should be a whitespace or delimiter between a numeric literal and the following keyword. -1 This woul

[Python-Dev] Order of positional and keyword arguments

There is an inconsistence in passing arguments to functions. Explicit positional arguments should precede keyword arguments (both explicit and variable), but variable positional arguments can follow explicit keyword arguments and precede variable keyword arguments. For example, for function

[Python-Dev] Boundaries between numbers and identifiers

In Python 2.5 `0or[]` was accepted by the Python parser. It became an error in 2.6 because "0o" became recognizing as an incomplete octal number. `1or[]` still is accepted. On other hand, `1if 2else 3` is accepted despites the fact that "2e" can be recognized as an incomplete floating point

Re: [Python-Dev] Timing for removing legacy Unicode APIs deprecated by PEP 393

13.04.18 16:27, INADA Naoki пише: Then, I want to reschedule the removal of these APIs. Can we remove them in 3.8? 3.9? or 3.10? I prefer sooner as possible. I suppose that many users will start porting to Python 3 only in 2020, after 2.7 EOL. After that time we shouldn't support

Re: [Python-Dev] PEP 575: Unifying function/method classes

15.04.18 16:09, Nick Coghlan пише: On 15 April 2018 at 22:50, Jeroen Demeyer wrote: I've been told that there might also be a problem with Random._randbelow, even though it doesn't cause test failures. From Raymond's description (and from an initial reading of the code),

Re: [Python-Dev] Trying to build from source, test-poplib fails

08.04.18 19:10, Antoine Pitrou пише: On Sat, 7 Apr 2018 17:31:47 -0500 Skip Montanaro wrote: It's been a long while since I rebuilt Python from the Git source. I tried for the first time the other day. Everything passed except test_poplib and test_asyncio. The former

Re: [Python-Dev] Is it useful to update cgitb module?

07.04.18 23:21, Stéphane Blondon пише: I wonder if it's useful to update the cgitb module, in particular the html output. I see some possible improvements: 1. In both text and html versions: When a module is called, there are no parameters (displayed as '()'). I think they are unnecessary.

Re: [Python-Dev] Timeline for Pull request reviews in 3.8

06.04.18 19:32, Anthony Flury via Python-Dev пише: The three pull requests are : Python 2.7 - doc string fix : https://github.com/python/cpython/pull/6015 There are several open issues for "sequence" vs "iterable" in docstrings and documentation for different functions. It would be worth to

Re: [Python-Dev] Enum, Flag, __contains__, and False vs TypeError

I expect that for IntFlag `x in flags` is equivalent either to bool(x | flags.value) or to (x | flags.value) == x It should return some result only if x is an integer (or compatible with integers) and raise a TypeError otherwise. Don't add any special checks unless there are good

Re: [Python-Dev] Why is pickle.DEFAULT_PROTOCOL still 3?

03.04.18 01:57, Lukasz Langa пише: On Apr 2, 2018, at 2:13 PM, Antoine Pitrou wrote: On Mon, 2 Apr 2018 13:48:46 -0700 Lukasz Langa wrote: Pickle protocol version 4.0 was originally defined back in PEP 3154 and shipped as part of Python 3.4 back in 2011.

Re: [Python-Dev] Nuking wstr [Re: How can we use 48bit pointer safely?]

30.03.18 16:54, Antoine Pitrou пише: We could also simply nuke wstr. I frankly don't think it's very important. It's only used when calling system functions taking a wchar_t argument, as an « optimization ». I'd be willing to guess that modern workloads aren't bottlenecked by the cost

Re: [Python-Dev] Subtle difference between f-strings and str.format()

29.03.18 18:06, Terry Reedy пише: On 3/28/2018 11:27 AM, Serhiy Storchaka wrote: The optimizer already changes semantic. Non-optimized "if a and True:" would call bool(a) twice, but optimized code calls it only once. Perhaps Ref 3.3.1 object.__bool__ entry, after " shou

Re: [Python-Dev] How can we use 48bit pointer safely?

30.03.18 09:28, INADA Naoki пише: As far as I know, most amd64 and arm64 systems use only 48bit address spaces. (except [1]) [1] https://software.intel.com/sites/default/files/managed/2b/80/5-level_paging_white_paper.pdf It means there are some chance to compact some data structures. I point

Re: [Python-Dev] Subtle difference between f-strings and str.format()

30.03.18 02:16, Steven D'Aprano пише: Is there a down-side to 2b? It sounds like something you might end up doing at a later date regardless of what you do now. This complicate the compiler and the eval loop, especially in the case of nested substitutions in formats, like

Re: [Python-Dev] Subtle difference between f-strings and str.format()

29.03.18 13:17, Jeff Allen пише:     '{1} {0}'.format(a(), b()) # E1     f'{b()}{a()}' # E2 I think I would be very surprised to find b called before a in E1 because of the general contract on the meaning of method calls. I'm assuming that's what an AST-based optimisation

Re: [Python-Dev] PEP 574 -- Pickle protocol 5 with out-of-band data

28.03.18 23:19, Antoine Pitrou пише: Agreed. Do you know by which timeframe you'll know which opcodes you want to add? I'm currently in the middle of the first part, trying to implement pickling local classes with static and class methods without creating loops. Other parts exist just like

Re: [Python-Dev] PEP 574 -- Pickle protocol 5 with out-of-band data

28.03.18 21:39, Antoine Pitrou пише: > I'd like to submit this PEP for discussion. It is quite specialized > and the main target audience of the proposed changes is > users and authors of applications/libraries transferring large amounts > of data (read: the scientific computing & data science

Re: [Python-Dev] Subtle difference between f-strings and str.format()

28.03.18 22:04, Guido van Rossum пише: Yes, #3, and what Tim says. Thank you. This helps a much. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe:

Re: [Python-Dev] Subtle difference between f-strings and str.format()

28.03.18 22:05, Paul Moore пише I can't imagine (non-contrived) code where the fact that a is formatted before b is evaluated would matter, so I'm fine with option 3. If formatting a and evaluating b both raise exceptions, the resulting exception depends on the order. $ ./python -bb

Re: [Python-Dev] Subtle difference between f-strings and str.format()

28.03.18 21:30, Tim Peters пише: [Tim] I have a hard time imaging how that could have come to be, but if it's true I'd say the unoptimized code was plain wrong. The dumbest possible way to implement `f() and g()` is also the correct ;-) way: result = f() if not bool(result): result =

Re: [Python-Dev] Subtle difference between f-strings and str.format()

28.03.18 19:20, Guido van Rossum пише: Hm, without thinking too much about it I'd say it's okay to change the evaluation order. Do you mean the option 3, right? This is the simplest option. I have already wrote a PR for optimizing old-style formating [1], but have not merged it yet due to

[Python-Dev] Subtle difference between f-strings and str.format()

There is a subtle semantic difference between str.format() and "equivalent" f-string. '{}{}'.format(a, b) f'{a}{b}' In the former case b is evaluated before formatting a. This is equivalent to t1 = a t2 = b t3 = format(t1) t4 = format(t2) r = t3 + t4 In the latter

Re: [Python-Dev] Use more Argument Clinic Annotations?

25.03.18 19:47, Dave Halter пише: Is there a way though in which the __text_signature__ could contain the information `-> str` or do we need to engineer that first? There is no such way currently. ___ Python-Dev mailing list Python-Dev@python.org

Re: [Python-Dev] Replacing self.__dict__ in __init__

25.03.18 18:38, Tin Tvrtković пише: For example, for a simple class with 9 attributes: What are results for classes with 2 or 100 attributes? What are results in Python 3.5? I think you are playing on thin ice. Your results depend on implementation details of the bytecode (in particularly

Re: [Python-Dev] Use more Argument Clinic Annotations?

25.03.18 15:36, Dave Halter пише: I recently started testing Jedi with Python 3.7. Some tests broke. I realized that one of the things that changed in 3.7 was the use of argument clinic in methods like str.replace. The issue is that the text signature doesn't contain a return annotation.

[Python-Dev] Move ensurepip blobs to external place

Currently the repository contains bundled pip and setuptools (2 MB total) which are updated with every release of pip and setuptools. This increases the size of the repository by around 2 MB several times per year. There were total 37 updates of Lib/ensurepip/_bundled, therefore the repository

Re: [Python-Dev] What is the purpose of NEXT_BLOCK()?

21.03.18 17:13, Guido van Rossum пише: Maybe spelunking in the Python 2 branch will help? It seems it was introduced in 2005 by Jeremy Hylton with this comment: /* The distinction between NEW_BLOCK and NEXT_BLOCK is subtle.  (I'd    like to find better names.)  NEW_BLOCK() creates a new block

[Python-Dev] What is the purpose of NEXT_BLOCK()?

There is the NEXT_BLOCK() macro in compile.c. It creates a new block, creates an implicit jump from the current block to the new block, and sets it as the current block. But why it is used? All seems working if remove NEXT_BLOCK(). If there was a need of NEXT_BLOCK() (if it reduces the

[Python-Dev] Deprecating float.is_integer()

I searched usages of is_integer() on GitHub and have found that it is used *only* in silly code like (x/5).is_integer(), (x**0.5).is_integer() (or even (x**(1/3)).is_integer()) and in loops like: i = 0 while i < 20: if i.is_integer(): print(i) i += 0.1

Re: [Python-Dev] Symmetry arguments for API expansion

13.03.18 10:35, Larry Hastings пише: On 03/12/2018 08:41 PM, Guido van Rossum wrote: If you force me to choose between allowing hex(3.14) or 42.hex() I'll choose the latter I assume you meant (42).hex() here.  If you're also interested in changing the language to permit 42.hex(), well, color

Re: [Python-Dev] Symmetry arguments for API expansion

12.03.18 21:15, Guido van Rossum пише: There's a reason why adding this to int feels right to me. In mypy we treat int as a sub*type* of float, even though technically it isn't a sub*class*.. The absence of an is_integer() method on int means that this code has a bug that mypy doesn't catch:

Re: [Python-Dev] Symmetry arguments for API expansion

12.03.18 18:49, Raymond Hettinger пише: There is a feature request and patch to propagate the float.is_integer() API through rest of the numeric types ( https://bugs.python.org/issue26680 ). While I don't think it is a good idea, the OP has been persistent and wants his patch to go forward.

Re: [Python-Dev] Fix strncpy warning with gcc 8 (#5840)

06.03.18 12:34, Xiang Zhang пише: https://github.com/python/cpython/commit/efd2bac1564f8141a4eab1bf8779b412974b8d69 commit: efd2bac1564f8141a4eab1bf8779b412974b8d69 branch: master author: Siddhesh Poyarekar committer: Xiang Zhang date:

Re: [Python-Dev] Backward incompatible change about docstring AST

28.02.18 12:49, Armin Rigo пише: On 27 February 2018 at 15:32, Serhiy Storchaka <storch...@gmail.com> wrote: 1. CPython and PyPy set different position for multiline strings. PyPy sets the position of the start of string, but CPython sets the position of the end of the string. A p

Re: [Python-Dev] Backward incompatible change about docstring AST

28.02.18 00:31, Terry Reedy пише: 2. Usually the position of the docstring is used for determining the absolute position of some fragments in the docstring (for example doctests). But since the literal string can contain \n and escaped newlines, and this information is lost in AST, the

Re: [Python-Dev] Backward incompatible change about docstring AST

27.02.18 15:37, INADA Naoki пише: Of course, this change was backward incompatible. Tools reading/writing docstring via AST will be broken by this change. For example, it broke PyFlakes, and PyFlakes solved it already. https://github.com/PyCQA/pyflakes/pull/273 Other examples: coveragepy:

Re: [Python-Dev] The `for y in [x]` idiom in comprehensions

23.02.18 19:30, Guido van Rossum пише: I'm not saying anything new here, but since you asked specifically for my opinion: I don't care for the idiom; it's never occurred to me before, and it smells of cleverness. If I saw it in a code review I would probably ask for a regular for-loop to make

Re: [Python-Dev] The `for y in [x]` idiom in comprehensions

22.02.18 23:33, Barry Warsaw пише: On Feb 22, 2018, at 11:04, Serhiy Storchaka <storch...@gmail.com> wrote: Stephan Houben proposed an idiom which looks similar to new hypothetic syntax: result = [y + g(y) for x in range(10) for y in [f(x)]] `for y in [expr]` in a comprehension

[Python-Dev] The `for y in [x]` idiom in comprehensions

Yet one discussion about reusing common subexpressions in comprehensions took place last week on the Python-ideas maillist (see topic "Temporary variables in comprehensions" [1]). The problem is that in comprehension like `[f(x) + g(f(x)) for x in range(10)]` the subexpression `f(x)` is

Re: [Python-Dev] Update tcl/tk to 8.6.latest on Windows?

21.02.18 12:12, Terry Reedy пише: 3.7.0b1 Windows installer installs tcl/tk 8.6.6, which is a couple of years old.  Same for Windows repository builds.  I believe the MacOS installer shipped with something later.  Can we update Windows to the current 8.6.8? Yes, please open an issue for

Re: [Python-Dev] [RELEASED] Python 3.4.8 and Python 3.5.5 are now available

11.02.18 04:15, Larry Hastings пише: Actually, it was updated on the server, but somehow the old version was sticking around in the CDN cache.  I "purged" it and it's fine now. Weird that it would linger this long! Great! ___ Python-Dev mailing

Re: [Python-Dev] Deprecate crypt module and revert PR 3854

02.02.18 18:18, Guido van Rossum пише: I'm all for nudging people in the direction of xcrypt. I assume we can't just switch the C-level crypt with xcrypt and leave the Python API unchanged? However until a usable solution exist (either in the stdlib or as 3rd party) I don't think we should

Re: [Python-Dev] Positional-only parameters in Python

17.01.18 16:34, Victor Stinner пише: In Februrary 2017, I proposed on python-ideas to change the Python syntax to allow to declare positional-only parameters in Python: https://mail.python.org/pipermail/python-ideas/2017-February/044879.html

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

09.01.18 01:05, Gregory P. Smith пише: On Mon, Jan 8, 2018 at 12:36 PM Serhiy Storchaka <storch...@gmail.com <mailto:storch...@gmail.com>> wrote: 08.01.18 11:11, Pablo Galindo Salgado пише: > Following Gregory's comment on the PR I understand that he is proposing

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

09.01.18 05:31, Nick Coghlan пише: On 8 January 2018 at 19:11, Pablo Galindo Salgado wrote: Following Gregory's comment on the PR I understand that he is proposing to have three objects in the os module representing each action and pass a sequence of these objects to the

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

08.01.18 11:11, Pablo Galindo Salgado пише: Following Gregory's comment on the PR I understand that he is proposing to have three objects in the os module representing each action and pass a sequence of these objects to the Python API. What I am not sure about this is that there is no previous

Re: [Python-Dev] 'continue'/'break'/'return' inside 'finally' clause

02.01.18 22:31, Neil Schemenauer пише: Serhiy Storchaka <storch...@gmail.com> wrote: Currently 'break' and 'return' are never used inside 'finally' clause in the stdlib. See the _recv_bytes() function: Lib/multiprocessing/connection.py: 316 Thank you Neil! I missed this case becau

Re: [Python-Dev] Heap allocate type structs in native extension modules?

26.12.17 12:16, Hugh Fisher пише: I have a Python program which generates the boilerplate code for native extension modules from a Python source definition. (http://bitbucket.org/hugh_fisher/fullofeels if interested.) The examples in the Python doco and the "Python Essential Reference" book all

Re: [Python-Dev] 'continue'/'break'/'return' inside 'finally' clause

28.12.17 16:38, Guido van Rossum пише: Looks to me the prohibition was to prevent a crash. It makes more sense to fix it. The crash can be fixed by just removing the check after finishing issue17611. But is there any use case for 'continue'/'break'/'return' inside 'finally' clause? The

[Python-Dev] 'continue'/'break'/'return' inside 'finally' clause

Currently 'continue' is prohibited inside 'finally' clause, but 'break' and 'return' are allowed. What is the r 'continue' was prohibited in https://bugs.python.org/issue1542451. Should we prohibit also 'break' and 'return' or allow 'continue'? 'break' and 'return' are never used inside

Re: [Python-Dev] __init_subclass__ is a class method (Was: Make __class_getitem__ a class method)

16.12.17 00:48, Ivan Levkivskyi пише: Actually documentation https://docs.python.org/3.6/reference/datamodel.html#customizing-class-creation already says `classmethod object.__init_subclass__(cls)` I am not an expert in this, so I am not sure if the docs can be improved here (maybe we can add

Re: [Python-Dev] Make __class_getitem__ a class method

15.12.17 20:02, Yury Selivanov пише: But nobody decorates __new__ with a @staticmethod. And making __class_getitem__ a @classmethod will only confuse users -- that's all I'm saying. So I'm +1 to keep the things exactly as they are now. It would be great do document that in order to implement

Re: [Python-Dev] Guarantee ordered dict literals in v3.7?

15.12.17 17:53, Guido van Rossum пише: Make it so. "Dict keeps insertion order" is the ruling. Thanks! What should dict.popitem() return? The first item, the last item, or unspecified? ___ Python-Dev mailing list Python-Dev@python.org

Re: [Python-Dev] Make __class_getitem__ a class method

15.12.17 18:47, Yury Selivanov пише: Shouldn't we optimize the usability for pure-Python first, and then for C API? Right now we have the '__new__' magic method, which isn't a @classmethod. Making '__class_getitem__' a @classmethod will confuse regular Python users. For example: class

[Python-Dev] __init_subclass__ is a class method (Was: Make __class_getitem__ a class method)

15.12.17 19:04, Ivan Levkivskyi пише: Good point! Pure Python will be the primary use case and we have another precedent for "automatic" class method: __init_subclass__ (it does not need to be decorated). __init_subclass__ is very different beast, and parallels with it can be confusing. It

Re: [Python-Dev] Accepting PEP 560 -- Core support for typing module and generic types

15.12.17 18:36, Antoine Pitrou пише: Do you have any general idea how to speed up class creation? Some work was done in [https://bugs.python.org/issue31336]. Currently I have no ideas. Creating a class is 1-2 orders slower than creating a function. And adding parent classes significantly

[Python-Dev] Make __class_getitem__ a class method

The class itself always is passed as the first argument to __class_getitem__(): cls.__class_getitem__(cls, item) I propose to make __class_getitem__ a class method. This will make simpler implementing it in C. Currently it should be declared with flags METH_VARARGS|METH_STATIC and

Re: [Python-Dev] Accepting PEP 560 -- Core support for typing module and generic types

15.12.17 04:00, Guido van Rossum пише: In the light of Antoine's and Stephan's feedback I think this can be reconsidered -- while I want to take a cautious stance about resource consumption I don't want to stand in the way of progress. I don't see any problems with implementing this on types

Re: [Python-Dev] Accepting PEP 560 -- Core support for typing module and generic types

15.12.17 02:33, Antoine Pitrou пише: On Thu, 14 Dec 2017 16:03:48 -0800 Guido van Rossum wrote: A slot is pretty expensive, as *every* class in existence will be another 8 bytes larger (and possibly more due to malloc rounding). I'm always surprised by the discussions about

Re: [Python-Dev] Accepting PEP 560 -- Core support for typing module and generic types

15.12.17 02:25, Yury Selivanov пише: My motivation to add the slot wasn't the performance: it's just not possible to have a class-level __getitem__ on types defined in C. The only way is to define a base class in C and then extend it in pure-Python. This isn't too hard usually, though. What

Re: [Python-Dev] Zero-width matching in regexes

05.12.17 01:21, MRAB пише: I've finally come to a conclusion as to what the "correct" behaviour of zero-width matches should be: """always return the first match, but never a zero-width match that is joined to a previous zero-width match""". If it's about to return a zero-width match that's

Re: [Python-Dev] Zero-width matching in regexes

06.12.17 15:37, Paul Moore пише: Behaviour (1) means that we'd get >>> regex.sub(r'\w*', 'x', 'hello world', flags=regex.VERSION1) 'xx xx' (because \w* matches the empty string after each word, as well as each word itself). I just tested in Perl, and that is indeed what happens there as well.

Re: [Python-Dev] Zero-width matching in regexes

05.12.17 22:26, Terry Reedy пише: On 12/4/2017 6:21 PM, MRAB wrote: I've finally come to a conclusion as to what the "correct" behaviour of zero-width matches should be: """always return the first match, but never a zero-width match that is joined to a previous zero-width match""". Is this

Re: [Python-Dev] Zero-width matching in regexes

05.12.17 01:21, MRAB пише: I've finally come to a conclusion as to what the "correct" behaviour of zero-width matches should be: """always return the first match, but never a zero-width match that is joined to a previous zero-width match""". If it's about to return a zero-width match that's

Re: [Python-Dev] PEP 565: Show DeprecationWarning in __main__

05.12.17 22:10, Victor Stinner пише: Maybe we need something to declare the code that we own, to enable warnings on them. Just compare __author__ with the name of the user running a script. ;-) ___ Python-Dev mailing list Python-Dev@python.org

Re: [Python-Dev] PEPs: ``.. code:: python`` or ``::`` (syntax highlighting)

30.11.17 15:00, Wes Turner пише: In ReStructuredText, this gets syntax highlighted because of the code directive [1][2][3]: .. code:: python    import this    def func(*args, **kwargs):        pass This also gets syntax highlighted as python[3]: .. code:: python    import this    def

Re: [Python-Dev] Py_DECREF(m) on PyInit_xxx() failure?

30.11.17 17:42, Victor Stinner пише: CPython has many C extensions with non-trivial PyInit_xxx() functions which has to handle failures. A few modules use "Py_DECREF(m); retutrn NULL;", but most functions only do "return NULL;". Is it a reference leak or not? Example from Modules/posixmodule.c:

Re: [Python-Dev] Third and hopefully final post: PEP 557, Data Classes

30.11.17 03:02, Guido van Rossum пише: I tried to look up the discussion but didn't find much except that you flagged this as an issue. To repeat, your concern is that isdataclass() applies to *instances*, not classes, which is how Eric has designed it, but you worry that either through the

Re: [Python-Dev] Removing files from the repository

29.11.17 21:00, Guido van Rossum пише: That sounds a bit excessive. Is there a recent incident that inspired this proposal? The concrete inspiration is issue32159 [1]. I am still not sure that removing these scripts is needed. But there were other cases in which I was not sure about the

Re: [Python-Dev] Removing files from the repository

29.11.17 20:47, Ryan Gonzalez пише: Doesn't Git make this rather easy, though? e.g. you can find all deleted files with: git log --diff-filter=D --summary and find a specific file with (showing glob patterns): git log --all --full-history -- **/thefile.* and then show it: git show -- or

[Python-Dev] Removing files from the repository

After removing files from the repository they disappear from the source tree, and it is even hard to notice this if you don't use it regularly. It is hard to track the history of the removed file even if you know it exact path. If you know it only approximate this is harder. I think that any

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

28.11.17 22:31, Raymond Hettinger пише: 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 more Perlish look and a more

[Python-Dev] Regular expressions: splitting on zero-width patterns

The two largest problems in the re module are splitting on zero-width patterns and complete and correct support of the Unicode standard. These problems are solved in regex. regex has many other features, but they are less important. I want to tell the problem of splitting on zero-width

<    1   2   3   4   5   6   7   8   9   10   >