Re: [Python-Dev] More optimisation ideas

On Sun, Jan 31, 2016 at 08:23:00PM +, Brett Cannon wrote: > So freezing the stdlib helps on UNIX and not on OS X (if my old testing is > still accurate). I guess the next question is what it does on Windows and > if we would want to ever consider freezing the stdlib as part of the build >

Re: [Python-Dev] Speeding up CPython 5-10%

On Wed, Jan 27, 2016 at 01:25:27PM -0500, Yury Selivanov wrote: > Hi, > > > tl;dr The summary is that I have a patch that improves CPython > performance up to 5-10% on macro benchmarks. Benchmarks results on > Macbook Pro/Mac OS X, desktop CPU/Linux, server CPU/Linux are available > at [1].

Re: [Python-Dev] Hash randomization for which types?

On Tue, Feb 16, 2016 at 11:56:55AM -0800, Glenn Linderman wrote: > On 2/16/2016 1:48 AM, Christoph Groth wrote: > >Hello, > > > >Recent Python versions randomize the hashes of str, bytes and datetime > >objects. I suppose that the choice of these three types is the result > >of a compromise.

Re: [Python-Dev] why we have both re.match and re.string?

On Wed, Feb 10, 2016 at 10:59:18PM +0100, Luca Sangiacomo wrote: > Hi, > I hope the question is not too silly, but why I would like to understand > the advantages of having both re.match() and re.search(). Wouldn't be > more clear to have just one function with one additional parameters like >

Re: [Python-Dev] PEP 515: Underscores in Numeric Literals

On Wed, Feb 10, 2016 at 11:20:38PM +0100, Georg Brandl wrote: > This came up in python-ideas, and has met mostly positive comments, > although the exact syntax rules are up for discussion. Nicely done. But I would change the restrictions to a simpler version. Instead of five rules to learn: >

Re: [Python-Dev] PEP 515: Underscores in Numeric Literals

On Wed, Feb 10, 2016 at 10:53:09PM +, Paul Moore wrote: > On 10 February 2016 at 22:20, Georg Brandl wrote: > > This came up in python-ideas, and has met mostly positive comments, > > although the exact syntax rules are up for discussion. > > +1 on the PEP. Is there any

Re: [Python-Dev] When should pathlib stop being provisional?

On Tue, Apr 05, 2016 at 11:53:05PM -0700, Nathaniel Smith wrote: > This makes me twitch slightly, because NumPy has had a whole set of > problems due to the ancient and minimally-considered decision to > assume a bunch of ad hoc non-namespaced method names fulfilled some > protocol -- like all

Re: [Python-Dev] Challenge: Please break this! (a.k.a restricted mode revisited)

I haven't been following this thread in detail, so perhaps I have missed something, but I have a question... On Tue, Apr 12, 2016 at 02:05:06PM +0200, Victor Stinner wrote: > You don't understand that even if the visible "Python scope", "Python > namespace", or call it as you want (the code

Re: [Python-Dev] PEP 506 secrets module

I've just spotted this email from Guido, sorry about the delay in responding. Further comments below. On Thu, Jan 14, 2016 at 10:47:09AM -0800, Guido van Rossum wrote: > I think the discussion petered out and nobody asked me to approve it yet > (or I lost track of it). I'm almost happy to

Re: [Python-Dev] Challenge: Please break this! (a.k.a restricted mode revisited)

On Sun, Apr 10, 2016 at 08:12:30PM -0400, Jonathan Goble wrote: > On Sun, Apr 10, 2016 at 7:02 PM, Oscar Benjamin > wrote: > > I haven't looked at your sandbox but for a different approach try this one: > > > > L = [None] > > L.extend(iter(L)) > > > > On my Linux

Re: [Python-Dev] When should pathlib stop being provisional?

On Wed, Apr 06, 2016 at 11:30:32AM +0200, Petr Viktorin wrote: > Python was in a similar situation with the .next method on iterators, > which changed to __next__ in Python 3. PEP 3114 (which explains this > change) says: > > > Code that nowhere contains an explicit call to a next method can > >

Re: [Python-Dev] When should pathlib stop being provisional?

I haven't really been following this discussion, but a couple of comments... On Tue, Apr 05, 2016 at 11:47:32PM +, Brett Cannon wrote: > http://www.snarky.ca/why-pathlib-path-doesn-t-inherit-from-str Nice write-up, thanks. [...] > To me it seems to basically be a question of whether

Re: [Python-Dev] When should pathlib stop being provisional?

On Wed, Apr 06, 2016 at 10:02:30AM +1000, Chris Angelico wrote: > My personal view on the text/bytes debate is that a path is > fundamentally a human concept, and consists therefore of text. The > fact that some file systems store (at the low level) bytes and some > store (I think) UTF-16 code

Re: [Python-Dev] PEP 506 secrets module

On Sun, Apr 10, 2016 at 11:43:08AM -0700, Guido van Rossum wrote: > Hi Steven, > > No probIem with the delay -- it's still before 3.6.0. I do think it's > just about a record gap in the PEP review process. :-) > > I will approve the PEP as soon as you've updated the two function > names in the

