Re: [Python-Dev] Python 3.6 dict becomes compact and gets a private version; and keywords become ordered

On Mon, Sep 12, 2016 at 3:57 PM Brett Cannon <br...@python.org> wrote: > On Mon, 12 Sep 2016 at 15:46 Ethan Furman <et...@stoneleaf.us> wrote: > > On 09/12/2016 09:27 AM, Gregory P. Smith wrote: > > > For the regular dict (non kwargs or namespace __dict__) use case I

Re: [Python-Dev] Python 3.6 dict becomes compact and gets a private version; and keywords become ordered

On Mon, Sep 12, 2016 at 9:51 AM Chris Angelico <ros...@gmail.com> wrote: > On Tue, Sep 13, 2016 at 2:27 AM, Gregory P. Smith <g...@krypto.org> wrote: > > Disorder for this purpose need not be a random shuffle (overkill). It > just > > needs to be regularly inco

Re: [Python-Dev] Python 3.6 dict becomes compact and gets a private version; and keywords become ordered

On Mon, Sep 12, 2016 at 10:25 AM INADA Naoki wrote: > > So fundamental question is: Is it to so bad thing that some people > write code depending on CPython and PyPy implementation? > Yes. See below. I think cross-interpreter libraries can use OrederedDict correctly >

Re: [Python-Dev] Python 3.6 dict becomes compact and gets a private version; and keywords become ordered

For the regular dict (non kwargs or namespace __dict__) use case I would actually like to *see disorder preserved during iteration*. If we don't, we will eventually to find ourselves in a similar state we were in pre hash-randomization: (1) Over time, code will come to depend on the order for no

Re: [Python-Dev] [Python-checkins] cpython: Use HTTP in testPythonOrg

Hi, Berker. Could you add a comment to the test on why this should use http? I can see this bouncing back and forth between http and https, as people clean an up all http usages to be https. Thanks. Eric. On 9/11/2016 8:46 AM, berker.peksag wrote:

Re: [Python-Dev] Python 3.6 dict becomes compact and gets a private version; and keywords become ordered

ffects the language spec bit. (OTOH it doesn't matter that much anyway... the language spec is definitely a useful thing, but it's largely aspirational in practice -- other implementations target CPython compatibility more than they target language spec compatibility.) -n -- Nathaniel J. Smith -- https:

Re: [Python-Dev] [Python-checkins] cpython: make invalid_comma_and_underscore a real prototype

Oops, thanks Benjamin. That was a copy and paste error. Eric. On 9/9/2016 11:15 PM, benjamin.peterson wrote: https://hg.python.org/cpython/rev/1e7b636b6009 changeset: 103539:1e7b636b6009 user:Benjamin Peterson date:Fri Sep 09 20:14:05 2016 -0700 summary:

Re: [Python-Dev] Changes to PEP 498 (f-strings)

of the backslash scenarios, but I'll watch the buildbots. Eric. On 8/30/2016 1:55 PM, Eric V. Smith wrote: After a long discussion on python-ideas (starting at https://mail.python.org/pipermail/python-ideas/2016-August/041727.html) I'm proposing the following change to PEP 498: backslashes inside brackets

[Python-Dev] What's the status of PEP 515?

The implementation of '_' in numeric literals is here: http://bugs.python.org/issue26331 And to add '_' in int.__format__ is here: http://bugs.python.org/issue27080 But I don't want to add support in int.__format__ unless numeric literal support is added. So, Georg and Serhiy: is issue 26331

Re: [Python-Dev] The Amazing Unreferenced Weakref

This code appears to have been added to fix https://bugs.python.org/issue3100 - A crash involving a weakref subclass. -gps On Tue, Sep 6, 2016 at 3:51 PM Larry Hastings wrote: > > This is all about current (3.6) trunk. > > In Objects/weakrefobject.c, we have the function >

Re: [Python-Dev] [New-bugs-announce] [issue27948] f-strings: allow backslashes only in the string parts, not in the expression parts

