[Python-Dev] Re: Problems with dict subclassing performance

Has anyone raised this on bugs.python.org? That's the best way to get something like this looked at, not via a post on Stack Overflow. The SO posting didn't include a bpo link. Paul On Thu, 12 Aug 2021 at 07:33, Marco Sulla wrote: > > No ideas? Excuse me for the up. > > On Fri, 6 Aug 2021 at 21:2

[Python-Dev] Re: A better way to freeze modules

My quick reaction was somewhat different - it would be a great idea, but it’s entirely possible to implement this outside the stdlib as a 3rd party module. So the fact that no-one has yet done so means there’s less general interest than the OP is suggesting. And from my experience, the reason for

[Python-Dev] Re: A better way to freeze modules

On Fri, 3 Sept 2021 at 10:29, Simon Cross wrote: > > Hi Gregory, > > I think adding a meta path importer that reads from a standard > optimized format could be a great addition. I think the biggest open question would be "what benefits does this have over the existing zipimport?" Maybe it could b

[Python-Dev] Re: Should the definition of an "(async) iterator" include __iter__?

On Thu, 16 Sept 2021 at 01:30, Chris Barker via Python-Dev wrote: > """ > "[i]terators are required to have an __iter__() method" which neither `for` > nor `iter()` actually enforce. > """ > > I'm confused -- as far as I can tell `for` does enforce this -- well, it > doesn't enforce it, but it

[Python-Dev] Re: The Default for python -X frozen_modules.

On Tue, 28 Sept 2021 at 15:33, Eric Snow wrote: > > It means that the site module module can no longer be "customized" by > > modifying directly the site.py file (inject a path in PYTHONPATH env > > var where the customized site.py lives). But there is already a > > supported way to customize the

[Python-Dev] Re: Does ensurepip still have to include a copy of setuptools?

On Sat, 2 Oct 2021 at 03:27, Illia Volochii wrote: > > Hi everyone, > > ensurepip includes private copies of pip and setuptools. But PEP 453 states > that "once pip is able to run pip install --upgrade pip without needing > setuptools installed first, then the private copy of setuptools will be

[Python-Dev] Re: Does ensurepip still have to include a copy of setuptools?

On Sat, 2 Oct 2021 at 12:20, Thomas Grainger wrote: > > I raised an issue about this: https://github.com/pypa/pip/issues/10530 I agree with the comment made on that issue - this isn't the right way to handle the problem. We need to encourage projects to opt into the new approach and remove the le

[Python-Dev] Re: PEP 654 except* formatting

On Sun, 3 Oct 2021 at 16:55, Irit Katriel via Python-Dev wrote: > > We wonder if people have a view on which of the following is clearer/better: > > 1. except *E as e: // except *(E1, E2) as e: > 2. except* E as e: // except* (E1, E2) as e: > > (The difference is in the whitespace around the *

[Python-Dev] Re: PEP 654 except* formatting

On Mon, 4 Oct 2021 at 07:16, Greg Ewing wrote: > > On 4/10/21 6:23 pm, Guido van Rossum wrote: > > On Sun, Oct 3, 2021 at 9:20 PM Jonathan Goble > > wrote: > > > > Therefore my vote is for requiring `except* E` and keeping `except > > *E` as a SyntaxError. > > >

[Python-Dev] Re: Does ensurepip still have to include a copy of setuptools?

On Mon, 4 Oct 2021 at 08:21, Antoine Pitrou wrote: > > On Sat, 2 Oct 2021 13:27:03 +0100 > Paul Moore wrote: > > On Sat, 2 Oct 2021 at 12:20, Thomas Grainger wrote: > > > > > > I raised an issue about this: https://github.com/pypa/pip/issues/10530 > > &g

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

On Fri, 8 Oct 2021 at 03:45, S Pradeep Kumar wrote: > Typing-sig has been discussing user-friendly syntax for the type used to > represent callables. [1] Since this affects the Python language syntax, we > wanted to get some high-level feedback from you before putting up a detailed > PEP. Dis

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

On Fri, 8 Oct 2021 at 16:29, Jelle Zijlstra wrote: > That's one of the differences between the proposals discussed here. The basic > proposal Pradeep pointed out would not support named arguments, the more > complete syntax favored by Guido (and also by me; 2(a) in Pradeep's email) > would supp

