Re: [Python-Dev] Arbitrary non-identifier string keys when using **kwargs

On Sun, Oct 14, 2018 at 12:15 PM Jeff Allen wrote: > > > On 10/10/2018 00:06, Steven D'Aprano wrote: > > On Tue, Oct 09, 2018 at 09:37:48AM -0700, Jeff Hardy wrote: > > ... > > From an alternative implementation point of view, CPython's behaviour > *is* the

Re: [Python-Dev] Arbitrary non-identifier string keys when using **kwargs

On Sun, Oct 7, 2018 at 3:45 PM Terry Reedy wrote: > > On 10/7/2018 1:34 PM, Chris Barker via Python-Dev wrote: > > On Fri, Oct 5, 2018 at 3:01 PM Brett Cannon > > wrote: > > > > I'm also fine with saying that keys in **kwargs that are not proper > > identifiers is

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

On Mon, May 7, 2018 at 10:21 AM, Glenn Linderman wrote: > On 5/7/2018 7:59 AM, Eric Snow wrote: > > On Sun, May 6, 2018 at 8:25 PM, Nick Coghlan wrote: > > I'm inclined to agree that a Python 3.8 PEP in the spirit of the PEP 3003 > language moratorium could be a very good idea. > > Note that the

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

On Thu, Feb 11, 2016 at 10:15 AM, Andrew Barnert via Python-Dev < python-dev@python.org> wrote: > On Feb 11, 2016, at 09:39, Terry Reedy wrote: > > > > If trailing _ is allowed, to simplify the implementation, I would like > PEP 8, while on the subject, to say something like "While trailing _s on

[Python-Dev] Python Mobile-sig

There is now a Python SIG dedicated to running Python on mobile devices. Sign up for the mobile-...@python.org mailing list and find out more at [1]. The Mobile-SIG exists to improve the usability of Python on mobile devices, as mobile platforms have their own unique requirements and constraints.

[Python-Dev] IronPython 2.7.5 Released

On behalf of the IronPython team, I'm very happy to announce the release of IronPython 2.7.5[1]. Like all IronPython 2.7-series releases, .NET 4 is required to install it. Installing this release will replace any existing IronPython 2.7-series installation. Assemblies for embedding are provided for

Re: [Python-Dev] 2.7 Windows installers (Was: death to 2.7; long live 2.7)

On Sun, Apr 13, 2014 at 9:51 PM, "Martin v. Löwis" wrote: > As I just said: to get started, run the current build process. Without > knowing WiX in detail, I'd still claim that msi.py is superiour in > terms of expressiveness (i.e. it can better compute what files go into > the MSI). I'm almost ce

Re: [Python-Dev] [Python-checkins] cpython (3.3): Add -b and -X options to python man page.

On Sun, Jun 23, 2013 at 8:40 AM, Maciej Fijalkowski wrote: > >> +.BI "\-X " option > >> +Set implementation specific option. > > > > > > Should probably be "Set the implementation-specific option." > > Is there anyone respecting this notation? (I know pypy does not, it > uses --jit and stuff) > >

Re: [Python-Dev] PyPy, Jython, & IronPython: Enum convenience function and pickleablity

