Re: [Python-Dev] Best practice for documentation for std lib

On 09/22/2013 08:49 AM, Barry Warsaw wrote: On Sep 22, 2013, at 10:34 AM, Brett Cannon wrote: The rule of thumb I go by is the docstring should be enough to answer the question "what args does this thing take and what does it do in general to know it's the function I want and another one in the

[Python-Dev] Enum Eccentricities

http://bugs.python.org/issue19011 So, as anyone who has worked with Enum is probably aware by now, Enum's are a strange duck -- you might even call them platypuses. For example, Enum members are instances of the class, but they are defined inside the class structure, and new ones cannot be cr

Re: [Python-Dev] PEP 455: TransformDict

On 09/14/2013 12:31 PM, Guido van Rossum wrote: On Fri, Sep 13, 2013 at 11:40 AM, Antoine Pitrou wrote: Following the python-dev discussion, I've written a PEP to recap the proposal and the various arguments. It's inlined below, and it will probably appear soon at http://www.python.org/dev/peps

Re: [Python-Dev] Revert #12085 fix for __del__ attribute error message

On 09/22/2013 08:24 PM, Nick Coghlan wrote: On 23 Sep 2013 06:38, "Terry Reedy" mailto:tjre...@udel.edu>> wrote: On 9/22/2013 2:41 PM, Guido van Rossum wrote: On Sun, Sep 22, 2013 at 10:35 AM, Terry Reedy mailto:tjre...@udel.edu> >> wrote:

Re: [Python-Dev] Enum Eccentricities

On 09/23/2013 08:16 AM, Steven D'Aprano wrote: I would expect instance.blue to work, and I'm completely at a loss as to how Enum has managed to prevent it. [A peek behind the curtains...] Currently, Enum members do not live in the class dict. So when, for example, blue is searched for in red

Re: [Python-Dev] Revert #12085 fix for __del__ attribute error message

On 09/23/2013 02:19 PM, Nick Coghlan wrote: The relevant C API function is just called "PyErr_WriteUnraisable", not "PyErr_WriteUnraisableButThatIsTechnicallyWrongSinceItWasAlreadyRaisedAndWeJustCaughtItAndAreNowReportingItToStdErr". Wow. How many legs does that HumptyCamel have, anyway? ;)

Re: [Python-Dev] Revert #12085 fix for __del__ attribute error message

On 09/23/2013 02:35 PM, Antoine Pitrou wrote: On Tue, 24 Sep 2013 07:19:14 +1000 Nick Coghlan wrote: On 24 Sep 2013 01:24, "Antoine Pitrou" wrote: On Mon, 23 Sep 2013 18:51:04 +1000 Nick Coghlan wrote: On 23 September 2013 18:45, Antoine Pitrou wrote: Le Mon, 23 Sep 2013 18:17:51 +1000,

Re: [Python-Dev] project culture: take responsibility for your commits

On 10/02/2013 11:58 AM, Stefan Behnel wrote: I'm looking back on a rather unpleasant experience that I recently had in this developer community. Actually, twice by now. Here's what I take from it: You should take responsibility for your commits. It doesn't sound like you learned anything, the

Re: [Python-Dev] PEP 455: TransformDict

On 10/07/2013 02:24 PM, Steven D'Aprano wrote: On Fri, Oct 04, 2013 at 11:06:15PM +0200, Victor Stinner wrote: if type(self) is not dict: # This only applies to subclasses, not dict itself. try: transform = type(self).__transform__ except AttributeError: pass

Re: [Python-Dev] PEP 455: TransformDict