I'm aware of the buildbot failures due to this commit. I'm working on it. Sorry about that: tests passed on my machine. Eric. On 09/03/2016 09:24 AM, Eric V. Smith wrote: > > New submission from Eric V. Smith: > > See issue 27921. > > Currently (and for 3.6 be

Re: [Python-Dev] PEP 525, third round, better finalization

ough to make it work reliably on CPython, but I have serious concerns that it bakes a CPython-specific design into the language. I would prefer a design that actually aims for "level 2" cleanup semantics (for example, [1]) -n [1] https://mail.python.org/pipermail/python-ideas/2016-A

Re: [Python-Dev] Supported versions of OpenSSL

On Tue, Aug 30, 2016 at 1:08 PM M.-A. Lemburg wrote: > On 29.08.2016 22:16, Christian Heimes wrote: > > On 2016-08-29 21:31, M.-A. Lemburg wrote: > >> On 29.08.2016 18:33, Cory Benfield wrote: > >>> > On 29 Aug 2016, at 04:09, M.-A. Lemburg wrote: > >

[Python-Dev] Changes to PEP 498 (f-strings)

After a long discussion on python-ideas (starting at https://mail.python.org/pipermail/python-ideas/2016-August/041727.html) I'm proposing the following change to PEP 498: backslashes inside brackets will be disallowed. The point of this is to disallow convoluted code like: >>> d = {'a': 4} >>>

Re: [Python-Dev] Supported versions of OpenSSL

On Mon, Aug 29, 2016 at 1:18 PM Christian Heimes wrote: > On 2016-08-29 21:31, M.-A. Lemburg wrote: > > On 29.08.2016 18:33, Cory Benfield wrote: > >> > >>> On 29 Aug 2016, at 04:09, M.-A. Lemburg wrote: > >>> > >>> On 28.08.2016 22:40, Christian Heimes

[Python-Dev] Adding PEP 515's '_' formatting

PEP 515 adds underscores to numeric literals. As part of that, it adds optional underscores to numeric formatters (similar to PEP 378 for ','). See https://www.python.org/dev/peps/pep-0515/#further-changes I had assigned myself http://bugs.python.org/issue27080 to implement this.

Re: [Python-Dev] Making stdlib modules optional for distributions (Was: Breaking up the stdlib (Was: release cadence))

On 7/6/2016 10:44 PM, Nick Coghlan wrote: The point of overlap I see is that if the stdlib starts putting some selected modules into site-packages (so "pip install --upgrade " works without any changes to pip or equivalent tools), then that also solves the "How to explicitly declare dependencies

Re: [Python-Dev] release cadence (was: Request for CPython 3.5.3 release)

On Jul 3, 2016 1:45 PM, "Paul Moore" wrote: > [...] > Furthermore, pip/setuptools are just getting to the point of allowing > for dependencies conditional on Python version. If independent stdlib > releases were introduced, we'd need to implement dependencies based on >

Re: [Python-Dev] Compact ordered dict is not ordered for split table. (was: PEP XXX: Compact ordered dict

t data on this to confirm that it isn't a big issue, but intuitively, code like WeirdFoo.__init__ is vanishingly rare, and this is just a best-effort optimization anyway. Catching 98.9% of cases is good enough. Is there something I'm missing here? Is this your option #3? -n -- Natha

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

On Jun 16, 2016 10:01 AM, "David Mertz" wrote: > Python 3.6 is introducing a NEW MODULE, with new APIs. The 'secrets' module is the very first time that Python has ever really explicitly addressed cryptography in the standard library. This is completely, objectively untrue. If

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

On Jun 16, 2016 1:23 AM, "Stefan Krah" <ste...@bytereef.org> wrote: > > Nathaniel Smith pobox.com> writes: > > In practice, your proposal means that ~all existing code that uses > > os.urandom becomes incorrect and should be switched to either secrets &g

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

hat uses os.urandom becomes incorrect and should be switched to either secrets or random. This is *far* more churn for end-users than Nick's proposal. ...Anyway, since there's clearly going to be at least one PEP about this, maybe we should stop rehashing bits and pieces of the argument in these long threads that most people end up skipping and then rehashing again later? -n -- Nathaniel J. Smith -- https://vorpus.org ___ 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] BDFL ruling request: should we block forever waiting for high-quality random bits?

On Wed, Jun 15, 2016 at 10:25 PM, Theodore Ts'o <ty...@mit.edu> wrote: > On Wed, Jun 15, 2016 at 04:12:57PM -0700, Nathaniel Smith wrote: >> - It's not exactly true that the Python interpreter doesn't need >> cryptographic randomness to initialize SipHash -- it's more

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

runs very early -- to set some flag, and then we expose that flag in sys._something, and later in the startup sequence check for it after the warnings module is functional. Exposing the flag at the Python level would also make it possible for code like cloud-init to do its own explicit check an

Re: [Python-Dev] PEP 468

On Jun 13, 2016 6:16 PM, "MRAB" wrote: > > On 2016-06-14 01:47, 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

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

de, so they need to patch that regardless, and could just as easily make it robust against blocking /dev/urandom at the same time. I don't understand the RPM world as well, but I can't find any evidence that Fedora or SuSE ship systemd-cron at all.) -n -- Nathaniel J. Smith -- https://vorpus.org _

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

On Jun 11, 2016 11:13 PM, "Theodore Ts'o" wrote: > > On Sat, Jun 11, 2016 at 05:46:29PM -0400, Donald Stufft wrote: > > > > It was a RaspberryPI that ran a shell script on boot that called > > ssh-keygen. That shell script could have just as easily been a > > Python script that

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

On Thu, Jun 9, 2016 at 8:11 PM, Larry Hastings <la...@hastings.org> wrote: > > On 06/09/2016 07:58 PM, Nathaniel Smith wrote: > > I suspect the crypto folks would be okay with pushing this back to > 3.6, so long as the final resolution is that os.urandom remains the

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

r in 3.6? (And it would probably be good even in the long run to issue a prominent warning if hash seeding fails.) -n -- Nathaniel J. Smith -- https://vorpus.org ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/

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

exact spelling, semantics, and per-platform > implementation of these functions is far from settled, and nobody is > proposing that we do something like that for 3.5. We already have a function for non-crypto-strength pseudo-random bits: random.getrandbits. os.urandom is the one for the cry

Re: [Python-Dev] C99

free conditions on the compiled output. And Cygwin GCC isn't even real Windows. Maybe switching to Clang will make sense in 3.7 but that's a long ways off... -n -- Nathaniel J. Smith -- https://vorpus.org ___ Python-Dev mailing list Python-Dev@python.o

Re: [Python-Dev] C99

On 06/06/2016 10:11 AM, Guido van Rossum wrote: > On Mon, Jun 6, 2016 at 4:23 AM, Sturla Molden wrote: >> Guido van Rossum wrote: >> >>> I'm not sure I meant that. But if I have a 3rd party extension that >>> compiles with 3.5 headers using C89, then it

Re: [Python-Dev] New hash algorithms: SHA3, SHAKE, BLAKE2, truncated SHA512

t, and the right answer never changes). And in unlikely case where some terrible unexpected bug is discovered then the only maintenance needed will be to delete the current impl and drop-in whatever the new fixed one is. So +1 to adding SHA-3 and BLAKE to algorithms_guaranteed. -n -- Nathaniel J

Re: [Python-Dev] runtime dlls on Windows

s is the idea of my pynativelib proposal, though in this case you would only be using a small piece of the full proposal: https://mail.python.org/pipermail/wheel-builders/2016-April/90.html (I really need to get back to that... if anyone wants to help sprint on this

Re: [Python-Dev] Yearly PyPI breakage

keep things from breaking more than they already have. As long as that's the case it doesn't matter what "should" happen, there's no-one to do it. -n -- Nathaniel J. Smith -- https://vorpus.org ___ Python-Dev mailing list Python-Dev@python.org

Re: [Python-Dev] Most 3.x buildbots are green again, please don't break them and watch them!

On 4/13/2016 7:40 AM, Victor Stinner wrote: > Last months, most 3.x buildbots failed randomly. Some of them were > always failing. I spent some time to fix almost all Windows and Linux > buildbots. There were a lot of different issues. Thanks for all of your work on this, Victor. It's much

Re: [Python-Dev] Defining a path protocol

On Apr 7, 2016 10:00 AM, "Chris Barker" wrote: > > On Thu, Apr 7, 2016 at 12:00 AM, INADA Naoki wrote: >> >> >> I feel adding protocol only for path is bit over engineering. So I'm -0.5 on adding __fspath__. >> >> I'm +1 on adding general protocol

Re: [Python-Dev] Defining a path protocol

On Wed, Apr 6, 2016 at 3:54 PM, Gregory P. Smith <g...@krypto.org> wrote: > Note: While I do not object to the bike shed colors being proposed, if you > call the attribute .__path__ that is somewhat confusing when thinking about > the import system which declares that "any

Re: [Python-Dev] Defining a path protocol

ut I don't know afterwards). For __index__ the "built-in" is: from operator import index -n -- Nathaniel J. Smith -- https://vorpus.org ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev

Re: [Python-Dev] Defining a path protocol

Note: While I do not object to the bike shed colors being proposed, if you call the attribute .__path__ that is somewhat confusing when thinking about the import system which declares that *"any module that contains a __path__ attribute is considered a package"*. So would module.__path__ become a

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

On Apr 6, 2016 07:44, "Steven D'Aprano" wrote: > > 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)

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