Re: [Python-Dev] Terminal console

On Tue, Apr 26, 2016 at 08:45:20AM -0400, Franklin? Lee wrote: > On Apr 26, 2016 4:02 AM, "Paul Moore" wrote: > > > > On 25 April 2016 at 23:55, Franklin? Lee > wrote: > > > FWIW, Gmail's policies require: > > [...] > > > That link is currently

Re: [Python-Dev] File system path PEP, part 2

On Thu, May 12, 2016 at 08:53:12PM +, Brett Cannon wrote: > Second draft that takes Guido's comments into consideration. The biggest > change is os.fspath() now returns whatever path.__fspath__() returns > instead of restricting it to only str. Counter suggestion: - __fspath__() method may

Re: [Python-Dev] file system path protocol PEP

On Thu, May 12, 2016 at 07:22:25PM +0200, Sjoerd Job Postmus wrote: > The whole point of adding `os.fspath` is to make it easier to use Path > objects. This is in an effort to gain greater adoption of pathlib in > libraries. Now, this is an excellent idea. > > However, if it were to reject

Re: [Python-Dev] File system path PEP, part 2

On Fri, May 13, 2016 at 03:43:29PM +, Brett Cannon wrote: > On Fri, 13 May 2016 at 04:00 Steven D'Aprano <st...@pearwood.info> wrote: [...] > > - but os.fspath() will only return str; > > - and os.fspathb() will only return bytes; > I prefer what's in the PEP. I g

Re: [Python-Dev] Need help in OCR implementation with Python3.5.1 or pyCharm Community edition

On Thu, May 05, 2016 at 05:23:02PM +0100, MRAB wrote: > On 2016-05-05 16:26, Ryan Gonzalez wrote: > >On Thu, May 5, 2016 at 3:24 AM, Deepak Srivastava [ ... about three or four pages of quoting ... ] > >Questions like this are better suited for python-list. [...] > It looks to me that it's the

Re: [Python-Dev] Memory

On Sun, May 01, 2016 at 08:08:22AM -0500, Ryan Gonzalez wrote: > Well, I put this in Google Translate...and got this: > > The disk clatters > the Spontie giggles > ~ > hopefully > alliance insures ... > > Not sure if this a useless post or Translate just being weird. Leaning > towards the

Re: [Python-Dev] Tracker Etiquette

