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

24.07.19 13:33, Rob Cliffe via Python-Dev пише: Naive question: Is there a way (in Python) to get at the underlying dict from a dict.values object, or more generally from any dict view object? No, there is not. As well as there is no way to get at the underlying list, tuple, dict from corresp

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

25.07.19 01:15, Greg Ewing пише: Steven D'Aprano wrote: Currently that assertion fails. Should it? Putting aside the convenience of "do nothing, just inherit the object.__eq__ behaviour" do you think that the current behaviour is *correct*? What I'm getting from this thread is that there are

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

25.07.19 22:05, Kyle Stanley пише: I would agree that a doc change should occur if it is decided that the current behavior is appropriate, but I would like to mention that in the current [documentation for `object.__eq__()`](https://docs.python.org/3/reference/datamodel.html#object.__eq__), it

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

25.07.19 23:19, Kyle Stanley пише: Serhiy Storchaka wrote: Actually, the == operator cannot return NotImplemented. Thanks for the clarification. What is the reason for this limitation and is it only possible for the `==` operator to return one of `None`, `False`, or `True`? The

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

26.07.19 08:27, Inada Naoki пише: On Fri, Jul 26, 2019 at 2:03 PM Random832 wrote: Items also sometimes contains unhashable types, and some methods simply fail in that case. I suggest that this precedent provides a way forward - implement the entire intuitive "contains the same amount of each

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

05.08.19 07:22, raymond.hettin...@gmail.com пише: We should revisit what we want to do (if anything) about invalid escape sequences. For Python 3.8, the DeprecationWarning was converted to a SyntaxWarning which is visible by default. The intention is to make it a SyntaxError in Python 3.9.

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

06.08.19 20:37, Paul Moore пише: I don't see issues reported in the bug trackers for docutils and bottle. Maybe as a start, someone could raise issues there? The warning in docutils was fixed. https://sourceforge.net/p/docutils/code/8255/ ___ Python-D

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

07.08.19 01:37, Brett Cannon пише: I think this is a good example of how the community is not running tests with warnings on and making sure that their code is warnings-free. This warning has existed for at least one full release and fixing it doesn't require some crazy work-around for backwar

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

07.08.19 03:31, Rob Cliffe via Python-Dev пише: How about: whenever a third-party library uses a potentially-wrong escape sequence, it creates a message on the console. Then when someone sees that message, they can post a bug report against the package. Would not it just increase the amount of

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

07.08.19 03:57, Gregory P. Smith пише: People distribute code via pypi.  if we reject uploads of packages with these problems and link to fixers (modernize can be taught what to do), we prevent them from spreading further. How can we check that there are such problems in the package? Pass all

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

08.08.19 07:55, Toshio Kuratomi пише: Like the Ansible feature, though, the problem is that over time we've discovered that it is hard to educate users about the exact characteristic of the feature (\k == k but \n == newline; No, \k == \\k. This differs from most other programming languages. __

[Python-Dev] Re: Pickle for C extension?

19.10.20 20:39, Marco Sulla пише: > TL;DR Is it possible to use C code to implement the (un)pickling of an > type written in a C extension, as it was written in _pickle.c? > > Long explaining: I'm trying to create a C extension for frozendict. For > simplicity, first I wrote it in CPython, then I

[Python-Dev] Re: When to remove BytesWarning?

26.10.20 10:10, Inada Naoki пише: > Of course, there are some runtime costs too. > > https://github.com/python/cpython/blob/fb5db7ec58624cab0797b4050735be865d380823/Modules/_functoolsmodule.c#L802 > https://github.com/python/cpython/blob/fb5db7ec58624cab0797b4050735be865d380823/Objects/codeobject.

[Python-Dev] Re: When to remove BytesWarning?

24.10.20 06:19, Inada Naoki пише: > To avoid BytesWarning, the compiler needs to do some hack when they > need to store bytes and str constants in one dict or set. > BytesWarning has maintenance costs. It is not huge, but significant. > > When can we remove it? My idea is: > > 3.10: Deprecate the

[Python-Dev] Re: Macro for logging

21.10.20 15:30, Antoine Pitrou пише: > On Wed, 21 Oct 2020 14:19:37 +0200 > Marco Sulla wrote: >> If not already present, do you think it's useful to add a macro that does >> something like >> >> # ifdef Py_DEBUG >> fprintf(stderr, "%s\n", message); >> # endif > > In general, you want to do t

[Python-Dev] Re: Drop Solaris, OpenSolaris, Illumos and OpenIndiana support in Python

29.10.20 23:43, Victor Stinner пише: > * Current best effort support (no change): changes only happen if a > core dev volunteers to review and merge a change written by a > contributor. It is my preference. Several years ago I tested and fixed Python on OpenIndiana in virtual machine, but I was n

[Python-Dev] Re: Who is target reader of tutorial?

05.11.20 11:12, Inada Naoki пише: > Since "How To" guide is not organized well, it is very tempting to > write all details in tutorial. > I have seen may pull requests which "improve" tutorial by describe > more details and make > the tutorial more perfect. > > But adding more and more information

[Python-Dev] Re: When to remove BytesWarning?

11.11.20 15:05, John Hagen пише: > If I recall, it was str(bytes) warning that flagged in a few places and was > missing a .decode() call or similar. > > It seems like the bytes== warnings could be implemented in a type checker > such as mypy, if it doesn't > already do this. Assuming you have c

[Python-Dev] Re: Why does "except Ex as x" not restore the previous value of x?

17.11.20 11:55, Mark Shannon пише: > I'm wondering why > ``` > x = "value" > try: >     1/0 > except Exception as x: >     pass > ``` > > does not restore "value" to x after > the `except` block. > > There doesn't seem to be an explanation for this behavior in the docs or > PEPs, that I can find.

[Python-Dev] Re: Where is the SQLite module maintainer

27.12.20 22:20, Erlend Aasland пише: > Who can help me review code that touches the sqlite3 module code base? > > > I've received a lot of constructive reviews from Victor Stinner, Dong-he > Na and Pablo Galindo on my past sqlite3 PR's; thank you so much! I still > feel uncomfortable requesting t

[Python-Dev] Re: why include cpython/*.h, Need this macro ? # error "this header file must not be included directly"

10.01.21 09:53, junyixie пише: > #ifndef Py_LIMITED_API > # define Py_CPYTHON_FILEOBJECT_H > # include "cpython/fileobject.h" > # undef Py_CPYTHON_FILEOBJECT_H > #endif > > cpython/fileobject.h > ``` > #ifndef Py_CPYTHON_FILEOBJECT_H > # error "this header file must not be included directly"

[Python-Dev] Re: Let's Fix Class Annotations -- And Maybe Annotations Generally

12.01.21 03:21, Larry Hastings пише: > I forgot about __slots__!  Yup, it's optional, and you can even delete > it, though after the class is defined I'm not sure how much difference > that makes. It affects pickling if __slotnames__ is not set yet. The latter is set when you pickle or copy an ins

[Python-Dev] Re: Bumping minimum Sphinx version to 3.2 for cpython 3.10?

12.01.21 22:38, Julien Palard via Python-Dev пише: > During the development of cpython 3.10, Sphinx was bumped to 3.2.1. > > Problem is Sphinx 3 have some incompatibilities with Sphinx 2, some that > we could work around, some are bit harder, so we may need to bump > `needs_sphinx = '3.2'` (curr

[Python-Dev] Re: Bumping minimum Sphinx version to 3.2 for cpython 3.10?

13.01.21 01:28, Victor Stinner пише: > I looked at Sphinx and Python versions of Debian, Ubuntu and Fedora: > https://bugs.python.org/issue42843#msg384963 > > In my list, there is only Debian Buster (stable) which doesn't have > Sphinx 3 yet. It uses Python 3.7 and so would not be affected by > Py

[Python-Dev] Re: What's up with assignment expression and tuples?

05.02.21 09:51, Paul Sokolovsky пише: > a0 = 0 > b0 = 10 > while ((a1, b1) := phi([a0, a2], [b0, b2]))[0] < 5: > a2 = a1 + 1 > b2 = b1 + 1 Such code quickly becomes unreadable. Especially if in real code function has additional arguments and names are longer that 2-3 characters. The follo

[Python-Dev] Re: Signature discrepancies between documentation and implementation

09.02.21 12:22, Erlend Aasland пише: > What's the recommended approach with issues like > https://bugs.python.org/issue43094? Change the docs or the implementation? I > did a quick search on bpo, but could not find similar past issues. If the documentation and the C implemented function contradi

[Python-Dev] Re: [Release management] schedule for renaming the default branch

10.03.21 16:06, Pablo Galindo Salgado пише: > # What you need to do? > > You just need to update your local clone after the branch name changes. > From the local clone of the repository on a computer, > run the following commands to update the name of the default branch. > > $ git branch -m maste

[Python-Dev] Re: Non-monotonically increasing line numbers in dis.findlinestarts() output

18.03.21 03:39, Victor Stinner пише: > I'm happy to see that Python 3.10 now also implements faster bytecode > which rely on this change ;-) It was used long time ago before 3.10. For example: a[i] = \ f() 2 0 LOAD_NAME0 (f) 2 CALL_FUNCTION

[Python-Dev] Re: Where and how can I contribute?

26.03.21 20:37, Terry Reedy пише: > On 3/26/2021 6:29 AM, Marco Sulla wrote: >> I would contribute to the project in my spare time. Can someone point >> me to some easy task? I know C and the Python C API a little. > > Review existing PRs.  In some cases (ask), convert existing patches > posted on

[Python-Dev] Re: When we remove 'U' mode of open()?

07.04.21 19:13, Victor Stinner пише: > Hi Inada-san, > > I'm +0 on removing again the flag, but I would prefer to not endorse > the responsibility. I am already responsible for enough incompatible > changes in Python 3.10 :-D > > Some context on this "U" open mode. The flag is accepted by many >

[Python-Dev] Re: NamedTemporaryFile and context managers

08.04.21 23:31, Ethan Furman пише: > In issue14243 [1] there are two issues being tracked: > > - the difference in opening shared files between posix and Windows > - the behavior of closing the underlying file in the middle of >   NamedTemporaryFile's context management > > I'd like to address an

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

26.04.18 21:37, Serhiy Storchaka пише: > 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 despit

[Python-Dev] Re: 0xfor 3. Parser bug?

14.04.21 13:22, Stefano Borini пише: > This was just posted on SO > > https://stackoverflow.com/questions/67083039/why-does-python-return-15-for-0xfor-x-in-1-2-3 > > I can reproduce it with a simpler example > 0xfor 3 > 15 > > Is it a bug in the parser, or working as intended? It's not onl

[Python-Dev] Re: How about using modern C++ in development of CPython ?

24.03.21 11:54, redrad...@gmail.com пише: > What about of using modern C++ in developing CPython ? > > With C++ we can get the following benefits: > 1) Readability - less code, most code is hidden by abstraction without losing > performance > 2) Maintainability - no code duplication in favor of u

[Python-Dev] Re: Can we change python -W option and PYTHONWARNINGS to use a regex for the message?

16.04.21 16:07, Victor Stinner пише: > I propose to change the -W command line option and the PYTHONWARNINGS > environment variable to use the message as a regular expression in > Python 3.10. Or does anyone have a reason to keep the current behavior > as it is? > > I created https://bugs.python.o

[Python-Dev] Re: str() vs format(): trivia question

20.04.21 22:01, Guido van Rossum пише: > So to be clear, that one user wants f"{Color.RED}" to return "1" and not > " Color.RED" (or  something like that). The user should write f"{int(Color.RED)}" or f"{Color.RED.value}". I have also an idea to support of additional conversion characters, so the

[Python-Dev] Re: str() vs format(): trivia question

20.04.21 17:56, Ethan Furman пише: > urllib.urlencode currently uses `str()` on its non-bytes objects before > encoding the result.  This causes a compatibility break when integer > module constants are converted to IntEnum, as `str(IntEnum.MEMBER)` no > longer returns the integer representation; h

[Python-Dev] Re: In what tense should the changelog be written?

30.04.21 05:57, Larry Hastings пише: > When one writes one's "blurb" for the changelog, in what tense should it > be? See the previous discussion on this topic: https://mail.python.org/archives/list/python-dev@python.org/thread/C342Y73LALVFLI2ACFB3SH6ZDT2YTGPC/ . I always use "fixed", "removed",

[Python-Dev] Re: Proposal: declare "unstable APIs"

03.06.21 20:10, Guido van Rossum пише: > This is not a complete thought yet, but it occurred to me that while we > have deprecated APIs (which will eventually go away), and provisional > APIs (which must mature a little before they're declared stable), and > stable APIs (which everyone can rely on)

[Python-Dev] Re: Proposal: declare "unstable APIs"

04.06.21 12:08, Petr Viktorin пише: > It is used, and I started the work :) > See e.g. > https://docs.python.org/3.10/c-api/sequence.html#c.PySequence_Concat Great news! Several core developers (including me) tried to solve this problem, but a large amount of work stopped us at an early stage. Gla

[Python-Dev] Re: Proposal: declare "unstable APIs"

06.06.21 06:48, Guido van Rossum пише: > On Fri, Jun 4, 2021 at 6:15 AM Victor Stinner > wrote: > If possible, I would prefer to make PyThreadState, PyCodeObject and > other structures opaque, and only go through getter and setter > functions ;-) PyCode_New(

[Python-Dev] Re: Making PY_SSIZE_T_CLEAN not mandatory.

07.06.21 06:05, Inada Naoki пише: > Since Python 3.8, PyArg_Parse*() APIs and Py_BuildValue() APIs emitted > DeprecationWarning when > '#' format is used without PY_SSIZE_T_CLEAN defined. > In Python 3.10, they raise a RuntimeError, not a warning. Extension > modules can not use '#' format with int

[Python-Dev] Re: Making PY_SSIZE_T_CLEAN not mandatory.

07.06.21 08:41, Hai Shi пише: > There have an another question. There have many C API defined under > PY_SSIZE_T_CLEAN, for example: _PyArg_Parse_SizeT(). > Could we remove or merge them after making PY_SSIZE_T_CLEAN not mandatory? We should support binary compatibility to some degree, so there s

[Python-Dev] Re: Delayed evaluation of f-strings?

24.06.21 12:37, Eric Nieuwland пише: > In a recent discussion with a colleague we wondered if it would be > possible to postpone the evaluation of an f-string so we could use it > like a regular string and .format() or ‘%’. You can just use lambda: delayed_fstring = lambda: f"The current name

[Python-Dev] types.Union or types.UnionType?

In 3.10 the union type (the type of the result of the | operator for types) was added (https://www.python.org/dev/peps/pep-0604/). It is exposed as types.Union. There are differences between typing.Union and types.Union: * typing.Union is indexable, types.Union is not. * types.Union is a class, ty

[Python-Dev] Re: Should we try to get a complete draft of What's New by b1?

11.08.21 21:35, Brett Cannon пише: > So my question is whether we want to push to be more diligent about > updating What's New by b1 so people can provide feedback during the > betas beyond just reporting breaking changes? I think that What's New should be updated as soon as possible, immediately

[Python-Dev] Re: Making code object APIs unstable

13.08.21 20:24, Guido van Rossum пише: > If these weren't part of the stable ABI, I'd choose (E). But because > they are, I think only (A) or (B) are our options. The problem with (C) > is that if there's code that links to them but doesn't call them (except > in some corner case that the user can

[Python-Dev] Re: Discrepancy between what aiter() and `async for` requires on purpose?

29.08.21 23:16, Brett Cannon пише: > If you look at > https://github.com/python/cpython/blob/b11a951f16f0603d98de24fee5c023df83ea552c/Python/ceval.c#L2409-L2451 > > you will see that `async

[Python-Dev] Re: [Python-ideas] Re: open functions in dbm submodule need to support path-like object

08.09.21 08:19, David Mertz, Ph.D. пише: > I attempted to do this today, as my first actual contribution to CPython > itself.  I think the prior attempt went down a wrong path, which is why > neither PR could actually pass tests. > > I've been looking at `posixmodule.c` for comparison, specificall

[Python-Dev] deprecated-removed

I always thought that the "deprecated" directive is used if the term of removing the deprecated feature is not set yet, and the "deprecated-removed" directive is used if it is set. After removing the feature both directives are replaced with the "versionchanged" directive which only specifies the v

[Python-Dev] Re: f-strings in the grammar

20.09.21 14:18, Pablo Galindo Salgado пише: > * The parser will likely have "\n" characters and backslashes in > f-strings expressions, which currently is impossible: What about characters "\x7b", "\x7d", "\x5c", etc? What about newlines in single quotes? Currently this works: f'''{1 + 2}''' Bu

[Python-Dev] Re: Changing exception text in micro releases

24.09.21 16:51, Eric V. Smith пише: > This is clearly an improvement. My question is: is it okay to backport > this to 3.9 and 3.10? I think we have a rule that it's okay to change > the exception text, but I'm not sure how that applies to micro releases > (3.9.x, 3.10.1). I am sure that it will b

[Python-Dev] Re: Should I care what -3.14 // inf produces?

30.09.21 10:07, Jeff Allen пише: from decimal import Decimal Decimal('-3.14') // Decimal('Infinity') > Decimal('-0') You do not need an infinity to see the difference. >>> Decimal('3.14') % Decimal('2') Decimal('1.14') >>> Decimal('3.14') % Decimal('-2') Decimal('1.14') >>> Decimal('-3.

[Python-Dev] Re: RFC on Callable Type Syntax

07.10.21 19:41, S Pradeep Kumar пише: > 1. Syntax to replace Callable > > After a lot of discussion, there is strong consensus in typing-sig about > adding syntax to replace Callable. So, the above example would be > written as: > ```python > def print_purchases( >     user: User, >     formatter:

Re: [Python-Dev] cpython (2.7): Fix posixpath.realpath() for multiple pardirs (fixes issue #6975).

On 18.02.13 19:26, Antoine Pitrou wrote: On Mon, 18 Feb 2013 11:24:40 +0100 (CET) serhiy.storchaka wrote: +def test_realpath_curdir(self): +self.assertEqual(realpath('.'), os.getcwd()) +self.assertEqual(realpath('./.'), os.getcwd()) +self.assertEqual(realpath('/'.jo

Re: [Python-Dev] Disabling string interning for null and single-char causes segfaults

On 02.03.13 22:32, Terry Reedy wrote: I am just curious: does 3.3 still intern (some) unicode chars? Did the 256 interned bytes of 2.x carry over to 3.x? Yes, Python 3 interns an empty string and first 256 Unicode characters. ___ Python-Dev mailing

Re: [Python-Dev] Disabling string interning for null and single-char causes segfaults

On 01.03.13 17:24, Stefan Bucur wrote: Before digging deeper into the issue, I wanted to ask here if there are any implicit assumptions about string identity and interning throughout the interpreter implementation. For instance, are two single-char strings having the same content supposed to be i

Re: [Python-Dev] can't assign to function call

On 18.03.13 17:40, Steven D'Aprano wrote: On 19/03/13 02:01, Hrvoje Niksic wrote: Assigning to function calls is orthogonal to reference types. For example, Python manages assignment to subscripts without having references just fine: val = obj[index] # val = obj.__getitem__(index) obj[ind

Re: [Python-Dev] Recent changes to TextIOWrapper and its tests

On 18.03.13 22:26, Jeff Allen wrote: The puzzle is that it requires t.read() to succeed. When I insert a check for bytes type in all the places it seems necessary in my code, I pass the first two conditions, but since t.read() also raises TypeError, the overall test fails. Is reading the stream

Re: [Python-Dev] Rough idea for adding introspection information for builtins

On 19.03.13 06:45, Larry Hastings wrote: 4. Store a string that looks like the Python declaration of the signature, and parse it (Nick's suggestion). For foo above, this would be "(arg,b=3,*,kwonly='a')". Length: 23 bytes. Strip parenthesis and it will be only 21 bytes long. We'd want one m

[Python-Dev] Tarfile CLI

There is a proposition to add a command line interface to tarfile module. It will be useful on platforms where tar is not included in the base system. The question is about interface. Should it be a subset of tar options (-t as --extract, -t as --list, -f to specify an archive name) or be sim

Re: [Python-Dev] Tarfile CLI

On 19.03.13 09:52, Serhiy Storchaka wrote: There is a proposition to add a command line interface to tarfile module. Link: http://bugs.python.org/issue13477 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo

Re: [Python-Dev] Recent changes to TextIOWrapper and its tests

On 18.03.13 22:26, Jeff Allen wrote: The puzzle is that it requires t.read() to succeed. When I insert a check for bytes type in all the places it seems necessary in my code, I pass the first two conditions, but since t.read() also raises TypeError, the overall test fails. Is reading the stream

Re: [Python-Dev] give IDLE its own NEWS section?

On 06.04.13 17:58, Benjamin Peterson wrote: I noticed IDLE changes were being put under the "library" section in Misc/NEWS. How about creating a IDLE section? http://bugs.python.org/issue17221 http://bugs.python.org/issue17506 ___ Python-Dev mailing

Re: [Python-Dev] cpython: Add fast-path in PyUnicode_DecodeCharmap() for pure 8 bit encodings:

On 09.04.13 23:29, victor.stinner wrote: http://hg.python.org/cpython/rev/53879d380313 changeset: 83216:53879d380313 parent: 83214:b7f2d28260b4 user:Victor Stinner date:Tue Apr 09 21:53:09 2013 +0200 summary: Add fast-path in PyUnicode_DecodeCharmap() for pure 8 bit enc

Re: [Python-Dev] PEP 435 -- Adding an Enum type to the Python standard library

On 12.04.13 15:55, Eli Bendersky wrote: The enumeration value names are available through the class members:: >>> for member in Colors.__members__: ... print(member) red green blue This is unnecessary because enumerations are iterable. Colors.__members__ is equal

Re: [Python-Dev] PEP 435 -- Adding an Enum type to the Python standard library

On 13.04.13 15:43, Eli Bendersky wrote: On Sat, Apr 13, 2013 at 1:31 AM, Serhiy Storchaka wrote: On 12.04.13 15:55, Eli Bendersky wrote: There is some ambiguity in the term "enumeration values". On the one hand, it's the singleton instances of the enumeration class (Colors.r

Re: [Python-Dev] PEP 435 -- Adding an Enum type to the Python standard library

On 13.04.13 03:13, Glenn Linderman wrote: On 4/12/2013 3:59 PM, Guido van Rossum wrote: class Insect(Enum): wasp = 1 bee = 1 ant = 2 We'd have Insect.wasp == Insect.bee < Insect.ant but Insect.wasp is not Insect.bee. can't define two names in the same enum to have the same valu

Re: [Python-Dev] cpython: Simplify the code of get_attrib_from_keywords somewhat.

On 22.04.13 15:52, eli.bendersky wrote: http://hg.python.org/cpython/rev/c9674421d78e changeset: 83494:c9674421d78e user:Eli Bendersky date:Mon Apr 22 05:52:16 2013 -0700 summary: Simplify the code of get_attrib_from_keywords somewhat. -PyDict_DelItem(kwds, attrib

Re: [Python-Dev] PEP 435 -- Adding an Enum type to the Python standard library

26.04.13 11:00, Greg Ewing написав(ла): However, there's a worse problem with defining enum inheritance that way. The subtype relation for extensible enums works the opposite way to that of classes. To see this, imagine a function expecting something of type Colors. It knows what to do with red,

Re: [Python-Dev] PEP 435 -- Adding an Enum type to the Python standard library

26.04.13 18:50, Larry Hastings написав(ла): On 04/26/2013 12:34 AM, Greg Ewing wrote: Or if, as Guido says, the only sensible things to use as enum values are ints and strings, just leave anything alone that isn't one of those. The standard Java documentation on enums: http://docs.oracle.

Re: [Python-Dev] PEP 435 -- Adding an Enum type to the Python standard library

26.04.13 11:00, Greg Ewing написав(ла): However, there's a worse problem with defining enum inheritance that way. The subtype relation for extensible enums works the opposite way to that of classes. To see this, imagine a function expecting something of type Colors. It knows what to do with red,

Re: [Python-Dev] PEP 435 -- Adding an Enum type to the Python standard library

26.04.13 05:13, Nick Coghlan написав(ла): With a merged design, it becomes *really* hard to give the instances custom behaviour, because the metaclass will somehow have to differentiate between namespace entries that are intended to be callables, and those which are intended to be instances of th

Re: [Python-Dev] PEP 435 -- Adding an Enum type to the Python standard library

Thank you for your answers, Barry. Eli already answered me most of my questions. 20.04.13 22:18, Barry Warsaw написав(ла): On Apr 13, 2013, at 11:31 AM, Serhiy Storchaka wrote: The str and repr of the enumeration class also provides useful information:: >>> pri

Re: [Python-Dev] Enumeration items: `type(EnumClass.item) is EnumClass` ?

29.04.13 21:14, Glenn Linderman написав(ла): 1) Enum could be subclassed to provide different, sharable, types of behaviors, then further subclassed to provide a number of distinct sets of values with those behaviors. You can use a multiclass inheritance for this. 2) Enum could be subclassed

Re: [Python-Dev] Enumeration item arguments?

30.04.13 00:59, Ethan Furman написав(ла): In the Planet example we saw the possibility of specifying arguments to enum item __init__: class Planet(Enum): MERCURY = (3.303e+23, 2.4397e6) VENUS = (4.869e+24, 6.0518e6) EARTH = (5.976e+24, 6.37814e6) MARS= (6.421e+23, 3.3

Re: [Python-Dev] [RELEASED] Python 3.2.5 and Python 3.3.2

16.05.13 08:20, Georg Brandl написав(ла): On behalf of the Python development team, I am pleased to announce the releases of Python 3.2.5 and 3.3.2. The releases fix a few regressions in 3.2.4 and 3.3.1 in the zipfile, gzip and xml.sax modules. Details can be found in the changelogs: It seems

Re: [Python-Dev] cpython: Undo the deprecation of _asdict().

18.05.13 10:06, raymond.hettinger написав(ла): http://hg.python.org/cpython/rev/1b760f926846 changeset: 83823:1b760f926846 user:Raymond Hettinger date:Sat May 18 00:05:20 2013 -0700 summary: Undo the deprecation of _asdict(). Why?

Re: [Python-Dev] cpython: Use PY_FORMAT_SIZE_T because Visual Studio does not understand %zd format.

18.05.13 19:37, richard.oudkerk написав(ла): http://hg.python.org/cpython/rev/0648e7fe7a72 changeset: 83829:0648e7fe7a72 user:Richard Oudkerk date:Sat May 18 17:35:19 2013 +0100 summary: Use PY_FORMAT_SIZE_T because Visual Studio does not understand %zd format. See also DE

Re: [Python-Dev] cpython: Use PY_FORMAT_SIZE_T because Visual Studio does not understand %zd format.

18.05.13 23:00, Serhiy Storchaka написав(ла): 18.05.13 19:37, richard.oudkerk написав(ла): http://hg.python.org/cpython/rev/0648e7fe7a72 changeset: 83829:0648e7fe7a72 user:Richard Oudkerk date:Sat May 18 17:35:19 2013 +0100 summary: Use PY_FORMAT_SIZE_T because Visual

Re: [Python-Dev] Why is documentation not inline?

20.05.13 01:33, Benjamin Peterson написав(ла): 2013/5/19 Demian Brecht : It seems like external docs is standard throughout the stdlib. Is there an actual reason for this? ernal One is legacy. It certainly wasn't possible with the old LaTeX doc system. Do you know that TeX itself written usin

Re: [Python-Dev] PEP 409 and the stdlib

20.05.13 16:12, Ethan Furman написав(ла): As a quick reminder, PEP 409 allows this: try: ... except AnError: raise SomeOtherError from None so that if the exception is not caught, we get the traditional single exception traceback, instead of the new: During han

Re: [Python-Dev] PEP 409 and the stdlib

21.05.13 10:17, Hrvoje Niksic написав(ла): On 05/20/2013 05:15 PM, Ethan Furman wrote: 1) Do nothing and be happy I use 'raise ... from None' in my own libraries 2) Change the wording of 'During handling of the above exception, another exception occurred' (no ideas as to what at the moment)

Re: [Python-Dev] PEP 409 and the stdlib

21.05.13 12:28, Hrvoje Niksic написав(ла): On 05/21/2013 10:36 AM, Serhiy Storchaka wrote: The above exception was converted to the following exception: ... That makes it clear that the conversion was explicit and (hopefully) intentional, and that the latter exception supersedes the

Re: [Python-Dev] PEP 409 and the stdlib

21.05.13 13:05, Hrvoje Niksic написав(ла): On 05/21/2013 11:56 AM, Serhiy Storchaka wrote: try: x = d['key'] except KeyError: x = fallback('key') def fallback(key): if key not in a: raise BusinessError(...) return 1 / a[key]

Re: [Python-Dev] PEP 409 and the stdlib

20.05.13 18:46, Antoine Pitrou написав(ла): I think it is a legitimate case where to silence the original exception. However, the binascii.Error would be more informative if it said *which* non-base32 digit was encountered. Please open a new issue for this request (note that no other binascii o

Re: [Python-Dev] Structural cleanups to the main CPython repo

28.05.13 16:07, Nick Coghlan написав(ла): On Tue, May 28, 2013 at 10:31 PM, Antoine Pitrou wrote: Le Tue, 28 May 2013 22:15:25 +1000, Nick Coghlan a écrit : * moved the main executable source file from Modules to a separate Apps directory Sounds fine (I don't like "Apps" much, but hey :-)).

Re: [Python-Dev] performance testing recommendations in devguide

29.05.13 21:00, Eric Snow написав(ла): Critically sensitive performance subjects * interpreter start-up time * module import overhead * attribute lookup overhead (including MRO traversal) * function call overhead * instance creation overhead * dict performance (the underlying namespace type) * tu

[Python-Dev] Obsoleted RFCs

Here is attached a list of obsoleted RFCs referred in the *.rst, *.txt, *.py, *.c and *.h files. I think it would be worthwhile to update the source code and documentation for more modern RFCs. For example for updating RFC3548 to RFC4648 there is an issue #16995. 821: Simple Mail Transfer Proto

Re: [Python-Dev] doctest and pickle

08.06.13 10:03, Ethan Furman написав(ла): Indeed, and it is already in several different ways. But it would be nice to have a pickle example in the docs that worked with doctest. I ended up doing what Barry did: >>> from test.test_enum import Fruit >>> from pickle import dumps, loads

Re: [Python-Dev] Obsoleted RFCs

08.06.13 11:23, Benjamin Peterson написав(ла): 2013/6/8 Serhiy Storchaka : Here is attached a list of obsoleted RFCs referred in the *.rst, *.txt, *.py, *.c and *.h files. I think it would be worthwhile to update the source code and documentation for more modern RFCs. Just because you change

Re: [Python-Dev] Obsoleted RFCs

08.06.13 11:42, M.-A. Lemburg написав(ла): On 08.06.2013 09:45, Serhiy Storchaka wrote: Here is attached a list of obsoleted RFCs referred in the *.rst, *.txt, *.py, *.c and *.h files. I think it would be worthwhile to update the source code and documentation for more modern RFCs. Thanks

Re: [Python-Dev] Obsoleted RFCs

By mistake some local files were added to the list. Here's an updated list. It now also contains low-case references. Attached also a script used to generate this list. 3: Documentation conventions. (Obsoleted by RFC0010) Lib/test/math_testcases.txt 10: Documentation conventions. (Obsoleted

Re: [Python-Dev] doctest and pickle

08.06.13 11:47, Ethan Furman написав(ла): In this case it is better to exclude a code example from doctests or add auxiliary code (i.e. as Steven suggested) to pass the doctest. Are you saying there is something wrong about what I have in place now? I would think that one line showing something

Re: [Python-Dev] cpython (2.7): Fix comment blocks. Adjust blocksize to a power-of-two for better divmod

14.06.13 11:46, Antoine Pitrou написав(ла): On Fri, 14 Jun 2013 07:06:49 +0200 (CEST) raymond.hettinger wrote: http://hg.python.org/cpython/rev/5accb0ac8bfb changeset: 84116:5accb0ac8bfb Fix comment blocks. Adjust blocksize to a power-of-two for better divmod computations. Is there any

Re: [Python-Dev] cpython: Move test_pep352 over to unittest.main()

14.06.13 04:18, brett.cannon написав(ла): http://hg.python.org/cpython/rev/af27c661d4fb changeset: 84115:af27c661d4fb user:Brett Cannon date:Thu Jun 13 21:18:43 2013 -0400 summary: Move test_pep352 over to unittest.main() You forgot about: from test.support import run_uni

Re: [Python-Dev] stat module in C -- what to do with stat.py?

20.06.13 16:05, Christian Heimes написав(ла): I have re-implemented the entire stat module in C. [1] It's a necessary step to fix portability issues. For most constants POSIX standards dictate only the name of the constant and its meaning but not its value. Only the values of permission bits (064

[Python-Dev] A type of out-of-range exception for %c

Currently %c formatting raises OverflowError if an argument is out of range. >>> '%c' % 1114112 Traceback (most recent call last): File "", line 1, in OverflowError: %c arg not in range(0x11) >>> '{:c}'.format(1114112) Traceback (most recent call last): File "", line 1, in OverflowError

Re: [Python-Dev] cpython (2.7): Fix comment blocks. Adjust blocksize to a power-of-two for better divmod

24.06.13 03:16, Raymond Hettinger написав(ла): I truly wasn't expecting the Spanish Inquisition :-) I only asked about the reasons. Previous reasons seemed reasonable to me and I wanted to know why a new code is better than the old. It will help me to use the best style in other places. Tha

Re: [Python-Dev] PyArg_ParseTupe(): parse unsigned integer and check for overflow

29.06.13 18:16, Nadeem Vawda написав(ла): I ran into the same problem in the _lzma module. My solution was to define a custom converter that does an explicit check before returning the value (see http://hg.python.org/cpython/file/default/Modules/_lzmamodule.c#l134). Definitely Argument Clinic s

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