On 10/07/2013 02:55 PM, Ethan Furman wrote: A key difference (pun unavoidable ;) between __missing__ and __transform__ is that __missing__ is only called when a key is not found, while __transform__ needs to be called /every/ time a key is looked up: d[k] d.get(k) d.has_key(k

[Python-Dev] inspect() and dir()

Greetings, Currently, inspect() is dependent on dir(). Now that we can override what dir() returns on a class by class basis, we are seeing the side-effect of (possibly) incomplete inspect results, with also leads to (possibly) incomplete help(). I would think we want inspect to be more thoro

Re: [Python-Dev] PEP 457: Syntax For Positional-Only Parameters

On 10/08/2013 04:33 PM, Larry Hastings wrote: I've contributed a new PEP to humanity. I include the RST for your reading pleasure below, but you can also read it online here: http://www.python.org/dev/peps/pep-0457/ I like it! :) Feedback below... == N

Re: [Python-Dev] PEP 457: Syntax For Positional-Only Parameters

On 10/08/2013 05:15 PM, Steven D'Aprano wrote: On Wed, Oct 09, 2013 at 01:33:26AM +0200, Larry Hastings wrote: The obvious solution: add a new singleton constant to Python that is passed in when a parameter is not mapped to an argument. I propose that the value be called called ``undefined``, a

Re: [Python-Dev] PEP 457: Syntax For Positional-Only Parameters

On 10/08/2013 08:09 PM, Benjamin Peterson wrote: 2013/10/8 Terry Reedy : On 10/8/2013 9:31 PM, Benjamin Peterson wrote: 2013/10/8 Larry Hastings : This PEP proposes a backwards-compatible syntax that should permit implementing any builtin in pure Python code. This is rather too strong. Yo

Re: [Python-Dev] inspect() and dir()

On 10/08/2013 03:07 PM, Guido van Rossum wrote: I'd say that the effect overriding dir() has on help() is intentional. Not sure about inspect -- it has other uses. However, the last time I used it I was definitely hunting for stuff to document. If want help to be effected that is easy enough

Re: [Python-Dev] PEP 457: Syntax For Positional-Only Parameters

On 10/08/2013 09:55 PM, Benjamin Peterson wrote: 2013/10/8 Ethan Furman : On 10/08/2013 08:09 PM, Benjamin Peterson wrote: 2013/10/8 Terry Reedy : On 10/8/2013 9:31 PM, Benjamin Peterson wrote: 2013/10/8 Larry Hastings : This PEP proposes a backwards-compatible syntax that should

Re: [Python-Dev] PEP 457: Syntax For Positional-Only Parameters

On 10/09/2013 08:09 AM, Larry Hastings wrote: On 10/09/2013 04:45 PM, Anders J. Munch wrote: How about a naming convention instead, where using a leading underscore in a parameter name is a hint that it is positional-only. For example, the docstring of sorted: sorted(iterable, key=None, r

Re: [Python-Dev] inspect() and dir()

On 10/09/2013 09:40 AM, Brett Cannon wrote: On Tue, Oct 8, 2013 at 5:29 PM, Ethan Furman wrote: Currently, inspect() is dependent on dir(). What's inspect()? I don't know of any global with that name and you are obviously not talking about the module. My apologies. I am actual

Re: [Python-Dev] PEP 457: Syntax For Positional-Only Parameters

On 10/09/2013 09:05 AM, Paul Moore wrote: I remain -1 on forcing "Python syntax" to support all of these odd corner cases (and positional-only is already a corner case, range/addch are seriously so). Considering the prevalence of positional-only functions and methods, I don't think they can be

Re: [Python-Dev] inspect() and dir()

On 10/09/2013 02:46 PM, Nick Coghlan wrote: On 10 Oct 2013 03:39, "Ethan Furman" wrote: My apologies. I am actually talking about the module. I meant inspect.get_members() and inspect.classify_class_attrs(), which, as near as I can tell, are the only two functions in inspect tha

Re: [Python-Dev] inspect() and dir()

On 10/09/2013 03:36 PM, Nick Coghlan wrote: On 10 Oct 2013 08:07, "Ethan Furman" wrote: On 10/09/2013 02:46 PM, Nick Coghlan wrote: On 10 Oct 2013 03:39, "Ethan Furman" wrote: My apologies. I am actually talking about the module. I meant inspe

Re: [Python-Dev] cpython: Rename contextlib.ignored() to contextlib.ignore().

On 10/11/2013 05:51 AM, Mark Lawrence wrote: On 11/10/2013 11:33, Eric V. Smith wrote: And Antoine has again taught me a new word: polysemic: having more than one meaning; having multiple meanings IMHO a poor word to use. I'm a middle aged Brit who's never heard of it so people who have Eng

Re: [Python-Dev] cpython: Rename contextlib.ignored() to contextlib.ignore().

-1 to contextlib.ignore(s|d|ing|etc) ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] cpython: Rename contextlib.ignored() to contextlib.ignore().

On 10/11/2013 09:43 AM, Barry Warsaw wrote: On Oct 11, 2013, at 06:27 PM, Georg Brandl wrote: Maybe to fit in with other verb-like APIs used as context managers: it's open() not opened(). open() predates context managers, but maybe we need a new convention. with ignore(FileNotFoundError): v

Re: [Python-Dev] PEPs shouldn't be considered docs

On 10/11/2013 04:24 AM, Ned Batchelder wrote: I'd like to suggest that we not consider PEPs to be documentation. +1 The few times I've tried to use the PEPs to understand current Python it was confusing, wrong, and a waste of time. -- ~Ethan~ ___

Re: [Python-Dev] cpython: Rename contextlib.ignored() to contextlib.ignore().

On 10/11/2013 12:00 PM, MRAB wrote: On 11/10/2013 18:39, Ethan Furman wrote: On 10/11/2013 09:43 AM, Barry Warsaw wrote: On Oct 11, 2013, at 06:27 PM, Georg Brandl wrote: Maybe to fit in with other verb-like APIs used as context managers: it's open() not opened(). open() predates co

Re: [Python-Dev] Support keyword in PEP URL?

On 10/11/2013 04:35 PM, Ben Finney wrote: Victor Stinner writes: For draft PEP, the identifier may change. For an idea implemented in several PEPs, the obvious identifier may be taken first, but the preferred PEP for that identifier may later change. For example, PEP 354 would have the obvi

Re: [Python-Dev] Support keyword in PEP URL?

On 10/11/2013 06:13 PM, Victor Stinner wrote: Let me try to name PEPs related to Unicode: 100: unicode_integration 261: unicode_ucs4 277: windows_unicode_filenames (hum, I proposed a limit of 20 characters, this name is 25 characters long) 383: surrogateescape 393: compact_unicode 414: u_prefix

Re: [Python-Dev] cpython: Rename contextlib.ignored() to contextlib.ignore().

On 10/11/2013 07:47 PM, Stephen J. Turnbull wrote: Nick Coghlan writes: > (RDM is also right that the exception still has the effect of > terminating the block early, but I view names as mnemonics rather > than necessarily 100% accurate descriptions of things). This is just way too ambigu

Re: [Python-Dev] cpython: Rename contextlib.ignored() to contextlib.ignore().

On 10/11/2013 09:05 PM, Ethan Furman wrote: On 10/11/2013 07:47 PM, Stephen J. Turnbull wrote: Nick Coghlan writes: > (RDM is also right that the exception still has the effect of > terminating the block early, but I view names as mnemonics rather > than necessarily 100%

[Python-Dev] __objclass__ documentation

It was pointed in Issue16938[1] that __objclass__ is not documented anywhere. Is the following an appropriate description? (in Doc/reference/datamodel.rst in user-defined functions) +-+---+---+ | :attr:`__objclass__`|

Re: [Python-Dev] cpython: Rename contextlib.ignored() to contextlib.ignore().

On 10/12/2013 03:27 PM, Raymond Hettinger wrote: When you ask someone to describe what "try: f() except SomeException: pass" does, they will say that it ignores the exception. And they would be right in that case. FWIW, I presented this to 2500+ people in the keynote at the 2013 U.S. Pycon

Re: [Python-Dev] inspect() and dir()

On 10/10/2013 02:25 AM, Nick Coghlan wrote: On 10 Oct 2013 14:32, "Ethan Furman" wrote: That makes sense. So what should the new functions be called? get_all_members and classify_all_class_attrs ? Yeah, those work for me. The only way they should miss anything is if attribute

Re: [Python-Dev] cpython: Rename contextlib.ignored() to contextlib.ignore().

On 10/12/2013 06:50 PM, Raymond Hettinger wrote: On Oct 12, 2013, at 4:30 PM, Ethan Furman wrote: Were you only displaying the same short form above? Yes. The specific example given was: with ignore(OSError): os.remove(somefile) That is certainly nicer than the multi-line

Re: [Python-Dev] __objclass__ documentation

On 10/12/2013 11:18 PM, Cameron Simpson wrote: On 12Oct2013 15:03, Ethan Furman wrote: It was pointed in Issue16938[1] that __objclass__ is not documented anywhere. Is the following an appropriate description? (in Doc/reference/datamodel.rst in user-defined functions

Re: [Python-Dev] __objclass__ documentation

On 10/13/2013 04:44 AM, Nick Coghlan wrote: On 13 Oct 2013 08:27, "Ethan Furman" wrote: It was pointed in Issue16938[1] that __objclass__ is not documented anywhere. Is the following an appropriate description? (in Doc/reference/datamodel.rst in user-defined

Re: [Python-Dev] cpython: Rename contextlib.ignored() to contextlib.ignore().

On 10/13/2013 05:34 AM, Antoine Pitrou wrote: On Sun, 13 Oct 2013 16:57:09 +1000 Nick Coghlan wrote: For the record, this thread did prompt me to consider the new construct anew, but on reflection, I still consider it a reasonable addition to contextlib. It substantially improves the simple c

Re: [Python-Dev] cpython: Rename contextlib.ignored() to contextlib.ignore().

On 10/15/2013 09:28 AM, PJ Eby wrote: On Tue, Oct 15, 2013 at 11:52 AM, R. David Murray wrote: What about making the context manager provide the trapped exception, in a fashion similar to what assertRaises does? Sadly, that won't work, since context managers provide a value *before* the block

Re: [Python-Dev] cpython: Rename contextlib.ignored() to contextlib.ignore().

On 10/15/2013 12:59 PM, Tim Delaney wrote: On 16 October 2013 05:17, Alexander Belopolsky mailto:alexander.belopol...@gmail.com>> wrote: On Tue, Oct 15, 2013 at 12:45 PM, Ethan Furman mailto:et...@stoneleaf.us>> wrote: > with trap(OSError) as cm: > os.u

Re: [Python-Dev] cpython: Rename contextlib.ignored() to contextlib.ignore().

On 10/16/2013 12:07 AM, Raymond Hettinger wrote: On Oct 15, 2013, at 4:24 PM, Nick Coghlan wrote: this thread still epitomises everything that sucks about soul destroying, energy draining bikeshed painting that makes me wonder why I ever bother trying to make anything better. I think each of

Re: [Python-Dev] cpython: Rename contextlib.ignored() to contextlib.ignore().

On 10/16/2013 07:06 AM, Ethan Furman wrote: Actually, it was to kick around one line of code, the most import one: def ignored(...): s/import/important/ ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo

[Python-Dev] Bug tracker and docs@python

Good day! What is the effect of assigning a bug tracker issue to docs@python? -- ~Ethan~ ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-

Re: [Python-Dev] cpython: Rename contextlib.ignored() to contextlib.ignore().

On 10/17/2013 08:26 AM, Nick Coghlan wrote: # Arbitrarily nested search loop with exit_label() as found: for i in range(x): for j in range(y): if matches(i, j): found.exit((i, j)) if found: print(found.value) +

Re: [Python-Dev] Bug tracker and docs@python

On 10/17/2013 08:29 AM, Benjamin Peterson wrote: 2013/10/17 Ethan Furman : Good day! What is the effect of assigning a bug tracker issue to docs@python? The assignee field is set to d...@python.org. In other words, nothing magical happens. Heh, okay. So commit the doc patch myself, then

Re: [Python-Dev] On suppress()'s trail blazing (was Re: cpython: Rename contextlib.ignored() to contextlib.ignore())

On 10/17/2013 01:03 PM, Terry Reedy wrote: class suppress: def __init__(self, *exceptions): self.exceptions = exceptions def __exit__(self, etype, eval, etrace): return etype in self.exceptions This fails when etype is a subclass of the exceptions, as mentioned in the original

Re: [Python-Dev] On suppress()'s trail blazing (was Re: cpython: Rename contextlib.ignored() to contextlib.ignore())

On 10/17/2013 01:57 PM, Xavier Morel wrote: On 2013-10-17, at 22:11 , Ethan Furman wrote: On 10/17/2013 01:03 PM, Terry Reedy wrote: class suppress: def __init__(self, *exceptions): self.exceptions = exceptions def __exit__(self, etype, eval, etrace): return etype in

Re: [Python-Dev] PEP: Ordered Class Definition Namespace

On 06/07/2016 11:13 AM, Eric Snow wrote: On Tue, Jun 7, 2016 at 11:01 AM, Ethan Furman wrote: On 06/07/2016 10:51 AM, Eric Snow wrote: Specification = * types for which `__prepare__()`` returned something other than ``OrderedDict`` (or a subclass) have their

[Python-Dev] PEP 467: Minor API improvements to bytes, bytearray, and memoryview

Minor changes: updated version numbers, add punctuation. The current text seems to take into account Guido's last comments. Thoughts before asking for acceptance? PEP: 467 Title: Minor API improvements for binary sequences Version: $Revision$ Last-Modified: $Date$ Author: Nick Coghlan Statu

Re: [Python-Dev] PEP: Ordered Class Definition Namespace

On 06/07/2016 02:20 PM, Eric Snow wrote: On Tue, Jun 7, 2016 at 12:30 PM, Nick Coghlan wrote: On 7 June 2016 at 10:51, Eric Snow wrote: * ``__definition_order__`` is a tuple * ``__definition_order__`` is a read-only attribute Thinking about the class decorator use case, I think this may nee

Re: [Python-Dev] PEP: Ordered Class Definition Namespace

On 06/07/2016 03:27 PM, Eric Snow wrote: Not all attrs are writable and it's a case-by-case situation: some of the ones that are writable started out read-only and changed once there was a valid reason. If anything, it's arguably safer in general to take an immutable-by-default approach. I'm

Re: [Python-Dev] PEP 467: Minor API improvements to bytes, bytearray, and memoryview

On 06/07/2016 02:33 PM, Paul Sokolovsky wrote: This PEP proposes to deprecate that behaviour in Python 3.6, and remove it entirely in Python 3.7. Why the desire to break applications of thousands and thousands of people? Besides, bytes(3) behavior is very logical. Everyone who knows what mallo

Re: [Python-Dev] PEP 520: Ordered Class Definition Namespace

On 06/07/2016 05:50 PM, Eric Snow wrote: Overall +1. Some nits below. Specification = 3. types for which `__prepare__()`` returned something other than ``OrderedDict`` (or a subclass) have their ``__definition_order__`` set to ``None`` (unless ``__defini

Re: [Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits?

On 06/09/2016 04:25 AM, Larry Hastings wrote: A problem has surfaced just this week in 3.5.1. Obviously this is a good time to fix it for 3.5.2. But there's a big argument over what is "broken" and what is an appropriate "fix". Having read the thread thus far, here is my take on fixing it:

Re: [Python-Dev] PEP 520: Ordered Class Definition Namespace

On 06/09/2016 02:39 PM, Nick Coghlan wrote: On 7 June 2016 at 20:17, Eric Snow wrote: On Tue, Jun 7, 2016 at 6:20 PM, Ethan Furman wrote: If __definition_order__ is supposed to be immutable as well as read-only then we should convert non-tuples to tuples. No point in letting that user bug

Re: [Python-Dev] Smoothing the transition from Python 2 to 3

On 06/08/2016 02:40 PM, Fred Drake wrote: On Wed, Jun 8, 2016 at 5:33 PM, Ryan Gonzalez wrote: What about something like "unpythonic" or similar? Or perhaps... antipythy? That's awfully close to antipathy [1], my path module on PyPI. Besides, I liked the suggestion from the -ideas list: Py

Re: [Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits?

On 06/09/2016 03:22 PM, Larry Hastings wrote: On 06/09/2016 08:52 AM, Guido van Rossum wrote: That leaves direct calls to os.urandom(). I don't think this should block either. Then it's you and me against the rest of the world ;-) Okay, it's decided: os.urandom() must be changed for 3.5.2 t

Re: [Python-Dev] PEP: Ordered Class Definition Namespace

On 06/07/2016 11:13 AM, Eric Snow wrote: On Tue, Jun 7, 2016 at 11:01 AM, Ethan Furman wrote: On 06/07/2016 10:51 AM, Eric Snow wrote: Specification = * types for which `__prepare__()`` returned something other than ``OrderedDict`` (or a subclass) have their

Re: [Python-Dev] PEP 468

On 06/10/2016 02:13 PM, Franklin? Lee wrote: P.S.: If anyone is missing the relevance, Raymond Hettinger's compact dicts are inherently ordered until a delitem happens.[1] That could be "good enough" for many purposes, including kwargs and class definition. It would be great for kwargs, but no

Re: [Python-Dev] PEP 468

On 06/13/2016 05:47 PM, Larry Hastings wrote: On 06/13/2016 05:05 PM, MRAB wrote: This could be avoided by expanding the items to include the index of the 'previous' and 'next' item, so that they could be handled like a doubly-linked list. The disadvantage would be that it would use more memo

[Python-Dev] proposed os.fspath() change

I would like to make a change to os.fspath(). Specifically, os.fspath() currently raises an exception if something besides str, bytes, or os.PathLike is passed in, but makes no checks if an os.PathLike object returns something besides a str or bytes. I would like to change that to the opposite:

Re: [Python-Dev] proposed os.fspath() change

On 06/15/2016 10:59 AM, Brett Cannon wrote: On Wed, 15 Jun 2016 at 09:48 Guido van Rossum wrote: These are really two separate proposals. I'm okay with checking the return value of calling obj.__fspath__; that's an error in the object anyways, and it doesn't matter much whether we do this or

Re: [Python-Dev] proposed os.fspath() change

On 06/15/2016 11:44 AM, Brett Cannon wrote: On Wed, 15 Jun 2016 at 11:39 Guido van Rossum wrote: OK, so let's add a check on the return of __fspath__() and keep the check on path-like or string/bytes. I'll update the PEP. Ethan, do you want to leave a note on the os.fspath() issue to update

Re: [Python-Dev] proposed os.fspath() change

On 06/15/2016 12:10 PM, Koos Zevenhoven wrote: if isinstance(filename, os.PathLike): By the way, regarding the line of code above, is there a convention regarding whether implementing some protocol/interface requires registering with (or inheriting from) the appropriate ABC for it to work

Re: [Python-Dev] proposed os.fspath() change

On 06/15/2016 12:24 PM, Koos Zevenhoven wrote: On Wed, Jun 15, 2016 at 10:15 PM, Brett Cannon wrote: ABCs like os.PathLike can override __subclasshook__ so that registration isn't required (see https://hg.python.org/cpython/file/default/Lib/os.py#l1136). So registration is definitely good to d

Re: [Python-Dev] BDFL ruling request: should we block forever waiting for high-quality random bits?

On 06/15/2016 01:01 PM, Nick Coghlan wrote: For 3.6+, we can instead make it so that the only things that actually rely on cryptographic quality randomness being available are: - calling a secrets module API - calling a random.SystemRandom method - calling os.urandom directly However, we do

Re: [Python-Dev] security SIG?

On 06/18/2016 07:30 AM, Cory Benfield wrote: On 18 Jun 2016, at 04:06, Brett Cannon wrote: Do we need a security SIG? E.g. would people like Christian and Cory like >> to have a separate place to talk about the ssl stuff brought up at the >> language summit? Honestly, I’m not sure what we w

Re: [Python-Dev] security SIG?

On 06/19/2016 12:39 PM, Nick Coghlan wrote: On 18 June 2016 at 10:36, Ethan Furman wrote: To sum up: I think it would be a good idea. I'm coming around to this point of view as well. import-sig, for example, is a very low traffic SIG, but I think it serves three key useful purposes:

Re: [Python-Dev] security SIG?

On 06/19/2016 03:51 PM, Guido van Rossum wrote: I think it's fine to have this SIG. I could see it going different ways in terms of discussions and membership, but it's definitely worth a try. I don't like clever names, and I very much doubt that it'll be mistaken for an address to report sensit

[Python-Dev] New security-sig mailling list

has been created: https://mail.python.org/mailman/listinfo/security-sig The purpose of this list is to discuss security-related enhancements to Python while having as little impact on backwards compatibility as possible. Once a proposal is ready it will be presented to Python Dev. (This te

Re: [Python-Dev] New security-sig mailling list

On 06/20/2016 03:02 PM, Chris Jerdonek wrote: I would recommend clarifying the relationship of the SIG to the Python Security Response Team ( https://www.python.org/news/security ), or at least clarifying that the SIG is different from the PSRT (and that security reports should not be sent to th

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

On 06/21/2016 01:48 PM, Serhiy Storchaka wrote: There is a design question. If you read file in some format or with some protocol, and the data is ended unexpectedly, when to use general EOFError exception and when to use format/protocol specific exception? I believe that EOFError was created

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

On 06/27/2016 02:54 PM, Greg Ewing wrote: Nikolaus Rath wrote: I think EOFError conveys more information. UnpicklingError can mean a lot of things, EOFError tells you the precise problem: pickle expected more data, but there was nothing left. I think EOFError should be used for EOF between pic

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

On 06/27/2016 03:20 PM, Guido van Rossum wrote: The point is that it's not an error. In Andre Malo's use case, at least, EOFError is used as a control flow exception, not as an error. Like StopIteration then: only an error if it escapes. -- ~Ethan~ ___

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

On 06/28/2016 01:55 PM, Guido van Rossum wrote: Awesome. That addresses my last concerns. PEP 520 is now accepted. Congratulations! And more Congratulations!! -- ~Ethan~ ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mail

[Python-Dev] AutoNumber Enum

There is a several-month-old request to add aenum's [1] AutoNumberEnum to the stdlib [2]. The requester and two of the three developers of Enum are in favor (the third hasn't chimed in yet). This new addition would enable the following: from Enum import AutoNumberEnum class Color(AutoNu

Re: [Python-Dev] AutoNumber Enum

On 06/29/2016 11:15 AM, Brett Cannon wrote: On Wed, 29 Jun 2016 at 10:41 Ethan Furman wrote: There is a several-month-old request to add aenum's [1] AutoNumberEnum to the stdlib [2]. The requester and two of the three developers of Enum are in favor (the third hasn't chimed in y

Re: [Python-Dev] AutoNumber Enum

On 06/29/2016 12:11 PM, Guido van Rossum wrote: And how would you implement that without support from the compiler? Does it use a hook that catches the NameError? It's built into the _EnumDict class dictionary used during class creation. Current (edited) code from the aenum package that imple

Re: [Python-Dev] AutoNumber Enum

On 06/29/2016 01:01 PM, Ivan Levkivskyi wrote: It looks like the values in AutoNumberEnum are consecutive integers 1,2,3,... Have you considered an option (keyword argument) to change this to powers of two 1,2,4,8,...? There is another issue relating to bitwise enums that deals with that. It

Re: [Python-Dev] AutoNumber Enum

On 06/29/2016 03:40 PM, Roberto Martínez wrote: Why the 'start' parameter default is 1? 0 (zero) is more consistent with other parts of the language: indexes, enumerate, range... An excerpt from [1]: The reason for defaulting to 1 as the starting number and not 0 is that 0 is False in a boo

Re: [Python-Dev] release cadence

On 07/05/2016 10:44 AM, Barry Warsaw wrote: On Jul 04, 2016, at 10:31 AM, Nick Coghlan wrote: While we liked the "consistent calendar cadence that is some multiple of 6 months" idea, several of us thought 12 months was way too short as it makes for too many entries in third party support matri

Re: [Python-Dev] Proposal: explicitly disallow function/class mismatches in accelerator modules

On 07/09/2016 06:50 AM, Nick Coghlan wrote: Given that the issues that arose in this case weren't at all obvious up front, what do folks think of the idea of updating PEP 399 to explicitly prohibit class/function mismatches between accelerator modules and their pure Python counterparts? So thi

Re: [Python-Dev] Proposal: explicitly disallow function/class mismatches in accelerator modules

On 07/10/2016 08:32 PM, Chris Angelico wrote: On Mon, Jul 11, 2016 at 1:26 PM, Steven D'Aprano wrote: (1) How much extra effort are we going to *mandate* that core devs put in to hide the differences between C and Python code, for the benefit of a small minority that will notice them? The su

Re: [Python-Dev] PEP 467: Minor API improvements to bytes, bytearray, and memoryview

On 06/07/2016 10:42 PM, Serhiy Storchaka wrote: On 07.06.16 23:28, Ethan Furman wrote: * Add ``bytes.iterbytes``, ``bytearray.iterbytes`` and ``memoryview.iterbytes`` alternative iterators "Byte" is an alias to "octet" (8-bit integer) in modern terminology. Mayb

Re: [Python-Dev] PEP487: Simpler customization of class creation

On 07/17/2016 09:57 AM, Guido van Rossum wrote: This PEP is now accepted for inclusion in Python 3.6. Martin, congratulations! Congratulations, Martin! I'm looking forward to this feature. :) -- ~Ethan~ ___ Python-Dev mailing list Python-Dev@pytho

Re: [Python-Dev] PEP 467: Minor API improvements to bytes, bytearray, and memoryview

On 06/07/2016 02:34 PM, Koos Zevenhoven wrote: Why not bytes.viewbytes (or whatever name) so that one could also subscript it? And if it were a property, one could perhaps conveniently get the n'th byte: b'abcde'.viewbytes[n] # compared to b'abcde'[n:n+1] AFAICT, 'viewbytes' doesn't add muc

[Python-Dev] PEP 467: next round

oftened to deprecation/discouragement --- PEP: 467 Title: Minor API improvements for binary sequences Version: $Revision$ Last-Modified: $Date$ Author: Nick Coghlan , Ethan Furman Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 2014-03-30 Python-Version: 3.6 Post-His

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

On 07/18/2016 02:01 PM, Jonathan Goble wrote: This PEP isn't revisiting that original design decision, just changing the spelling as users sometimes find the current behaviour of the binary sequence constructors surprising. In particular, there's a reasonable case to be made that ``bytes(x)`` (w

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

On 07/18/2016 02:45 PM, Brett Cannon wrote: On Mon, 18 Jul 2016 at 14:35 Alexander Belopolsky wrote: On Mon, Jul 18, 2016 at 5:01 PM, Jonathan Goble wrote: full(), despite its use in numpy, is also unintuitive to me (my first thought is that it would indicate whether an object has room for mo

Re: [Python-Dev] PEP 514: Python registration in the Windows registry

On 07/24/2016 12:45 AM, Paul Moore wrote: This PEP is now accepted. Congratulations, Steve! And more congratulations! :) -- ~Ethan~ ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe:

Re: [Python-Dev] PEP487: Simpler customization of class creation

On 07/24/2016 08:20 AM, Guido van Rossum wrote: I am very much against this. The two are not at all like each other. Also, what's the use case? To be clear: you are against the automatic calling of __set_name__ and/or __set_owner__ when using setattr outside of class creation? Said another

Re: [Python-Dev] PEP487: Simpler customization of class creation

On 07/29/2016 08:01 AM, Martin Teichmann wrote: ... Also, while researching other people's code when I wrote PEP 487, I couldn't find any such code elsewhere, yet I found a lot of code where people took the wildest measure to prevent a metaclass in doing its job on the first class it is used for

Re: [Python-Dev] What do we do about bad slicing and possible crashes (issue 27867)

On 08/28/2016 09:26 AM, Nick Coghlan wrote: On 28 August 2016 at 08:25, Terry Reedy wrote: Slicing can be made to malfunction and even crash with an 'evil' __index__ method. https://bugs.python.org/issue27867 The crux of the problem is this: PySlice_GetIndicesEx receives a slice object and a s

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

Coghlan , Ethan Furman Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 2014-03-30 Python-Version: 3.6 Post-History: 2014-03-30 2014-08-15 2014-08-16 2016-06-07 2016-09-01 Abstract During the initial development of the Python 3 language specification, the core

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

On 09/01/2016 02:06 PM, Victor Stinner wrote: 2016-09-01 21:36 GMT+02:00 Ethan Furman: Abstract This PEP proposes five small adjustments to the APIs of the ``bytes`` and ``bytearray`` types to make it easier to operate entirely in the binary domain: You should add bchr() in the

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

On 09/01/2016 04:07 PM, Victor Stinner wrote: 2016-09-02 0:04 GMT+02:00 Ethan Furman: - `fromord` to replace the mistaken purpose of the default constructor To replace a bogus bytes(obj)? If someone writes bytes(obj) but expect to create a byte string from an integer, why not using bchr

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

On 09/03/2016 05:08 AM, Martin Panter wrote: On 1 September 2016 at 19:36, Ethan Furman wrote: Deprecation of current "zero-initialised sequence" behaviour without removal Currently, the ``bytes`` and `

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

On 09/02/2016 06:17 PM, Greg Ewing wrote: Ethan Furman wrote: The problem with only having `bchr` is that it doesn't help with `bytearray`; the problem with not having `bchr` is who wants to write `bytes.fromord`? If we called it 'bytes.fnord' (From Numeric Ordinal) peopl

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

On 09/03/2016 09:48 AM, Nick Coghlan wrote: On 3 September 2016 at 21:35, Martin Panter wrote: On 3 September 2016 at 08:47, Victor Stinner wrote: Le samedi 3 septembre 2016, Random832 a écrit : On Fri, Sep 2, 2016, at 19:44, Ethan Furman wrote: The problem with only having `bchr` is that

Re: [Python-Dev] Please reject or postpone PEP 526

On 09/05/2016 06:46 AM, Nick Coghlan wrote: [an easy to understand explanation for those of us who aren't type-inferring gurus] Thanks, Nick. I think I finally have a grip on what Mark was talking about, and about how these things should work. Much appreciated! -- ~Ethan~ __

[Python-Dev] PEP520 and absence of __definition_order__

Per Victor's advice I'm posting this here. PEP 520 has been accepted, but without the __definition_order__ attribute. The accompanying comment: "Note: Since compact dict has landed in 3.6, __definition_order__ has been removed. cls.__dict__ now mostly accomplishes the same thing instead." The

<    7   8   9   10   11   12   13   14   15   16   >