On Sat, May 07, 2016 at 04:06:51PM -0700, Ethan Furman wrote: > I just reviewed an issue on the tracker, and found that many, if not > all, of my comments made at the time I completely disagree with (both > now, and before -- I'm going to claim sleep deprivation). > > Obviously I should post a

[Python-Dev] Should secrets include a fallback for hmac.compare_digest?

Now that PEP 506 has been approved, I've checked in the secrets module, but an implementation question has come up regarding compare_digest. Currently, the module tries to import hmac.compare_digest, and if that fails, then it falls back to a Python version. But since compare_digest has been

Re: [Python-Dev] Should secrets include a fallback for hmac.compare_digest?

On Fri, Apr 15, 2016 at 10:26:31AM +0200, Victor Stinner wrote: > It's easy to implement this function (in the native language of your Python > implemenation), it's short. I'm not sure that a Python version is really > safe. > > The secrets module is for Python 3.6, in this version the hmac

Re: [Python-Dev] When the infamous Bier trunk hits ... where is our Python backup?

On Thu, Apr 21, 2016 at 04:00:29AM -0700, Burkhard Meier wrote: > Well, > > Just a thought. I'm afraid I have no idea what you are referring to. -- Steve ___ Python-Dev mailing list Python-Dev@python.org

[Python-Dev] Changing the licence of statistics.py

I'm the author of statistics.py, and for historical reasons it was originally included in the standard library under the Apache licence. I now wish to change that and have it licenced under Python's standard licence. Is there anything I need to do other than just remove the Apache licence

Re: [Python-Dev] Changing the licence of statistics.py

On Sun, Aug 14, 2016 at 04:27:21AM +, Brett Cannon wrote: > Are you the sole author of the statistics module prior to contributing it, > Steve? Yes. There has been at least one patch to the module as part of the standard library by someone else: http://bugs.python.org/issue26002 but

[Python-Dev] Would somebody like to review issue27573 please?

I have a tiny patch for issue 27573, "code.interact() should print an exit message". http://bugs.python.org/issue27573 Its a one-line change to code.py, plus a dozen or so lines changed in test_code.py. If its not controversial, I think it would be nice to get it into 3.6. Thanks, --

Re: [Python-Dev] Breaking up the stdlib (Was: release cadence)

On Tue, Jul 05, 2016 at 08:01:43PM +0200, Petr Viktorin wrote: > In the tkinter case, compiling for source is easy on a developer's > computer, but doing that on a headless server brings in devel files for > the entire graphical environment. > Are you saying Python on servers should have a way to

Re: [Python-Dev] digital panels processing text sowftware write with Python language

On Fri, Jul 08, 2016 at 01:16:00PM +, Hadi Montazami safavi via Python-Dev wrote: > Dear SirsWith thanks, iam looking digital panels processing text > sowftware write with Python languagefor my project.Could you please > guide me if there is or guiding to write it personally.Thanking you

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

On Sat, Jul 09, 2016 at 11:50:59PM +1000, Nick Coghlan wrote: > I'm in the process of trying to disentangle > http://bugs.python.org/issue27137 which points out some of the > behavioural differences that arise when falling back from the original > C implementation of functools.partial to the pure

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

On Sun, Jul 10, 2016 at 10:15:33AM +1000, Nick Coghlan wrote: > On 10 July 2016 at 05:10, Steven D'Aprano <st...@pearwood.info> wrote: > > The other side of the issue is that requiring exact correspondence is > > considerably more difficult and may be over-kill for some use

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

On Mon, Jul 11, 2016 at 01:32:32PM +1000, Chris Angelico wrote: > On Mon, Jul 11, 2016 at 1:26 PM, Steven D'Aprano <st...@pearwood.info> wrote: > > (1) How much extra effort are we going to *mandate* that core devs put > > in to hide the differences between C and Python

Re: [Python-Dev] Breaking up the stdlib (Was: release cadence)

On Tue, Jul 05, 2016 at 09:53:24AM +0200, Petr Viktorin wrote: > While we're on the subject, I'd like to offer another point for > consideration: not all implementations of Python can provide the full > stdlib, and not everyone wants the full stdlib. > > For MicroPython, most of Python's

Re: [Python-Dev] Python FTP Injections Allow for Firewall Bypass (oss-security advisory)

I haven't seen any response to the following alleged security vulnerability. I am not qualified to judge the merits of this, but it does seem worrying that (alledgedly) the Python security team hasn't responded for over 12 months. Is anyone able to comment? Thanks, Steve On Mon, Feb 20,

Re: [Python-Dev] Translated Python documentation

On Fri, Feb 24, 2017 at 06:01:59AM -0500, tritium-l...@sdamon.com wrote: > My gut splits the difference on this issue; I suggest an approach to > meet in the middle – a version of the docs written in simplified > English (Not quite Up Goer Five simplified, but simplified.) As an English

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

Hi Mark, I'm going to trim your post drastically, down to the bare essentials, in order to keep this already long post down to a manageable size. On Fri, Sep 02, 2016 at 02:47:00PM +0100, Mark Shannon wrote: [...] > With type comments, this is intuitively correct and should type check: > def

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

On Fri, Sep 02, 2016 at 10:47:41AM -0700, Steve Dower wrote: > "I'm not seeing what distinction you think you are making here. What > distinction do you see between: > > x: int = func(value) > > and > > x = func(value) #type: int" > > Not sure whether I agree with Mark on this

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

On Fri, Sep 02, 2016 at 08:10:24PM +0300, Koos Zevenhoven wrote: > A good checker should be able to infer that x is a union type at the > point that it's passed to spam, even without the type annotation. For > example: > > def eggs(cond:bool): > if cond: > x = 1 > else: >

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

On Mon, Sep 05, 2016 at 11:19:38AM +0300, Koos Zevenhoven wrote: > On Mon, Sep 5, 2016 at 5:21 AM, Nick Coghlan wrote: [...] > > On 5 September 2016 at 04:40, Koos Zevenhoven wrote: > >> On Sun, Sep 4, 2016 at 9:13 PM, Ivan Levkivskyi

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

On Mon, Sep 05, 2016 at 04:40:08PM +0300, Koos Zevenhoven wrote: > On Mon, Sep 5, 2016 at 3:10 PM, Steven D'Aprano <st...@pearwood.info> wrote: > > > > [Koos Zevenhoven] > >> >> How is it going to help that these are equivalent within one checker, > >>

Re: [Python-Dev] Do PEP 526 type declarations define the types of variables or not?

On Mon, Sep 05, 2016 at 04:26:17PM +0100, Mark Shannon wrote: > In this example: > > def bar()->Optional[int]: ... > > def foo()->int: > x:Optional[int] = bar() > if x is None: > return -1 > return x > > According to PEP 526 the annotation

Re: [Python-Dev] Requesting on python directories

Hello Ramu, This is the wrong place to ask for help with your question, this is for development of the Python interpreter. I suggest you subscribe to the Python-List mailing list. For help with publishing packages, see https://wiki.python.org/moin/CheeseShopTutorial On Tue, Sep 06, 2016

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

Referring to the alternative syntax forms: # Proposed x: int = func(value) # Already accepted x = func(value) #type: int On Sun, Sep 04, 2016 at 11:52:24AM +0100, Mark Shannon wrote: > The key difference is in placement. > PEP 484 style > variable = value # annotation > >

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

On Sun, Sep 04, 2016 at 12:31:26PM +0100, Mark Shannon wrote: > In other words PEP 484 specifically states that annotations are to help > with type inference. As defined in PEP 526, I think that type > annotations become a hindrance to type inference. I'm pretty sure that they don't. Have you

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

On Sun, Sep 04, 2016 at 12:30:18PM +0100, Mark Shannon wrote: > It would be a real shame if PEP 526 mandates against checkers doing as > good as job as possible. Forcing all uses of a variable to have the same > type is a major and, IMO crippling, limitation. This is approaching FUD. Guido

Re: [Python-Dev] PEP 526 ready for review: Syntax for Variable and Attribute Annotations

On Thu, Sep 01, 2016 at 04:11:05PM +0300, Koos Zevenhoven wrote: > Maybe it's just me, but I've always thought 'def' is Python's least > logically used keyword. It seems to come from 'define', but what is it > about 'define' that makes it relate to functions only. Convention. You can't use

Re: [Python-Dev] PEP 526 ready for review: Syntax for Variable and Attribute Annotations

On Tue, Aug 30, 2016 at 02:20:26PM -0700, Guido van Rossum wrote: > - Whether (given PEP 484's relative success) it's worth adding syntax > for variable/attribute annotations. The PEP makes a good case that it does. > - Whether the keyword-free syntax idea proposed here is best: > NAME: TYPE

Re: [Python-Dev] PEP 526 ready for review: Syntax for Variable and Attribute Annotations

On Tue, Aug 30, 2016 at 02:20:26PM -0700, Guido van Rossum wrote: > I'm happy to present PEP 526 for your collective review: Are you hoping to get this in before 3.6 beta? Because I'm not sure I can give this much attention before then, but I really want to. -- Steve

Re: [Python-Dev] PEP 526 ready for review: Syntax for Variable and Attribute Annotations

On Tue, Aug 30, 2016 at 07:15:55PM -0700, Guido van Rossum wrote: > On Tue, Aug 30, 2016 at 6:00 PM, Steven D'Aprano <st...@pearwood.info> wrote: > > On Tue, Aug 30, 2016 at 02:20:26PM -0700, Guido van Rossum wrote: > >> I'm happy to present PEP 526 for your collective

Re: [Python-Dev] C99

On Thu, Oct 06, 2016 at 10:10:54PM -0700, Nathaniel Smith wrote: > The reason this matters is that the official vendor compiler on RHEL 5 > is gcc 4.1, but there's also a separately-distributed version of gcc > 4.8.2 that can target it. Where can I get that 4.8 for RHEL 5? I'm using Centos 5,

Re: [Python-Dev] cpython (3.6): replace usage of Py_VA_COPY with the (C99) standard va_copy

On Thu, Sep 22, 2016 at 11:47:20PM -0700, Benjamin Peterson wrote: > > On Thu, Sep 22, 2016, at 04:44, Victor Stinner wrote: > > 2016-09-22 8:02 GMT+02:00 Benjamin Peterson : > > > Just dump the compat macros in Python 4.0 I think. > > > > Please don't. Python 3 was so

Re: [Python-Dev] Optimizing list.sort() by checking type in advance

On Mon, Oct 10, 2016 at 09:16:32PM +, Elliot Gorokhovsky wrote: > Anyway, benchmarking technique aside, the point is that it it works well > for small lists (i.e. doesn't affect performance). You've been shown that there is something suspicious about your benchmarking technique, something

Re: [Python-Dev] itertools predicates

On Wed, Nov 02, 2016 at 07:03:27PM -0300, Francisco Couzo wrote: > Some functions that take a predicate from itertools accept None as its > predicate: [...] > I'd be interested in writing a patch to make itertools more consistent if > there's a consensus. There's a line in PEP 8 about foolish

Re: [Python-Dev] Someons's put a "Python 2.8" on GitHub

On Fri, Dec 09, 2016 at 09:56:44PM -0800, Larry Hastings wrote: > > "Python 2.8 is a backwards-compatible Python interpreter with new > features from Python 3.x. It was produced by forking Python 2.7.12 and > backporting [...] > https://github.com/naftaliharris/python2.8 I seem to recall that

Re: [Python-Dev] Someons's put a "Python 2.8" on GitHub

On Mon, Dec 12, 2016 at 03:10:09AM -0600, Wes Turner wrote: > [Continuing to play devil's advocate for the sake of clarification] Clarification of *what* exactly? You don't seem to be asking any questions, just making statements. If you have a concrete, specific question, please ask it. If its

Re: [Python-Dev] Issue with _thread.interrupt_main (29926)

On Mon, Mar 27, 2017 at 10:33:44PM -0400, Terry Reedy wrote: > https://bugs.python.org/issue29926 was opened as an IDLE issue, which > means that most watching the new issues list would ignore it. But I > think it is an issue with _thread.interrupt_main (which IDLE calls in > respond to ^C)

Re: [Python-Dev] Sorting

On Thu, Apr 06, 2017 at 02:30:06AM +0200, Oleg Broytman wrote: >Sorry, let me pour a bit of cold water here. Recently I was busy > porting a few big and small (but complex) programs to Python 3 and was > sending thousands curses every day. str=>unicode is the biggest change > but not the most

Re: [Python-Dev] Application support

Hello Ryan, Welcome! My response is below. On Sun, Mar 12, 2017 at 10:49:13AM -0700, Ryan James Kenneth Murray wrote: > To whom it may concern, > > I was about to use Markdown to verify or indicate any changes to the files > when I was directed to c python and pep, however I have reached my >

Re: [Python-Dev] Can I revoke PEP 103 (info about git)?

On Wed, Mar 08, 2017 at 04:30:41PM +0100, Oleg Broytman wrote: > On Wed, Mar 08, 2017 at 09:50:06AM -0500, Barry Warsaw > wrote: > > It's also okay to remove much of the content and just leave a placeholder. > > The historical record would of course always be available in the

Re: [Python-Dev] Impact of Namedtuple on startup time

On Mon, Jul 17, 2017 at 02:43:19PM +0200, Antoine Pitrou wrote: > > Hello, > > Cost of creating a namedtuple has been identified as a contributor to > Python startup time. Not only Python core and the stdlib, but any > third-party library creating namedtuple classes (there are many of > them).

Re: [Python-Dev] Impact of Namedtuple on startup time

On Tue, Jul 18, 2017 at 01:17:24AM +0200, Giampaolo Rodola' wrote: > The extra memory overhead is a price I would be happy to pay considering > that collections.namedtuple is considerably slower than a plain tuple. > Other than the additional overhead on startup / import time, instantiation > is

Re: [Python-Dev] Impact of Namedtuple on startup time

On Mon, Jul 17, 2017 at 09:31:20PM +, Brett Cannon wrote: > As for removing exec() as a goal, I'll back up Christian's point and the > one Steve made at the language summit that removing the use of exec() from > the critical path in Python is a laudable goal from a security perspective. I'm

Re: [Python-Dev] for...else

Hello Kiuhnm, and welcome. On Mon, Jul 24, 2017 at 05:35:03PM +0200, Kiuhnm via Python-Dev wrote: > Hello, > > I think that the expression "for...else" or "while...else" is completely > counter-intuitive. You may be right -- this has been discussed many, many times before. In my personal

Re: [Python-Dev] Python startup time

On Wed, Jul 19, 2017 at 04:11:24PM -0700, Chris Barker wrote: > As long as we are talking anecdotes: > > If it could save a person’s life, could you find a way to save ten seconds > off the boot time? If there were five million people using the Mac, and it > took ten seconds extra to turn it on

Re: [Python-Dev] PEP 484 update proposal: annotating decorated declarations

On Tue, May 09, 2017 at 11:54:26PM +0400, Abdur-Rahmaan Janhangeer wrote: > I'm really new to the mailing list. Can someone just summarise the > preceding message in 5 to 10 lines like what it is, what type is it or when > does it happen It is an update to PEP 484, adding support for

Re: [Python-Dev] mention aenum in the Enum docs?

On Tue, May 09, 2017 at 10:05:43AM -0700, Ethan Furman wrote: > A comment on a recent SO answer [1] wondered why my aenum library wasn't > mentioned in the docs to help guide people that needed/wanted more advanced > Enum options to it. I know that the std lib is where good modules go to die

Re: [Python-Dev] Format strings, Unicode, and Py2.7: need clarification

On Wed, May 17, 2017 at 02:41:29PM -0700, Craig Rodrigues wrote: > e = "{}".format(u"hi") [...] > type(e) == str > The confusion for me is why is type(e) of type str, and not unicode? I think that's one of the reasons why the Python 2.7 string model is (1) convenient to those using purely

Re: [Python-Dev] "Micro-optimisations can speed up CPython"

On Mon, May 29, 2017 at 07:27:05PM -0700, Guido van Rossum wrote: > > https://www.corsix.org/content/why-are-slots-so-slow > > > > Is the author of that article using non-standard terminology? The article > doesn't appear to be about __slots__ at all. Quoting Armin Ronacher: By far my

Re: [Python-Dev] Language proposal: variable assignment in functional context

Welcome Robert. My response below. Follow-ups to Python-Ideas, thanks. You'll need to subscribe to see any further discussion. On Fri, Jun 16, 2017 at 11:32:19AM +, Robert Vanden Eynde wrote: > In a nutshell, I would like to be able to write: > y = (b+2 for b = a + 1) I think this is

Re: [Python-Dev] PEP 544

On Wed, Oct 04, 2017 at 03:56:14PM -0700, VERY ANONYMOUS wrote: > i want to learn Start by learning to communicate in full sentences. You want to learn what? Core development? Python? How to program? English? This is not a mailing list for Python beginners. Try the "tutor" or "python-list"

Re: [Python-Dev] PEP 553: Built-in debug()

On Tue, Sep 05, 2017 at 06:14:12PM -0700, Barry Warsaw wrote: > I’ve written a PEP proposing the addition of a new built-in function > called debug(). Adding this to your code would invoke a debugger > through the hook function sys.debughook(). [...] > P.S. This came to me in a nightmare on

Re: [Python-Dev] PEP 557: Data Classes

On Fri, Sep 08, 2017 at 10:37:12AM -0700, Nick Coghlan wrote: > > def __eq__(self, other): > > if other.__class__ is self.__class__: > > return (self.name, self.unit_price, self.quantity_on_hand) == > > (other.name, other.unit_price, other.quantity_on_hand) > > return

Re: [Python-Dev] PEP 559 - built-in noop()

On Mon, Sep 11, 2017 at 07:39:07AM +1000, Chris Angelico wrote: [...] > As a language change, definitely not. But I like this idea for > PYTHONBREAKPOINT. You set it to the name of a function, or to "pass" > if you want nothing to be done. It's a special case that can't > possibly conflict with

Re: [Python-Dev] PEP 551: Security transparency in the Python runtime

Very nicely written. A few comments below. On Mon, Aug 28, 2017 at 04:55:19PM -0700, Steve Dower wrote: [...] > This PEP describes additions to the Python API and specific behaviors > for the > CPython implementation that make actions taken by the Python runtime > visible to > security and

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

On Thu, Nov 30, 2017 at 11:54:39PM -0500, Random832 wrote: > The OP isn't confusing anything; it's Eric who is confused. The quoted > paragraph of the PEP clearly and unambiguously claims that the sequence > is "arguments -> function -> call", meaning that something happens after > the "function"

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

On Mon, Dec 18, 2017 at 06:11:05PM -0800, Chris Barker wrote: > Now that dicts are order-preserving, maybe we should change prettyprint: > > In [7]: d = {'one':1, 'two':2, 'three':3} > > In [8]: print(d) > {'one': 1, 'two': 2, 'three': 3} > > order preserved. > > In [9]: pprint.pprint(d) >

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

On Mon, Dec 18, 2017 at 07:37:03PM -0800, Nathaniel Smith wrote: > On Mon, Dec 18, 2017 at 7:02 PM, Barry Warsaw wrote: > > On Dec 18, 2017, at 21:11, Chris Barker wrote: > > > >> Will changing pprint be considered a breaking change? > > > > Yes,

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

On Mon, Dec 18, 2017 at 08:28:52PM -0800, Chris Barker wrote: > On Mon, Dec 18, 2017 at 7:41 PM, Steven D'Aprano <st...@pearwood.info> > wrote: > > > > With arbitrary order, it made sense to sort, so as to always give the > > same > > > "pretty&

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

On Tue, Dec 19, 2017 at 04:56:16PM -0800, Steve Dower wrote: > On 19Dec2017 1004, Chris Barker wrote: > >(though I assume order is still ignored when comparing dicts, so: > >eval(pprint(a_dict)) == a_dict will still hold. > > Order had better be ignored when comparing dicts, or plenty of code

[Python-Dev] Revisiting old enhancement requests

What is the best practice for revisiting old enhancement requests on the tracker, if I believe that the time is right to revisit a rejected issue from many years ago? (Nearly a decade.) Should I raise a new enhancement request and link back to the old one, or re-open the original? Thanks,

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

On Mon, Dec 18, 2017 at 08:49:54PM -0800, Nathaniel Smith wrote: > On Mon, Dec 18, 2017 at 7:58 PM, Steven D'Aprano <st...@pearwood.info> wrote: > > I have a script which today prints data like so: [...] > To make sure I understand, do you actually

Re: [Python-Dev] Comment on PEP 562 (Module __getattr__ and __dir__)

On Sun, Nov 19, 2017 at 08:24:00PM +, Mark Shannon wrote: > Hi, > > Just one comment. Could the new behaviour of attribute lookup on a > module be spelled out more explicitly please? > > > I'm guessing it is now something like: > > `module.__getattribute__` is now equivalent to: > > def

Re: [Python-Dev] Comment on PEP 562 (Module __getattr__ and __dir__)

On Sun, Nov 19, 2017 at 05:34:35PM -0800, Guido van Rossum wrote: > On Sun, Nov 19, 2017 at 4:57 PM, Steven D'Aprano <st...@pearwood.info> > wrote: > > A minor point: this should(?) be written in terms of the public > > interface for accessing namespaces, namely: >

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

On Mon, Nov 06, 2017 at 01:07:51PM +1000, Nick Coghlan wrote: > That means our choices for 3.7 boil down to: > > * make this a language level guarantee that Python devs can reasonably rely on > * deliberately perturb dict iteration in CPython the same way the > default Go runtime does [1] I

Re: [Python-Dev] PEP 563: Postponed Evaluation of Annotations

On Wed, Nov 01, 2017 at 03:48:00PM -0700, Lukasz Langa wrote: > PEP: 563 > Title: Postponed Evaluation of Annotations > This PEP proposes changing function annotations and variable annotations > so that they are no longer evaluated at function definition time. > Instead, they are preserved in

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

On Tue, Nov 07, 2017 at 05:28:24PM +1000, Nick Coghlan wrote: > On 7 November 2017 at 16:21, Steven D'Aprano <st...@pearwood.info> wrote: > > On Mon, Nov 06, 2017 at 08:05:07PM -0800, David Mertz wrote: > >> Maybe OrderedDict can be > >> rewritten to use the dict

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

On Mon, Nov 06, 2017 at 11:33:10AM -0800, Barry Warsaw wrote: > If we did make the change, it’s possible we would need a way to > explicit say that order is not preserved. That seems a little weird > to me, but I suppose it could be useful. Useful for what? Given that we will hypothetically

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

On Mon, Nov 06, 2017 at 10:17:23PM -0200, Joao S. O. Bueno wrote: > And also, forgot along the discussion, is the big disadvantage that > other Python implementations would have a quite > significant overhead on mandatory ordered dicts. I don't think that is correct. Nick already did a survey,

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

On Mon, Nov 06, 2017 at 06:35:48PM +0200, Paul Sokolovsky wrote: > For MicroPython, it would lead to quite an overhead to make > dictionary items be in insertion order. As I mentioned, MicroPython > optimizes for very low bookkeeping memory overhead, so lookups are > effectively O(n), but

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

On Mon, Nov 06, 2017 at 12:18:17PM +0200, Paul Sokolovsky wrote: > > I don't think that situation should change the decision, > > Indeed, it shouldn't. What may change it is the simple and obvious fact > that there's no need to change anything, as proven by the 25-year > history of the

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

On Mon, Nov 06, 2017 at 08:05:07PM -0800, David Mertz wrote: > I strongly opposed adding an ordered guarantee to regular dicts. If the > implementation happens to keep that, great. That's the worst of both worlds. The status quo is that unless we deliberately perturb the dictionary order,

Re: [Python-Dev] The current dict is not an "OrderedDict"

On Tue, Nov 07, 2017 at 05:37:15PM +0200, Serhiy Storchaka wrote: > 07.11.17 16:56, Steven D'Aprano пише: > >To clarify: if we start with an empty dict, add keys A...D, delete B, > >then add E...H, we could expect: [...] > Rather > > {A: 1, D: 4, C: 3} # move the last

Re: [Python-Dev] The current dict is not an "OrderedDict"

On Tue, Nov 07, 2017 at 03:32:29PM +0100, Antoine Pitrou wrote: [...] > > "Insertion ordered until the first key removal" is the only guarantee > > that's being proposed. > > Is it? It seems to me that many arguments being made are only relevant > under the hypothesis that insertion is ordered

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

On Mon, Nov 06, 2017 at 12:27:54PM +0100, Antoine Pitrou wrote: > The ordered-ness of dicts could instead become one of those stable > CPython implementation details, such as the fact that resources are > cleaned up timely by reference counting, that people nevertheless > should not rely on if

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

On Fri, Dec 01, 2017 at 08:24:05AM -0500, Random832 wrote: > On Fri, Dec 1, 2017, at 05:31, Steven D'Aprano wrote: > > I'm more confused than ever. You seem to be arguing that Python > > functions CAN short-circuit their arguments and avoid evaluating them. >

Re: [Python-Dev] \G (match last position) regex operator non-existant in python?

On Sun, Oct 29, 2017 at 12:31:01AM +0100, MRAB wrote: > Not that I'm planning on making any further additions, just bug fixes > and updates to follow the Unicode updates. I think I've crammed enough > into it already. There's only so much you can do with the regex syntax > with its handful of

Re: [Python-Dev] iso8601 parsing

On Wed, Oct 25, 2017 at 04:32:39PM -0400, Alexander Belopolsky wrote: > On Wed, Oct 25, 2017 at 3:48 PM, Alex Walters wrote: > > Why make parsing ISO time special? > > It's not the ISO format per se that is special, but parsing of str(x). > For all numeric types, int,

Re: [Python-Dev] Dealing with tone in an email (was: Drop/deprecate Tkinter?)

On Thu, May 03, 2018 at 06:31:03PM +, Brett Cannon wrote: > No one is saying people can't be upset and if you are ever upset there's > something wrong; we're human beings after all. But those of us speaking up > about the tone are saying that you can also wait until you're not so upset > to

Re: [Python-Dev] Dealing with tone in an email (was: Drop/deprecate Tkinter?)

On Fri, May 04, 2018 at 09:04:20AM -0700, Guido van Rossum wrote: > Thank you Steven! I assume that Brian hadn't seen my response (such crossed > messages due to delivery delays are very common in this mailing list). > > I'd like to use your email (nearly) verbatim to start off the discussion >

Re: [Python-Dev] Dealing with tone in an email

On Fri, May 04, 2018 at 03:21:28PM -0400, Terry Reedy wrote: > On 5/4/2018 11:43 AM, Steven D'Aprano wrote: > > >I'm not defending Ivan's initial email. His tantrum *was* annoying, > >unreasonable, and unfair to those who do care about tkinter. > > Ivan's email wa

<    5   6   7   8   9   10   11   12   13   14   >