On Thu, May 2, 2013 at 1:18 PM, fwierzbi...@gmail.com wrote: > On Thu, May 2, 2013 at 12:07 PM, Ethan Furman wrote: >> In order for the Enum convenience function to be pickleable, we have this >> line of code in the metaclass: >> >> enum_class.__module__ = sys._getframe(1).f_globals['__name__

Re: [Python-Dev] Python Language Summit at PyCon: Agenda

On Mon, Mar 4, 2013 at 4:39 PM, Michael Foord wrote: > > On 1 Mar 2013, at 18:38, Antoine Pitrou wrote: > >> On Fri, 1 Mar 2013 09:32:23 -0500 >> Barry Warsaw wrote: >>> On the other hand in some ways Jython is sort of like Python on a weird virtual OS that lets the real OS bleed throu

Re: [Python-Dev] [compatibility-sig] do all VMs implement the ast module? (was: Re: AST optimizer implemented in Python)

On Mon, Aug 13, 2012 at 12:06 PM, Brett Cannon wrote: > Time to ask the other VMs what they are currently doing (the ast module came > into existence in Python 2.6 so all the VMs should be answer the question > since Jython is in alpha for 2.7 compatibility). IronPython has an _ast implementation

Re: [Python-Dev] [compatibility-sig] making sure importlib.machinery.SourceLoader doesn't throw an exception if bytecode is not supported by a VM

On Tue, Jun 12, 2012 at 12:01 PM, Brett Cannon wrote: > On Tue, Jun 12, 2012 at 2:28 PM, Eric Snow > wrote: >> >> On Tue, Jun 12, 2012 at 10:48 AM, Brett Cannon wrote: >> > I should mention another option is to add sys.dont_read_bytecode (I >> > think I >> > have discussed this with Frank at som

Re: [Python-Dev] [compatibility-sig] making sure importlib.machinery.SourceLoader doesn't throw an exception if bytecode is not supported by a VM

> 1) imp.cache_from_source is unimplemented, it's an AttributeError. Same for IronPython. > > 2) sys.dont_write_bytecode is always false, we don't respect that flag (we > really >   should IMO, but it's not a high priority for me, or anyone else apparently) Always True for IronPython. You can c

Re: [Python-Dev] backporting stdlib 2.7.x from pypy to cpython

On Mon, Jun 11, 2012 at 8:28 AM, Eric Snow wrote: > Nick's option 2 would be an improvement, but I imagine that option 3 > would have been the most effective by far.  Of course, the key thing > is how closely the various implementors would follow the new list. > Only they could say, though Frank W

Re: [Python-Dev] backporting stdlib 2.7.x from pypy to cpython

On Fri, Jun 8, 2012 at 8:13 AM, Matti Picus wrote: > > The windows port of pypy makes special demands on stdlib, specifically that > files are explicitly closed. There are some other minor issues, in order to > merge all the changes necessary to get pypy windows up to speed, around 10 > modules or

Re: [Python-Dev] sys.implementation

On Thu, May 10, 2012 at 3:39 PM, Steven D'Aprano wrote: >> Aye. Add a rule that all implementation specific (i.e. not defined in >> the PEP) keys must be prefixed with an underscore and I'm sold. > > > So now we're adding a new convention to single underscore names? Single > underscore names are i

Re: [Python-Dev] PEP 407: New release cycle and introducing long-term support versions

On Tue, Jan 17, 2012 at 3:50 PM, Ezio Melotti wrote: > * What is the effect on PyPy/Jython/IronPython?  Can they just skip the > feature releases and focus on the LTS ones? At least for IronPython it's unlikely we'd be able track the feature releases. We're still trying to catch up as it is. Hon

Re: [Python-Dev] Python as a Metro-style App

On Tue, Jan 10, 2012 at 4:20 PM, "Martin v. Löwis" wrote: >> Win 8 is practically a new OS target - the nt module may need to be >> replaced with a metro module to handle it well. > > No, it's not. Everything continues to work just fine on Windows 8, > as long as we keep developing desktop apps. >

Re: [Python-Dev] Python as a Metro-style App

On Sat, Jan 7, 2012 at 2:57 PM, Antoine Pitrou wrote: > Depending on the extent of removed/disabled functionality, it might not > be very interesting to have a Metro port at all. Win 8 is practically a new OS target - the nt module may need to be replaced with a metro module to handle it well. A

Re: [Python-Dev] PEP 3151 state

On Mon, Oct 3, 2011 at 11:32 AM, Antoine Pitrou wrote: > On Mon, 3 Oct 2011 19:56:04 +0200 > Antoine Pitrou wrote: > > > > Hello, > > > > I am back from holiday ;) and we haven't heard from other > > implementations whether there was any difficulty for them in > > implementing PEP 3151. > > Alex

Re: [Python-Dev] Windows 8 support

On Wed, Sep 14, 2011 at 4:38 AM, Neil Hodgson wrote: > Austin Fernandes: > >> Which versions of python will be compatible with windows8. I am using >> currently 2.7.2 version. > >   Current releases of both Python 2.7 and Python 3.2 appear to run > fine on the Windows 8 Developer Preview. You shou

Re: [Python-Dev] Draft PEP: "Simplified Package Layout and Partitioning"

On Tue, Jul 19, 2011 at 8:58 PM, P.J. Eby wrote: > The biggest likely exception to the above would be when a piece of > code tries to check whether some package is installed by importing > it.  If this is done *only* by importing a top-level module (i.e., not > checking for a ``__version__`` or so

Re: [Python-Dev] PEP 397 (Python launcher for Windows) reference implementation

On Thu, Jun 30, 2011 at 4:13 AM, Michael Foord wrote: > In the latest update Mark also addressed my main concern, making the > launcher configurable so it can also be used by alternative implementations > (particularly IronPython for Windows). I've copied Jeff Hardy and Dino