Re: [Python-Dev] [Distutils] PEP 426 is now the draft spec for distribution metadata 2.0

On Tuesday, 19 February 2013, M.-A. Lemburg wrote: > > The only tool in wide spread use that understands part of the 1.2 data > is setuptools/distribute, but it can only understand the Requires-Dist > field of that version of the spec (only because the 1.1 Requires field was > deprecated) and inte

Re: [Python-Dev] Fwd: PEP 426 is now the draft spec fordistribution metadata 2.0

On 19 February 2013 13:59, Nick Coghlan wrote: > It's OK if people don't want to read the detailed rationale provided > for each of the major changes as part of the PEP, or if they want to > dispute a particular piece of that rationale. But merely going "it's > too complicated!" or "metadata 1.2 f

Re: [Python-Dev] Fwd: PEP 426 is now the draft spec for distribution metadata 2.0

On 19 February 2013 13:40, Nick Coghlan wrote: >> If a tools wants to support metadata 2.0, it has to support all >> the complicated stuff as well, i.e. handle the requires fields, >> the environment markers and version comparisons/sorting. > > Which is what distutils2 can be used for now, and wha

Re: [Python-Dev] Fwd: PEP 426 is now the draft spec for distribution metadata 2.0

On 19 February 2013 20:36, Donald Stufft wrote: > 2. There is currently no code that I am aware of that implements this > spec. I don't believe distlib does (yet - give Vinay 5 minutes and who > knows? :-)), pkg_resources as I said implements a different format, > and distutils2, apart from being

Re: [Python-Dev] Fwd: PEP 426 is now the draft spec for distribution metadata 2.0

On 20 February 2013 00:54, Fred Drake wrote: > I'd posit that anything successful will no longer need to be added to > the standard library, to boot. Packaging hasn't done well there. distlib may be the exception, though. Packaging tools are somewhat unique because of the chicken and egg issue i

Re: [Python-Dev] Fwd: PEP 426 is now the draft spec for distribution metadata 2.0

On 20 February 2013 04:07, Tres Seaver wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 02/19/2013 09:37 PM, Paul Moore wrote: >> On 20 February 2013 00:54, Fred Drake wrote: >>> I'd posit that anything successful will no longer need to be added

Re: [Python-Dev] cffi in stdlib

On 26 February 2013 16:34, Eli Bendersky wrote: > I'm cautiously +0.5 because I'd really like to see a strong comparison case > being made vs. ctypes. I've used ctypes many times and it was easy and > effortless (well, except the segfaults when wrong argument types are > declared :-). I'll be real

Re: [Python-Dev] cffi in stdlib

On 26 February 2013 18:34, Maciej Fijalkowski wrote: >> One point which I *think* is correct, but which I don't see noted >> anywhere. Am I right that cffi needs a C compiler involved in the >> process, at least somewhere? If that's the case, then it is not a >> suitable option for at least one us

Re: [Python-Dev] cffi in stdlib

On 27 February 2013 11:53, Maciej Fijalkowski wrote: > I think it means you can't use the ABI version and specify the calling > convention. It's a reasonable bug report (the calling convention on > API version works though) That would be a deal-breaker for my use case of quick scripts working wit

Re: [Python-Dev] cffi in stdlib