ight be to have existing objects with unrelated attributes that happen to be called "path", and the bizarro problems that might be caused if someone accidentally passes one of them to a function that expects all .path attributes to be instances of this new protocol. -n -- Nathaniel J. Smi

Re: [Python-Dev] New OpenSSL - has anyone ever looked at (in)compatibility with LibreSSL

On Mon, Mar 14, 2016 at 4:56 PM Nathaniel Smith <n...@pobox.com> wrote: > Should people outside google pay attention to boringssl? The first > thing it says on the website is: > > "Although BoringSSL is an open source project, it is not intended for > general us

Re: [Python-Dev] New OpenSSL - has anyone ever looked at (in)compatibility with LibreSSL

cause there are no guarantees of API or ABI stability." On Mon, Mar 14, 2016 at 4:40 PM, Gregory P. Smith <g...@krypto.org> wrote: > Don't forget BoringSSL. > > On Wed, Mar 9, 2016 at 9:30 AM Michael Felt <mamf...@gmail.com> wrote: >> >> Can look at it. There

Re: [Python-Dev] New OpenSSL - has anyone ever looked at (in)compatibility with LibreSSL

Don't forget BoringSSL. On Wed, Mar 9, 2016 at 9:30 AM Michael Felt wrote: > Can look at it. There has been a lot of discussion, iirc, between OpenSSL > and LibreSSL re: version identification. > Thx for the reference. > > > On 08-Mar-16 14:55, Hasan Diwan wrote: > > > On 8