27 February 2013 18:24, Paul Moore wrote: > On 27 February 2013 11:53, Maciej Fijalkowski wrote: >> I think it means you can't use the ABI version and specify the calling >> convention. It's a reasonable bug report (the calling convention on >> API version works t

Re: [Python-Dev] cffi in stdlib

On 27 February 2013 18:50, Brett Cannon wrote: >> One other use case for the ABI level over the API level - the ABI >> level (no C extension) can be used across Python versions, where the >> API level needs a separate compiled extension per Python version. This >> can be a big deal on Windows at l

Re: [Python-Dev] cffi in stdlib

On 27 February 2013 19:08, Armin Rigo wrote: > That's not correct: you can't indeed give the calling convention, but > it is not needed for the common case. What is not supported is only > Python-defined callbacks using the Windows-specific convention --- as > documented, there is a workaround fo

Re: [Python-Dev] cffi in stdlib

On 27 February 2013 19:26, Paul Moore wrote: > On 27 February 2013 19:08, Armin Rigo wrote: >> That's not correct: you can't indeed give the calling convention, but >> it is not needed for the common case. What is not supported is only >> Python-defined callb

Re: [Python-Dev] cffi in stdlib

On 27 February 2013 23:18, Armin Rigo wrote: > from cffi import FFI > ffi = FFI() > ffi.cdef(""" > int MessageBox(HWND hWnd, LPCTSTR lpText, LPCTSTR lpCaption, UINT uType); > """) > lib = ffi.dlopen("USER32.DLL") > lib.MessageBox(ffi.NULL, "Hello, world!", "Title", 0) Yeah, that's loads bette

Re: [Python-Dev] cffi in stdlib

On 28 February 2013 09:06, Armin Rigo wrote: > And I think > that even on 64-bit Windows, passing 0 as a NULL pointer is buggy, > because it will pass a 32-bit 0. (It may be that it doesn't actually > make a difference and works anyway, but I'm not sure.) Similarly, a > function that returns a p

Re: [Python-Dev] IDLE in the stdlib

On 21 March 2013 00:38, Neil Hodgson wrote: > Terry Reedy: > >> Broken (and quirky): it has an absurdly limited output buffer (under a >> thousand lines) > >The limit is actually lines. > >> Quirky: Windows uses cntl-C to copy selected text to the clipboard and >> (where appropriate) cn

Re: [Python-Dev] IDLE in the stdlib

On 21 March 2013 06:54, Devin Jeanpierre wrote: > On Thu, Mar 21, 2013 at 2:42 AM, Terry Reedy wrote: >> I think being frozen in the late 1990s is better than being frozen in the >> early 1980s, like Command Prompt is. In fact, I think we should 'deprecate' >> the Command Prompt interpreter as th

Re: [Python-Dev] IDLE in the stdlib

On 21 March 2013 10:32, Terry Reedy wrote: > On 3/21/2013 5:27 AM, Paul Moore wrote: > >> Can I suggest that debates about the capability of Windows command >> line programming are off-topic here? > > > I respectfully disagree, unless you say that the whole thread is

[Python-Dev] PEP 405 (venv) - why does it copy the DLLs on Windows

PEP 405 has this note: """ On Windows, it is necessary to also copy or symlink DLLs and pyd files from compiled stdlib modules into the env, because if the venv is created from a non-system-wide Python installation, Windows won't be able to find the Python installation's copies of those files when

Re: [Python-Dev] PEP 405 (venv) - why does it copy the DLLs on Windows

On 23 March 2013 01:08, Vinay Sajip wrote: > Paul Moore gmail.com> writes: > >> I don't understand what this is saying - can someone clarify the >> reason behind this statement? What is different about a >> "non-system-wide installation" that cause

Re: [Python-Dev] PEP 405 (venv) - why does it copy the DLLs on Windows

On 23 March 2013 12:55, Antoine Pitrou wrote: > On Sat, 23 Mar 2013 12:57:02 + > Richard Oudkerk wrote: > >> On 23/03/2013 10:06am, Paul Moore wrote: >> >> One example of a non-system-wide installation is a source build of Python. >> >> PEP 405 venvs

[Python-Dev] Writing importers and path hooks

On 27 March 2013 21:19, Bradley M. Froehle wrote: > I implemented just such a path hook zipimporter plus the magic required > for C extensions --- as a challenge to myself to learn more about the Python > import mechanisms. > > See https://github.com/bfroehle/pydzipimport. Apologies for hija

Re: [Python-Dev] Writing importers and path hooks

On 28 March 2013 13:42, Brett Cannon wrote: >> importer, as I wanted to try a proof of concept importer based on the >> new importlib stuff (which is intended to make writing custom >> importers easier), and I really struggled to get something working. > > Struggling how? With the finder? The load

Re: [Python-Dev] Writing importers and path hooks

On 28 March 2013 16:08, Brett Cannon wrote: > You only need SourceLoader since you are dealing with Python source. You > don't need FileLoader since you are not reading from disk but an in-memory > zipfile. > > You should be implementing get_data, get_filename, and path_stats for > SourceLoader.

Re: [Python-Dev] casefolding in pathlib (PEP 428)

On 12 April 2013 09:39, Antoine Pitrou wrote: > Ok, I've taken a look at the code. Right now lower() is used for two > purposes: > > 1. comparisons (__eq__ and __ne__) > 2. globbing and matching > > While (1) could be dropped, for (2) I think we want glob("*.py") to find > "SETUP.PY" under Window

Re: [Python-Dev] Why can't I encode/decode base64 without importing a module?

On 22 April 2013 12:39, Calvin Spealman wrote: > if two lines is cumbersome, you're in for a cumbersome life a programmer. > One of which is essentially Python's equivalent of a declaration... Paul ___ Python-Dev mailing list Python-Dev@python.org http

[Python-Dev] Getting a list of registered codecs

Before I raise a bug for this, can someone confirm if I've simply missed something? I don't see any way, either in the docs or in the helpstrings from the codecs, of listing the codecs that have been registered. FWIW, I picked this up when I was looking at writing a simple encoding converter, and

Re: [Python-Dev] Getting a list of registered codecs

On 30 April 2013 10:42, M.-A. Lemburg wrote: > It would be possible to get a list of registered codec search functions, > but there's no API to ask the search functions for a list of supported > codecs. > OK, so there's no way to determine in advance what values of enc will work in bytestr.decod

Re: [Python-Dev] PEP 4XX: pyzaa "Improving Python ZIP Application Support"

On 2 April 2013 01:47, Daniel Holth wrote: > This PEP proposes to fix these problems by re-publicising the feature, > defining the .pyz and .pyzw extensions as “Python ZIP Applications” > and “Windowed Python ZIP Applications”, and providing some simple > tooling to manage the format. > There is

[Python-Dev] PEP 379 Python launcher for Windows - behaviour for #!/usr/bin/env python line is wrong

While reviewing the behaviour of Vinay's "distil" installer tool (see distutils-sig for details, but it's not relevant here) I have found what I think is a flaw in the behaviour of the py.exe launcher for Windows. To recap for people unfamiliar with the launcher, it emulates #! line interpretation

Re: [Python-Dev] PEP 4XX: pyzaa "Improving Python ZIP Application Support"

On 4 May 2013 07:48, Nick Coghlan wrote: > We don't need examples of arbitrary data file extentions, we need > examples of 4 letter extensions that are known to work correctly when > placed on PATHEXT, including when called from PowerShell. In the > absence of confirmation that 4-letter extension

Re: [Python-Dev] PEP 379 Python launcher for Windows - behaviour for #!/usr/bin/env python line is wrong

On 4 May 2013 15:20, Vinay Sajip wrote: > Paul Moore gmail.com> writes: > > > This will mean that scripts written with #!/usr/bin/env python will > > behave the same on Unix and Windows in the presence of activated > > virtualenvs. > > Overall I think it'

Re: [Python-Dev] PEP 379 Python launcher for Windows - behaviour for #!/usr/bin/env python line is wrong

On 4 May 2013 16:42, Vinay Sajip wrote: > I've taken a quick look at it, but I probably won't be able to make any > changes until the near the end of the coming week. Feel free to have a go; > OK, I have a patch against the standalone pylauncher repo at https://bitbucket.org/pmoore/pylauncher. I

Re: [Python-Dev] PEP 435 - requesting pronouncement

OK, I thought I'd take a look. I have never particularly needed enums in real life, so I'm reading the PEP from the POV of a naive user who is just thinking "hey, neat, Python got enums, let's see how they work". I have been skimming the discussions and my head has been exploding with the complexit

Re: [Python-Dev] PEP 435 - requesting pronouncement

On 5 May 2013 18:49, Guido van Rossum wrote: > > Summary - good job, I like the PEP a lot. But Python's enums are very > unlike > > those of other languages, and I suspect that's going to be more of an > issue > > than you'd hope... > > We're pretty confident that we're doing about the best job p

Re: [Python-Dev] PEP 4XX: pyzaa "Improving Python ZIP Application Support"

On 6 May 2013 20:46, Steve Dower wrote: > To summarise the bug, when PowerShell invokes a command based on an > extension in PATHEXT, only the first three characters of the extension are > used to determine the associated program. I tested this by creating a file > "test.txta" and adding ".TXTA"

Re: [Python-Dev] PEP 379 Python launcher for Windows - behaviour for #!/usr/bin/env python line is wrong

On 5 May 2013 18:10, Paul Moore wrote: > > On 4 May 2013 16:42, Vinay Sajip wrote: > >> I've taken a quick look at it, but I probably won't be able to make any >> changes until the near the end of the coming week. Feel free to have a go; >> > >

Re: [Python-Dev] PEP 443 - Single-dispatch generic functions

On 23 May 2013 15:58, Łukasz Langa wrote: > On 23 maj 2013, at 16:49, Guido van Rossum wrote: > > > Łukasz, are there any open issues? Otherwise I'm ready to accept the PEP. > > There's one. Quoting the PEP: > > "The dispatch type is currently specified as a decorator argument. The > implementat

Re: [Python-Dev] PEP 443 - Single-dispatch generic functions

On 23 May 2013 17:00, Walter Dörwald wrote: > Should it be possible to register multiple types for the generic function > with one register() call, i.e. should: > >@fun.register(int, float) >def _(arg, verbose=False): > ... > > be allowed as a synonym for > >@fun.register(int) >

Re: [Python-Dev] Validating SSL By Default (aka Including a Cert Bundle in CPython)

On 3 June 2013 21:05, Chris Angelico wrote: > +1 for having the default be safe, but this will have to be very > loudly announced ("when migrating from 3.3 to 3.4, TLS connections > will cease to work if blah blah"). > +1 on the default being safe, certainly. But with the proviso that the same c

Re: [Python-Dev] Validating SSL By Default (aka Including a Cert Bundle in CPython)

On 3 June 2013 22:46, Donald Stufft wrote: > Also, we should consider the issue for application users. Suppose I'm > using a Python application that downloads something from the web. I upgrade > to 3.4, and the app stops working because of a "will cease to work" case. > As an end user, how can I

Re: [Python-Dev] PEP 443 Accepted

On 5 June 2013 02:32, Guido van Rossum wrote: > Łukasz, > > Congratulations! I've accepted PEP 443. I've already marked it as > Accepted in the repo. I've also applied some very minor edits in order > to make the text flow a little better in a few places. I think this is > a great PEP -- it's sim

Re: [Python-Dev] PLY in stdlib (was cffi in stdlib)

On 15 July 2013 07:01, Raymond Hettinger wrote: > I would love to have PLY in the standard library. > It would open up a whole new world to some users > and be the basis for tool generation for others. > +1. Parser generators are useful tools - parsers are right on the boundary of "easy enough to

[Python-Dev] Adding Python scripts to PATHEXT on Windows

With the addition of the Python launcher (PEP 397), Python scripts on Windows are executable in much the same way as on Unix. However, "out of the box" it is still not quite possible to use Python scripts. This is because the .py extension is not registered with Windows in the PATHEXT environment v

Re: [Python-Dev] Adding Python scripts to PATHEXT on Windows

On 15 July 2013 09:40, Nick Coghlan wrote: > Sounds good to me - in the long run it may allow us to drop the Windows > exe wrappers when installing scripts on Windows. That's my motivation. In particular removing pip's exe wrappers to ease some of the issues being flagged on distutils-sig. Paul

Re: [Python-Dev] Adding Python scripts to PATHEXT on Windows

On 23 July 2013 17:11, "Martin v. Löwis" wrote: > Am 15.07.13 10:26, schrieb Paul Moore: > > Does anyone have any objections to this? I could try to write a patch, > > but I know next to nothing about building MSIs, so if any of the > > installer experts cou

Re: [Python-Dev] Inherance of file descriptor and handles on Windows (PEP 446)

On 23 July 2013 23:45, Victor Stinner wrote: > Said differently: the HANDLE_FLAG_INHERIT flag only has an effect on > *handles*, as indicated in its name. On Windows, file *descriptors* > are never inherited (are always closed) in child processes. I don't > think that it is possible to inherit fi

Re: [Python-Dev] Python 3 as a Default in Linux Distros

On 24 July 2013 10:12, Bohuslav Kabrda wrote: > - What should user get after using "yum install python"? > There are basically few ways of coping with this: > 1) Just keep doing what we do, eventually far in the future drop "python" > package and never provide it again (= go on only with python3/

Re: [Python-Dev] Official github mirror for CPython?

On 26 July 2013 08:50, Antoine Pitrou wrote: > > (For those that haven't seen it, RhodeCode seems broadly comparable to > > BitBucket feature wise, but because of the way it is licensed, the > > source code is freely available to all, and running your own instance > > is free-as-in-beer for non-p

Re: [Python-Dev] Adding Python scripts to PATHEXT on Windows

On 23 July 2013 17:33, Paul Moore wrote: > On 23 July 2013 17:11, "Martin v. Löwis" wrote: > >> Am 15.07.13 10:26, schrieb Paul Moore: >> > Does anyone have any objections to this? I could try to write a patch, >> > but I know next to nothing about buildi

Re: [Python-Dev] Adding Python scripts to PATHEXT on Windows

On 27 July 2013 21:14, Steve Dower wrote: > Any chance of this being made optional when installing? It provides no > benefit for people who prefer to associate scripts with an editor and may > be a source of confusion/complaints. > Personally, I don't know how to do this so someone else would h

Re: [Python-Dev] Adding Python scripts to PATHEXT on Windows

On 28 July 2013 00:30, Steve Dower wrote: > Another issue to consider is that the modification to PATHEXT can't be > undone when Python is uninstalled, unless each installation adds another > ".PY" and each uninstall removes only one (so my PATHEXT would look like > ...;.PY;.PY;.PY;.PY;.PY;.PY;.P

Re: [Python-Dev] Adding Python scripts to PATHEXT on Windows

On 28 July 2013 00:30, Steve Dower wrote: > > And if you change the association after the fact, you're presumably just > as capable > > of changing PATHEXT. > > Not if the association is changed by another installer (presumably with > the user's explicit permission). It would be very easy for peo

Re: [Python-Dev] Adding Python scripts to PATHEXT on Windows

On 30 July 2013 18:24, "Martin v. Löwis" wrote: > > Personally, I don't know how to do this so someone else would have to - > > It seems that this was settled as fine as-is; if you ever wanted to > allow this to be specifically enabled, you'd have to do three things > Thanks, Martin - MSI is a m

Re: [Python-Dev] Deprecating the formatter module

On 12 August 2013 20:22, Brett Cannon wrote: > At the PyCon CA sprint someone discovered the formatter module had > somewhat low code coverage. We discovered this is because it's tested by > test_sundry, i.e. it's tested by importing it and that's it. > > We then realized that it isn't really use

Re: [Python-Dev] please back out changeset f903cf864191 before alpha-2

On 26 August 2013 17:40, Eli Bendersky wrote: > Yes, exactly :-) "Incremental", though, seems to support the conjecture > that it's the input. Which is true, but, since XMLParser is also > "incremental" in this sense, slightly confusing. As a data point, until you explained the difference betwe

Re: [Python-Dev] Accepted: PEP 446 -- Make newly created file descriptors non-inheritable

On 27 August 2013 23:17, Guido van Rossum wrote: > Thanks for your tiresome work I'm guessing you meant "tireless" here :-) Paul ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http:/

Re: [Python-Dev] windows file closing race condition?

On 6 September 2013 13:21, Tim Golden wrote: > True, but then you're into determining a temporary name somewhere on the > same volume if possible and avoiding collisions etc. Again, I don't > think this is something we need to be doing by default in core Python. Agreed. There simply is no soluti

Re: [Python-Dev] windows file closing race condition?

On 6 September 2013 14:16, Richard Oudkerk wrote: > On 06/09/2013 1:55pm, Paul Moore wrote: >> >> ... If you rename the >> >> file to anywhere but the same directory, you potentially have >> permission issues. > > > Using the root directory avoids pe

Re: [Python-Dev] PEP 450 adding statistics module

On 8 September 2013 20:19, Steven D'Aprano wrote: [...] > Is this satisfactory or do I need to go into more detail? It describes only 7 functions, and yet you state there are 11. I'd suggest you add a 1-line summary of each function, something like: mean - calculate the (arithmetic) mean of the

Re: [Python-Dev] Add a "transformdict" to collections

On 10 September 2013 13:24, Paul Moore wrote: > On 10 September 2013 13:00, Nick Coghlan wrote: >> Is this just syntactic sugar for recursive lookup of a transformed version >> in __missing__? Or a way of supplying a custom "key" function to a >> dictionary?

Re: [Python-Dev] Add a "transformdict" to collections

On 10 September 2013 13:00, Nick Coghlan wrote: > Is this just syntactic sugar for recursive lookup of a transformed version > in __missing__? Or a way of supplying a custom "key" function to a > dictionary? Not quite, because the dict should preserve the originally entered key. >>> td['FOO'] =

Re: [Python-Dev] Add a "transformdict" to collections

On 10 September 2013 19:31, Antoine Pitrou wrote: >> I think it would be a flaw to have this detail implementation-defined. >> This would be like saying that it is implementation-defined which >> of A,B,C is returned from "A and B and C" if all are true. > > Ok, it seems everyone (except me :-)) a

Re: [Python-Dev] Add a "transformdict" to collections

On 10 September 2013 20:59, MRAB wrote: >> try: >> del d[k] >> finally: >> d[k] = v >> > That would raise a KeyError is the key was missing. A better way is: > > d.pop(k, None) Sorry, I was thinking of try...except: pass. But pop is indeed better. Teach me to code stuff on the fly witho

Re: [Python-Dev] PEP 447: add type.__locallookup__

On 19 September 2013 10:32, Ronald Oussoren wrote: > The first time a method is called the bridge looks for an Objective-C selector > with the same name and adds that to the class dictionary. This works fine for > normal > method lookups, by overriding __getattribute__, but causes problems with

Re: [Python-Dev] PEP 453 Round 4 - Explicit bootstrapping of pip in Python installations

On 19 September 2013 14:27, Donald Stufft wrote: > Major changes: > > * Removal of the option to fetch pip from PyPI in order not to modify the > trust model of the Python installers > * Consequently rename the model from ``getpip`` to ``extractpip`` If extractpip (I agree, I don't like the name

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

On 22 September 2013 13:54, Eli Bendersky wrote: > IMHO the right way to think about it is that the .rst files are by far the > more important documentation. Sometimes we forget that most Python > programmers are people who won't go into the source to read docstrings. While I agree entirely with

Re: [Python-Dev] PEP 453 (pip bootstrapping) ready for pronouncement?

On 27 September 2013 15:08, Stephen J. Turnbull wrote: >> New users on Windows and Mac OS X. I've heard many more complaints > > from folks running tutorials about the pip bootstrapping process than > > I ever have from the community at large about the GIL :P > > I bet those users are *not* runn

Re: [Python-Dev] PEP 453 (pip bootstrapping) ready for pronouncement?

On 27 September 2013 15:39, Mark Lawrence wrote: > On 27/09/2013 15:26, Paul Moore wrote: > >> So, for Windows users, installing a package becomes "pip install XXX". >> > > Apologies if this has already been said but it only works if you've already > ins

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

On 9 October 2013 10:46, Nick Coghlan wrote: > The PEP needs to state more clearly up front (preferably in the title) that > it's about *reserving* a Python level syntax that matches the syntax we > worked out for Argument Clinic at PyCon US. Explicitly stating that the > requirements that drive t

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

On 9 October 2013 13:38, Benjamin Peterson wrote: >> Generally, it needs to be a bit clearer that the intent of the PEP isn't to >> say "let's do this", it's to be explicit that acceptance of the Argument >> Clinic PEP severely constrains the design space for possible solutions if we >> ever *did*

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

On 9 October 2013 15:30, Larry Hastings wrote: > Only if I can stop writing other PEPs and replying to their discussion > threads! So once again, why is this new PEP needed? :-) Paul ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.

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

On 9 October 2013 15:53, Larry Hastings wrote: > My goal in writing the PEP was to codify existing practice, which meant > reflecting these (annoying!) corner cases accurately. That's fair. But I would argue that we very much don't want to encourage anyone ever duplicating that practice with new

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

On 9 October 2013 16:07, Larry Hastings wrote: > On 10/09/2013 04:38 PM, Paul Moore wrote: > > For that matter, why does the syntax used by Argument Clinic have to > be the same as whatever future syntax is used in Python? If indeed, > any ever is? What benefit do we get given th

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

On 9 October 2013 18:00, Ethan Furman wrote: > 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 serious

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

On 12 October 2013 00:29, Nick Coghlan wrote: > There's no grand policy change or clarification needed here, it's just > another consequence of the fact that the import system isn't documented > properly in versions prior to 3.3. And my personal apology for that. I knew when we wrote PEP 302 that

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

On 12 October 2013 01:53, Victor Stinner wrote: > t's easy to mix up PEP numbers. For example, Martin von Loewis wrote > two major PEP related to Unicode: 383 and 393. These numbers are > close, only one digit is different. It's worse when you discuss recent > PEPs: PEP 445 or PEP 454? Oops, no it

Re: [Python-Dev] Submitting PEP 453 (pip bootstrapping) for pronouncement

On 13 October 2013 13:43, Nick Coghlan wrote: > Accordingly, in addition to adding the option to extract and install ``pip`` > during installation, this PEP proposes that the Windows installer (and > ``sysconfig``) in Python 3.4 and later be updated to: > > - install scripts to PythonXY\bin rather

Re: [Python-Dev] The Tulip Has Landed

On 17 October 2013 23:40, Larry Hastings wrote: > For those interested parties: Guido just checked "asyncio", aka "Tulip", aka > "PEP 3156", in to trunk. I expect it to be part of Python 3.4.0a4, > hopefully to be released this weekend. Cool! How often do the online docs get built? There's nothi

Re: [Python-Dev] The Tulip Has Landed

On 18 October 2013 09:56, Terry Reedy wrote: > I believe once every 24 hours. The current page is dated Oct 17 (at bottom). > It is now Oct 18 most everywhere. Thanks, I didn't know there was a generated date at the bottom. Useful to know for the future! I'll wait for the update, cheers. Paul ___

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

On 9 June 2016 at 17:54, Ben Leslie wrote: >> My opinion is that blocking is slightly better than raising an exception >> because it matches what other OSs do, but that both blocking and raising an >> exception is better than silently giving data that may or may not be >> cryptographically secu

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

On 10 June 2016 at 03:13, Barry Warsaw wrote: > In my own experience, and IIRC Amber had a similar experience, the ease of > porting to Python 3 really comes down to how bytes/unicode clean your code > base is. Almost all the other pieces are either pretty manageable or fairly > easily automated.

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

On 10 June 2016 at 15:09, Cody Piersall wrote: >> One problem is that the str literals should be bytes >> literals. Comparison with None needs to be avoided. >> >> With Python 2 code runs successfully. With Python 3 the code >> crashes with a traceback. With my modified Python 3.6, the code >>

Re: [Python-Dev] Stop using timeit, use perf.timeit!

On 10 June 2016 at 15:34, David Malcolm wrote: >> The problem is that random noise can only ever slow the code down, it >> cannot speed it up. [...] > Isn't it possible that under some circumstances the 2nd process could > prefetch memory into the cache in such a way that the workload under > test

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

On 11 June 2016 at 22:46, Donald Stufft wrote: > I guess one question would be, what does the secrets module do if it’s on a > Linux that is too old to have getrandom(0), off the top of my head I can > think of: > > * Silently fall back to reading os.urandom and hope that it’s been seeded. > * Fal

Re: [Python-Dev] Why does base64 return bytes?

On 14 June 2016 at 16:19, Steven D'Aprano wrote: > Why does base64 encoding in Python return bytes? I seem to recall there was a debate about this around the time of the Python 3 move. (IIRC, it was related to the fact that there used to be a base64 "codec", that wasn't available in Python 3 beca

Re: [Python-Dev] Why does base64 return bytes?

On 15 June 2016 at 13:53, Daniel Holth wrote: > In that case could we just add a base64_text() method somewhere? Who would > like to measure whether it would be a win? "Just adding" a method in the stdlib, means we'd have to support it long term (backward compatibility). So by the time such an ex

Re: [Python-Dev] Bug in the DELETE statement in sqlite3 module

On 15 June 2016 at 07:40, ninostephen mathew wrote: > Respected Developer(s), > while writing a database module for one of my applications in python I > encountered something interesting. I had a username and password field in my > table and only one entry which was "Admin" and "password". While

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