Re: [Python-Dev] Bug in build system for cross-platform builds

On Sun, Mar 13, 2016 at 7:41 PM Martin Panter wrote: > On 13 March 2016 at 01:13, Russell Keith-Magee > wrote: > > The patches that I've uploaded to Issue23670 [1] show a full > cross-platform > > [1] http://bugs.python.org/issue23670 > > build

Re: [Python-Dev] Python should be easily compilable on Windows with MinGW

On Feb 26, 2016 9:56 AM, "Alexander Walters" wrote: > > No. > > Visual Studio is a solid compiler suit, mingw is a jenky mess, especially when you try and move to 64bit (where I don't think there is one true version of mingw). I see why you say this, but I think you're

Re: [Python-Dev] RE 25939 - _ssl.enum_certificates broken on Windows

There are already many tests that require ctypes. See for example test_uuid.py. -- Eric. > On Feb 18, 2016, at 7:18 PM, Steve Dower wrote: > > I think the test is blocked on my question of whether we are allowed to rely > on ctypes in the test suite. > > If so, it's

Re: [Python-Dev] Buffer overflow bug in GNU C's getaddrinfo()

On Wed, Feb 17, 2016 at 12:12 PM Andrew Barnert via Python-Dev < python-dev@python.org> wrote: > On Feb 17, 2016, at 10:44, MRAB wrote: > > > > Is this something that we need to worry about? > > > > Extremely severe bug leaves dizzying number of software and devices >

Re: [Python-Dev] Disabling changing sys.argv[0] with runpy.run_module(...alter_sys=True)

On Tue, Feb 16, 2016 at 9:00 PM Mike Kaplinskiy wrote: > Hey folks, > > I hope this is the right list for this sort of thing (python-ideas seemed > more far-fetched). > > For some context: there is currently a issue with pex that causes > sys.modules lookups to stop

Re: [Python-Dev] fullOfEels, assistant program for writing Python extension modules in C

You're almost certainly aware of this, but just to double check since you don't mention it in the email: cython is also a great tool for handling similar situations. Not quite the same since in addition to generating all the boilerplate for you it then lets you use almost-python to actually write

Re: [Python-Dev] Improving docs for len() of set

On Mon, Feb 8, 2016 at 8:24 AM Ben Hoyt wrote: > Hi folks, > > Just a suggestion for a documentation tweak. Currently the docs for len() > on a set say this: > >.. describe:: len(s) > > Return the cardinality of set *s*. > > I'm a relatively seasoned programmer, but

Re: [Python-Dev] Issue #26204: compiler now emits a SyntaxWarning on constant statement

On Mon, Feb 8, 2016 at 9:44 AM Victor Stinner wrote: > Hi, > > I changed the Python compiler to ignore any kind "constant > expressions", whereas it only ignored strings and integers before: > http://bugs.python.org/issue26204 > > The compiler now also emits a

Re: [Python-Dev] [Speed] speed.python.org

Displaying ratios linearly rather than on a log scale axis can be misleading depending on what you are looking for. (feature request: allow a log scale?) major kudos to everyone involved in getting this setup! On Fri, Feb 5, 2016 at 11:06 PM Nick Coghlan wrote: > On 6

Re: [Python-Dev] Update PEP 7 to require curly braces in C

On Sun, Jan 17, 2016 at 11:12 AM Brett Cannon wrote: > While doing a review of http://bugs.python.org/review/26129/ I asked to > have curly braces put around all `if` statement bodies. Serhiy pointed out > that PEP 7 says curly braces are optional: >

Re: [Python-Dev] Code formatter bot

Indeed, automated code formatting is a good thing. But a bot is the wrong approach. You want a code formatting checker as a potential pre-submit hook (like we have had for white space issues in the past), but until you have super high confidence in it you need to make sure it is not a blocker for

Re: [Python-Dev] PEP 509: Add a private version to dict

On Mon, Jan 11, 2016 at 8:50 AM Victor Stinner wrote: > Hi, > > After a first round on python-ideas, here is the second version of my > PEP. The main changes since the first version are that the dictionary > version is no more exposed at the Python level and the field

Re: [Python-Dev] subprocess check_output

This mailing list is for the development of future versions of Python. For questions about using Python, please use python-list: https://mail.python.org/mailman/listinfo/python-list Eric. On 12/30/2015 07:25 PM, Carlos Barera wrote: > Hi, > > Trying to run a specific command (ibstat) installed

Re: [Python-Dev] Python 4 musings (was Re: Deleting with setting C API functions)

Except that we should skip version 4 and go directly to 5 in homage to http://www.montypython.net/scripts/HG-handgrenade.php. On Wed, Dec 2, 2015 at 9:13 AM Guido van Rossum wrote: > On Wed, Dec 2, 2015 at 8:57 AM, Barry Warsaw wrote: > >> On Dec 02, 2015,

Re: [Python-Dev] If you shadow a module in the standard library that IDLE depends on, bad things happen

On Oct 29, 2015 6:26 PM, "Terry Reedy" wrote: > > On 10/29/2015 11:59 AM, Laura Creighton wrote: >> >> >> see the following: >> lac@smartwheels:~/junk$ echo "print ('hello there')" >string.py >> lac@smartwheels:~/junk$ idle-python3.5 >> hello there >> Traceback (most recent call

Re: [Python-Dev] If you shadow a module in the standard library that IDLE depends on, bad things happen

On Oct 29, 2015 10:22 AM, "Brett Cannon" wrote: > > > > On Thu, 29 Oct 2015 at 09:00 Laura Creighton wrote: >> >> >> see the following: >> lac@smartwheels:~/junk$ echo "print ('hello there')" >string.py >> lac@smartwheels:~/junk$ idle-python3.5 >> hello there

Re: [Python-Dev] If you shadow a module in the standard library that IDLE depends on, bad things happen

On Oct 29, 2015 11:45 AM, "Donald Stufft" wrote: > > Every test runner that includes a =E2=80=94pdb flag that will automatical= > ly invoke pdb at the point of failure. If pdb++ didn=E2=80=99t force the = > shadowing of stdlib, then every single test runner would need an option

Re: [Python-Dev] If you shadow a module in the standard library that IDLE depends on, bad things happen

d "just work" for everyone, if I were going to spend time on trying to fix this I'd probably target that :-). (I guess the trickiest bit would be to find an efficient and maintainable way to check whether a given package name is present in the stdlib.) -n -- Nathaniel J. Smit

[Python-Dev] Bytcode "magic tag"

In issue 25483 I'm adding an opcode to make f-string formatting more robust and faster. As part of that, I'm bumping the .pyc magic number. While doing that, I notice Lib/importlib/_bootstrap_external.h includes this comment: # Starting with the adoption of PEP 3147 in Python 3.2, every bump in

Re: [Python-Dev] Bytcode "magic tag"

On 10/28/2015 10:22 AM, Eric Snow wrote: > On Wed, Oct 28, 2015 at 6:35 AM, Eric V. Smith <e...@trueblade.com> wrote: >> Do I need to do anything else? Unlike what the comment in >> _boostrap_external.py suggests, this "magic tag" will not change every >&g

Re: [Python-Dev] Bytcode "magic tag"

On 10/28/2015 10:19 AM, Barry Warsaw wrote: > On Oct 28, 2015, at 08:35 AM, Eric V. Smith wrote: > >> The "following table" is a comment, that contains a few references to >> the tag "cpython-", specifically cpython-32. It doesn't seem >> that

Re: [Python-Dev] Should PEP 498 specify if rf'...' is valid?

On Oct 27, 2015, at 4:39 PM, Mark Lawrence wrote: > >> On 27/10/2015 18:39, Sven R. Kunze wrote: >>> On 26.10.2015 20:54, Ethan Furman wrote: >>> You misunderstand -- the order of string prefixes does *not* matter, >>> so forcing us to use one is silly. >> >> I don't

Re: [Python-Dev] Should PEP 498 specify if rf'...' is valid?

On 10/22/2015 1:09 PM, Ryan Gonzalez wrote: > But it'd be weird now if fR worked but fbR didn't. Or bR (which is currently allowed) but not fbR in the future. Eric. > > On Thu, Oct 22, 2015 at 12:02 PM, Sven R. Kunze > wrote: > > On 22.10.2015

Re: [Python-Dev] Should PEP 498 specify if rf'...' is valid?

On 10/21/2015 10:57 PM, Ryan Gonzalez wrote: > It mentions fr'...' as a formatted raw string but doesn't say anything > about rf'...'. Right now, in implementing PEP 498 support in Howl > (https://github.com/howl-editor/howl/pull/118 and >

Re: [Python-Dev] PEP 484 -- proposal to allow @overload in non-stub files

On Wed, Oct 21, 2015 at 6:51 PM Guido van Rossum wrote: > Well the whole point is not to have to figure out how to implement that > right now. > > On Wed, Oct 21, 2015 at 6:45 PM, Random832 wrote: > >> Guido van Rossum writes: >> >

Re: [Python-Dev] Should PEP 498 specify if rf'...' is valid?

On 10/22/2015 7:32 AM, Eric V. Smith wrote: > On 10/21/2015 10:57 PM, Ryan Gonzalez wrote: >> It mentions fr'...' as a formatted raw string but doesn't say anything >> about rf'...'. Right now, in implementing PEP 498 support in Howl >> (https://github.com/howl-editor/howl/

[Python-Dev] PEP-8 wart... it recommends short names because of DOS

https://www.python.org/dev/peps/pep-0008/#names-to-avoid *"Since module names are mapped to file names, and some file systems are case insensitive and truncate long names, it is important that module names be chosen to be fairly short -- this won't be a problem on Unix, but it may be a problem

Re: [Python-Dev] An example of Python 3 promotion attitude

On Oct 6, 2015 4:31 AM, "Maciej Fijalkowski" wrote: > > There was a discussion a while ago about python 3 and the attitude on > social media and there was a lack of examples. Here is one example: > >

Re: [Python-Dev] VS 2010 compiler

On Sep 29, 2015 8:22 AM, "Chris Barker" wrote: > >> And in mingw-w64, the only way to select a non-default CRT > > what is a "default" CRT in this case?? To answer the question: mingw-w64's standard/default/only-officially-supported CRT is msvcrt.dll (the version that has

Re: [Python-Dev] VS 2010 compiler

On Sep 28, 2015 1:39 PM, "Paul Moore" wrote: > > On 28 September 2015 at 21:18, MRAB wrote: > > Same here. I compile the regex module for Python 2.5-2.7 and 3.1-3.5, > > both 32-bit and 64-bit, using MinGW-w64, and I haven't had a problem yet > >

Re: [Python-Dev] Committing a bug fix

At the top of the file in the default branch, I see: What's New in Python 3.6.0 alpha 1? Which has a few things in it. Eric. On 9/28/2015 7:30 PM, Guido van Rossum wrote: > It used to be tradition to keep old news sections. Looks like the last > time we cleared it out was for 3.4.0. > > But

Re: [Python-Dev] VS 2010 compiler

On Mon, Sep 28, 2015 at 2:55 PM, Paul Moore <p.f.mo...@gmail.com> wrote: > On 28 September 2015 at 22:18, Nathaniel Smith <n...@pobox.com> wrote: >> On Sep 28, 2015 1:39 PM, "Paul Moore" <p.f.mo...@gmail.com> wrote: >>> >>> On 28 September

Re: [Python-Dev] VS 2010 compiler

are definitely aware of Carl's work. -n -- Nathaniel J. Smith -- http://vorpus.org ___ 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] PEP 495 accepted

On Sep 22, 2015 1:09 PM, "Alexander Belopolsky" < alexander.belopol...@gmail.com> wrote: > > > On Tue, Sep 22, 2015 at 3:32 PM, Guido van Rossum wrote: >> >> it is broken, due to the confusion about classic vs. timeline arithmetic -- these have different needs but there's only

Re: [Python-Dev] Make stacklevel=2 by default in warnings.warn()

On Sep 21, 2015 12:15 AM, "Victor Stinner" wrote: > > Would it be too verbose to display two frames or more by default? > Maybe depending on the action (ex: only if the warning is emitted only > once). It's not just about how it gets displayed -- the frame that it gets

Re: [Python-Dev] Make stacklevel=2 by default in warnings.warn()

n 3.4.4, but Larry disagrees and I don't really care enough to argue about it either way :-). -n -- Nathaniel J. Smith -- http://vorpus.org ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscri

Re: [Python-Dev] Make stacklevel=2 by default in warnings.warn()

ut has nothing to do with the current call stack at all. -n -- Nathaniel J. Smith -- http://vorpus.org ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mail

Re: [Python-Dev] PEP 498 (interpolated f-string) tweak

On 9/20/2015 8:37 AM, Nick Coghlan wrote: > On 19 September 2015 at 21:03, Eric V. Smith <e...@trueblade.com> wrote: >> Instead of calling __format__, I've changed the code generator to call >> format(expr1, spec1). As an optimization, I might add special opcodes to >>

Re: [Python-Dev] PEP 498 (interpolated f-string) tweak

> On Sep 20, 2015, at 11:15 AM, Serhiy Storchaka <storch...@gmail.com> wrote: > >> On 20.09.15 16:51, Eric V. Smith wrote: >>> On 9/20/2015 8:37 AM, Nick Coghlan wrote: >>>> On 19 September 2015 at 21:03, Eric V. Smith <e...@trueblade.com> wrote: >

Re: [Python-Dev] PEP 498 (interpolated f-string) tweak

On 9/19/2015 3:36 PM, Eric V. Smith wrote: > On 9/19/2015 3:22 PM, Serhiy Storchaka wrote: >> On 19.09.15 14:03, Eric V. Smith wrote: >>> Instead of calling __format__, I've changed the code generator to call >>> format(expr1, spec1). As an optimization, I might add

Re: [Python-Dev] PEP 498 (interpolated f-string) tweak

On 9/19/2015 3:22 PM, Serhiy Storchaka wrote: > On 19.09.15 14:03, Eric V. Smith wrote: >> While finishing up the implementation of PEP 498, I realized that the >> PEP has an error. It says that this code: >> >> f'abc{expr1:spec1}{expr2!r:spec2}def{expr3:!s}ghi' >>

[Python-Dev] PEP 498 (interpolated f-string) tweak

While finishing up the implementation of PEP 498, I realized that the PEP has an error. It says that this code: f'abc{expr1:spec1}{expr2!r:spec2}def{expr3:!s}ghi' Is equivalent to: 'abc' + expr1.__format__(spec1) + repr(expr2).__format__(spec2) + 'def' + str(expr3).__format__('') + 'ghi' But

Re: [Python-Dev] [Numpy-discussion] The process I intend to follow for any proposed changes to NumPy

and dump around the > NumPy code base, and then improve on what is in my head with the rest of the > community. > > Thanks, > > -Travis > > > > ___ > NumPy-Discussion mailing list > numpy-discuss...@scipy.org > http://mail.scipy.org/mailman/

Re: [Python-Dev] PEP 498: Literal String Interpolation is ready for pronouncement

On 9/8/2015 8:27 PM, Guido van Rossum wrote: > I'm accepting PEP 498. Congratulations Eric! And thanks to everyone who > contributed. A lot of thought and discussion went into this -- Eric > himself was against the idea when it first came up! Thanks, Guido. In the next few days I'll update the

Re: [Python-Dev] PEP 498: Naming

On 09/08/2015 10:20 AM, Alexander Belopolsky wrote: > > On Tue, Sep 8, 2015 at 2:37 AM, Mike Miller > wrote: > > To my knowledge there was i for interpolation, t for template, and e > for expression suggested. Any better

Re: [Python-Dev] PEP 498: Literal String Interpolation is ready for pronouncement

On Sep 5, 2015 11:32 AM, "Eric V. Smith" <e...@trueblade.com> wrote: > > > Actually, my current implementation doesn't use the lexer, although I > > suppose it could. I'm currently manually scanning the string, keeping > > track of strings and parens. To fi

Re: [Python-Dev] PEP 498: Literal String Interpolation is ready for pronouncement

On Sep 5, 2015 9:20 AM, "Guido van Rossum" wrote: > > The processing of f-strings described by the PEP uses several phases: > > - find the end of the string (the final quote[s]) using the same algorithm used for all string literals > - expand \ escapes (e.g. \u) It might be

Re: [Python-Dev] PEP 498: Literal String Interpolation is ready for pronouncement

> Actually, my current implementation doesn't use the lexer, although I > suppose it could. I'm currently manually scanning the string, keeping > track of strings and parens. To find the end of an expression, it looks > for a '!', ':', or non-doubled '}', not inside of a string or (), [], or > {}.

Re: [Python-Dev] PEP 498: Literal String Interpolation is ready for pronouncement

On 9/5/2015 3:23 PM, Nathaniel Smith wrote: > On Sep 5, 2015 11:32 AM, "Eric V. Smith" <e...@trueblade.com > <mailto:e...@trueblade.com>> wrote: >> Ignore the part about non-doubled '}'. The actual description is: >> >&

Re: [Python-Dev] PEP 498: Literal String Interpolation is ready for pronouncement

On 9/5/2015 1:28 PM, Nathaniel Smith wrote: > On Sep 5, 2015 9:20 AM, "Guido van Rossum" <gu...@python.org > <mailto:gu...@python.org>> wrote: >> >> The processing of f-strings described by the PEP uses several phases: >> >> - find the e

Re: [Python-Dev] PEP 498: Literal String Interpolation is ready for pronouncement

On 9/5/2015 1:14 PM, Gustavo Carneiro wrote: > Why not allow string concatenation without plus sign only if/when the > implementation becomes optimised to allow compile time concatenation? > This makes it crystal clear whether the concatenation is compile time or > runtime. If we allow it now,

Re: [Python-Dev] PEP 498: Literal String Interpolation is ready for pronouncement

On 9/5/2015 12:18 PM, Guido van Rossum wrote: > On Sat, Sep 5, 2015 at 2:10 AM, haypo s > wrote: > > (is it possible to indent and comment code inside a f-string?) > > > Now that's an interesting question. I think the answer must

Re: [Python-Dev] PEP 498: Literal String Interpolation is ready for pronouncement

On 9/5/2015 7:12 PM, Nathaniel Smith wrote: > On Sat, Sep 5, 2015 at 1:00 PM, Eric V. Smith <e...@trueblade.com> wrote: >> On 9/5/2015 3:23 PM, Nathaniel Smith wrote: >>> On Sep 5, 2015 11:32 AM, "Eric V. Smith" <e...@trueblade.com >>> <mailto:e...@

Re: [Python-Dev] PEP 498: Literal String Interpolation is ready for pronouncement

On Sat, Sep 5, 2015 at 1:00 PM, Eric V. Smith <e...@trueblade.com> wrote: > On 9/5/2015 3:23 PM, Nathaniel Smith wrote: >> On Sep 5, 2015 11:32 AM, "Eric V. Smith" <e...@trueblade.com >> <mailto:e...@trueblade.com>> wrote: >>> Ignore th

[Python-Dev] PEP 498: Literal String Interpolation is ready for pronouncement

I've made a number of small changes to PEP 498. I don't think any of the changes I've made in the last week are substantive. Mostly I've clarified how it works and removing some limitations. The only meaningful change is that expressions are now surrounded by parens before they're evaluated. This

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