Re: [Python-Dev] PEP 460: allowing %d and %f and mojibake

On 15 Jan 2014 04:16, "Guido van Rossum" wrote: > > [Other readers: asciistr is at https://github.com/jeamland/asciicompat] > > On Mon, Jan 13, 2014 at 11:44 PM, Nick Coghlan wrote: > > Right, asciistr is designed for a specific kind of hybrid API where > > yo

Re: [Python-Dev] PEP 460: allowing %d and %f and mojibake

On 15 Jan 2014 08:00, "Greg Ewing" wrote: > > Guido van Rossum wrote: >> >> def spam(a): >> r = asciistr('(') >> if a: r += a.strip() >> r += asciistr(')') >> return r >> >> The general fix would be to add >> >> else: r += a[:0] > > > The awkwardness might be reducable if asci

Re: [Python-Dev] PEP 461 - Adding % and {} formatting to bytes

On 15 Jan 2014 07:36, "Ethan Furman" wrote: > > On 01/14/2014 12:57 PM, Antoine Pitrou wrote: >> >> On Tue, 14 Jan 2014 11:56:25 -0800 >> Ethan Furman wrote: >>> >>> >>> %s, because it is the most general, has the most convoluted resolution: >>> >>> - input type is bytes? >>> pass it st

Re: [Python-Dev] PEP 460: allowing %d and %f and mojibake

On 15 Jan 2014 08:14, "Greg Ewing" wrote: > > Guido van Rossum wrote: >> >> Actually, Nick explained that asciistr() + asciistr() returns str, > > > That part seems wrong to me, because it means that > you can't write polymorphic byte/string functions > that are composable. > > I would be -1 on th

Re: [Python-Dev] PEP 461 - Adding % and {} formatting to bytes

On 15 Jan 2014 08:23, "Ethan Furman" wrote: > > On 01/14/2014 02:17 PM, Nick Coghlan wrote: >> >> >> On 15 Jan 2014 07:36, "Ethan Furman" > wrote: >>> >>> >>> On 01/14/2014 12:57 PM, Antoine Pitrou wrote: >

Re: [Python-Dev] PEP 460 reboot

On 15 Jan 2014 20:58, "Stephen J. Turnbull" wrote: > > Aside: OK, Guido, ya got me. > > I have a separate screed recounting the reasons for my apostasy, but > that's probably not interesting any more. I'll send it to individuals > on request. > > > But in terms of explaining the text model, that

Re: [Python-Dev] PEP 461 - Adding % and {} formatting to bytes

On 16 Jan 2014 17:53, "Ethan Furman" wrote: > > On 01/15/2014 06:45 AM, Brett Cannon wrote: >> >> >> This is why I have argued that if you specify it as "if there is a format spec specified, then the return value from >> calling __format__() will have str.decode('ascii', 'strict') called on it" yo

Re: [Python-Dev] PEP 461 updates

On 16 Jan 2014 11:45, "Carl Meyer" wrote: > > Hi Ethan, > > I haven't chimed into this discussion, but the direction it's headed > recently seems right to me. Thanks for putting together a PEP. Some > comments on it: > > On 01/15/2014 05:13 PM, Ethan Furman wrote: > >

Re: [Python-Dev] PEP 461 updates

On 17 Jan 2014 09:36, "Terry Reedy" wrote: > > On 1/16/2014 4:59 PM, Guido van Rossum wrote: > >> I'm getting tired of "did you understand what I said". > > > I was asking whether I needed to repeat myself, but forget that. > I was also saying that while I understand 'ascii-compatible encoding', I

Re: [Python-Dev] Closing the Clinic output format debate (at least for now)

nput changes and trust argument clinic to do the right thing, you can just skip reviewing it" notification directly into the filenames. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-De

Re: [Python-Dev] PEP 461 updates

se case was intermingled with general purpose text formatting on the str type, which is I think the main reason it has taken us so long to convince ourselves it is something that is genuinely worth bringing back in a more limited form in Python 3, rather than jus

Re: [Python-Dev] PEP 461 - Adding % and {} formatting to bytes

On 17 Jan 2014 18:03, "Eric Snow" wrote: > > On Thu, Jan 16, 2014 at 11:30 AM, Eric V. Smith wrote: > > For the first iteration of bytes.format(), I think we should just > > support the exact types of int, float, and bytes. It will call the > > type's__format__ (with the object as "self") and enc

Re: [Python-Dev] PEP 461 - Adding % and {} formatting to bytes

On 18 Jan 2014 02:08, "Paul Moore" wrote: > > On 17 January 2014 15:50, Eric V. Smith wrote: > > For #3, hopefully this "additional work" on the 3.x side would just be > > to add, to each class where you already have a custom __format__ used > > for b''.format(), code like: > > > > def __form

Re: [Python-Dev] PEP 461 - Adding % and {} formatting to bytes

On 18 Jan 2014 06:19, "Terry Reedy" wrote: > > On 1/17/2014 10:15 AM, Mark Lawrence wrote: > >> For both options 1 and 2 surely you cannot be suggesting that after >> people have written 2.x code to use format() as %f formatting is to be >> deprecated, > > > I will not be for at least a decade. I

Re: [Python-Dev] PEP 461 Final?

+1 on the technical spec from me. The rationale needs work, but you already know that :) For API consistency, I suggest explicitly noting that bytearray will also support the operation, generating a bytearray result. I also suggest introducing the phrase "ASCII compatible segments in binary forma

Re: [Python-Dev] .clinic.c vs .c.clinic

On 18 Jan 2014 19:08, "Chris Angelico" wrote: > > On Sat, Jan 18, 2014 at 8:02 PM, Serhiy Storchaka wrote: > > 2. I'm not use any IDE, but if you use, it can be important for you. If IDE > > shows sources tree, unlikely you want to see generated *.clinic.c files in > > them. This will increase th

Re: [Python-Dev] PEP 461 Final?

On 18 Jan 2014 11:52, "Ethan Furman" wrote: > > On 01/17/2014 05:27 PM, Steven D'Aprano wrote: >> >> On Fri, Jan 17, 2014 at 08:49:21AM -0800, Ethan Furman wrote: >>> >>> >>> Overriding Principles >>> = >>> >>> In order to avoid the problems of auto-conversion and Unicode >>> e

Re: [Python-Dev] PEP 461 updates

e doing latin-1 decoding already. If different rows in the *same* column are allowed to have different encodings, then that's not a valid use of the operation (since the column converter has no access to the rest of the row to determine what encoding should

Re: [Python-Dev] .clinic.c vs .c.clinic

to update that to skip clinic files without much difficulty (rather than having to exclude them manually from every search). Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Pytho

Re: [Python-Dev] PEP 461 Final?

repr("è").encode("ascii", "backslashreplace").decode("ascii")) 'è' (Please don't use eval() to reverse a transformation like this, as doing so not only makes security engineers cry, it's also likely to make your code vulner

Re: [Python-Dev] signature.object, argument clinic and grouped parameters

Guido, Larry and I thrashed out the required semantics for parameter groups at PyCon US last year (and I believe the argument clinic PEP describes those accurately). They're mainly needed to represent oddball signatures like range() and slice(). However, I'm inclined to say that the affected func

Re: [Python-Dev] .clinic.c vs .c.clinic

+1 for Contestant 4 for me as well, +0 for Contestant 5, -1 for the others. Same reasons as Georg, even where my votes are different. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https

Re: [Python-Dev] signature.object, argument clinic and grouped parameters

On 20 January 2014 20:16, Larry Hastings wrote: > > > On 01/19/2014 08:30 PM, Nick Coghlan wrote: > > Guido, Larry and I thrashed out the required semantics for parameter groups > at PyCon US last year (and I believe the argument clinic PEP describes those > accurately). >

Re: [Python-Dev] .clinic.c vs .c.clinic

opriate. That's substantially *less* directory clutter rather than more, just like __pycache__ vs the old model of implicitly creating adjacent .pyc and .pyo files. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _

Re: [Python-Dev] signature.object, argument clinic and grouped parameters

On 21 Jan 2014 06:26, "Terry Reedy" wrote: > > On 1/20/2014 7:59 AM, Nick Coghlan wrote: > >> However, while I know you're keen to finally make introspection work >> for all C level callables in 3.4, even the ones with signatures that >> can't be ex

Re: [Python-Dev] .clinic.c vs .c.clinic

On 21 Jan 2014 08:20, "Serhiy Storchaka" wrote: > > 20.01.14 20:09, Georg Brandl написав(ла): > >> Am 20.01.2014 14:31, schrieb Serhiy Storchaka: >>> >>> 20.01.14 15:03, Nick Coghlan написав(ла): >>>> >>>> On 20 January 201

Re: [Python-Dev] signature.object, argument clinic and grouped parameters

On 21 Jan 2014 09:26, "Larry Hastings" wrote: > > > > On 01/20/2014 04:59 AM, Nick Coghlan wrote: >> >> When I wrote that, I was thinking we had made >> inspect.Signature.__repr__ produce a nice string format, but then I >> noticed in the REPL to

Re: [Python-Dev] signature.object, argument clinic and grouped parameters

On 21 Jan 2014 13:49, "Larry Hastings" wrote: > > On 01/20/2014 03:53 PM, Nick Coghlan wrote: >> >> Please turn the question around and look at it with your release manager hat on rather than your creator of Argument Clinic hat: if I came to you and said I wanted to

Re: [Python-Dev] Formatting of positional-only parameters in signatures

On 22 Jan 2014 03:24, "Terry Reedy" wrote: > > On 1/21/2014 10:59 AM, Yury Selivanov wrote: >> >> There is one more, hopefully last, open urgent question with the signature >> object. At the time we were working on the PEP 362, PEP 457 didn’t >> exist. Nor did we have any function with real posito

Re: [Python-Dev] Enable Hostname and Certificate Chain Validation

part of 3.6 in 2017. I'd suggest a PEP along those lines, but I think you already have plenty to keep you busy helping to ride herd on the packaging ecosystem :) In the meantime, making it so that it *is* just a single additional function call to get proper TLS security settings in 3.4 is a

Re: [Python-Dev] Enable Hostname and Certificate Chain Validation

for us to realistically make it the default without a seriously long transition period (not quite IPv6 or even Python 3 long, but certainly not as short as the time period involved in introducing hash randomisation). Regards, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia __

Re: [Python-Dev] Enable Hostname and Certificate Chain Validation

On 22 January 2014 22:15, Donald Stufft wrote: > > On Jan 22, 2014, at 6:58 AM, Nick Coghlan wrote: >> >> The kinds of decisions that an application like a web browser or a >> package installer can make aren't necessarily available to a runtime. >> We had t

Re: [Python-Dev] Enable Hostname and Certificate Chain Validation

their browser, curl, wget, etc > > Python is not a Web client. Are you talking specifically about urllib? And all the other client modules that can make secure network connections (but don't validate that the certificate matches the hostname by default). Cheers, Nick. --

Re: [Python-Dev] Enable Hostname and Certificate Chain Validation

On 23 Jan 2014 00:39, "Benjamin Peterson" wrote: > > On Wed, Jan 22, 2014, at 04:15 AM, Donald Stufft wrote: > > > > On Jan 22, 2014, at 6:58 AM, Nick Coghlan wrote: > > > > > On 22 January 2014 21:36, Donald Stufft wrote: > > >> On Jan

Re: [Python-Dev] Enable Hostname and Certificate Chain Validation

On 23 Jan 2014 07:48, "Donald Stufft" wrote: > > Never mind. If someone else cares they can propose it. I withdraw. That's unfortunate, but understandable - we already have a lot to deal with just trying to get even the software distribution infrastructure to a "secure by default" status. Howeve

Re: [Python-Dev] Enable Hostname and Certificate Chain Validation

the > trusted CAs. Or, depending on the exact transition plan, potentially set: PYTHONSSLDEFAULT=NOVERIFY (akin to the "no, really, don't randomise the hashes" option). That's the kind of question a PEP would be needed to thrash out, though. Cheers, Nick. -- Nick Coghlan |

Re: [Python-Dev] Python 3 marketing document?

I've tried to address the most common questions and misapprehensions in my Python 3 Q & A: http://python-notes.curiousefficiency.org/en/latest/python3/questions_and_answers.html Cheers, Nick. ___ Python-Dev mailing list Python-Dev@python.org https://mail

Re: [Python-Dev] str.rreplace

On 25 Jan 2014 09:46, "Brett Cannon" wrote: > On Fri, Jan 24, 2014 at 6:02 PM, Mark Lawrence wrote: >>> >> >> Okay, I'll leave the snarky comments to the people who are authorised to be snarky. How do you get on this list? Is it any core dev, or are there more severe restrictions than that, for

Re: [Python-Dev] str.rreplace

On 25 January 2014 11:14, Steven D'Aprano wrote: > On Sat, Jan 25, 2014 at 10:41:05AM +1000, Nick Coghlan wrote: > >> In this specific case, our general communication about the different >> purposes of the core lists *isn't* particularly good, > > Nick,

Re: [Python-Dev] Quick poll: should help() show bound arguments?

unctions. +1 from me for fixing the signature help() and pydoc report for bound methods that are reported as such. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org https:

Re: [Python-Dev] lambda (x, y):

nd-class citizens that are not worth > consideration. Given that lambdas only just escaped being removed entirely from the language in Python 3, that impression isn't wrong. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia __

Re: [Python-Dev] Argument Clinic: what to do with builtins with non-standard signatures?

1) Change the signature until it is Python compatible. This new > signature *must* accept a superset of the arguments accepted > by the existing signature. (This is being discussed right > now in issue #19145.) For these, I think we should respect the release cycle a

Re: [Python-Dev] Argument Clinic: what to do with builtins with non-standard signatures?

On 25 January 2014 17:44, Nick Coghlan wrote: > On 25 January 2014 01:07, Larry Hastings wrote: >> c) Functions that accept an 'int' when they mean 'boolean' (aka the >>"ints instead of bools" problem) >> >>Solution: >>

Re: [Python-Dev] Argument Clinic: what to do with builtins with non-standard signatures?

On 25 January 2014 19:20, Nick Coghlan wrote: > On 25 January 2014 17:44, Nick Coghlan wrote: >> On 25 January 2014 01:07, Larry Hastings wrote: >>> c) Functions that accept an 'int' when they mean 'boolean' (aka the >>>"ints instead of

Re: [Python-Dev] Argument Clinic: what to do with builtins with non-standard signatures?

the 3.5 release PEP early so we can start making notes of things we've decided we would like to do but are too late for 3.4... Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-De

Re: [Python-Dev] New policies for the Derby -- please read!

quite a bit of work, so postponing it is an option definitely worth considering at this point in the release cycle. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org htt

Re: [Python-Dev] version numbers mismatched in google search results.

nsive array of existing unqualified deep links, which relate to Python 2. >> I looked (googled) for an example of a google link to current version of >> python 3.3 documentation. My approach was to google "python" and >> something >> listed in >> http://docs

Re: [Python-Dev] Deprecation policy

eased complexity and needing to manage the deprecation process), and provide a worse experience for users implementing custom import hooks that need to support multiple versions (due to the introduction of new cross-version compatibility issues). Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com

Re: [Python-Dev] cpython: Issue 19944: Fix importlib.find_spec() so it imports parents as needed.

keep the top level namespace simple and relatively easy to learn. find_loader()/find_spec() are both borderline as to which category they fall into, but as Eric noted, there was a dependency issue in this case which meant there were practical benefits to putting find_spec() in the "im

Re: [Python-Dev] Negative times behaviour in itertools.repeat for Python maintenance releases (2.7, 3.3 and maybe 3.4)

On 27 Jan 2014 04:44, "Serhiy Storchaka" wrote: > > 26.01.14 19:00, Vajrasky Kok написав(ла): > >> So I hope my argument is convincing enough. We need to fix this bug in >> Python 2.7, 3.3, and 3.4, by making `times` argument sent via >> positional or keyword in itertools.repeat ALWAYS means the s

Re: [Python-Dev] Negative times behaviour in itertools.repeat for Python maintenance releases (2.7, 3.3 and maybe 3.4)

er), rather than just a partial fix. That is, I'm OK with either not backporting anything at all, or backporting the full change. The only idea I object to is the one of removing the infinite iteration capability without providing a replacement spelling for it. Cheers, Nick. -- Nick Coghlan |

Re: [Python-Dev] [Python-checkins] peps: Incorporate PEP 462 feedback

first, and a doc patch, added to the doc queue if > the code patch succeeded. That seems like added complexity for little gain - note that we can make the *test runner* smart about how it handles doc-only patches, by just checking the docs build and skipping the test run. Cheers, Nick. -- Nick

Re: [Python-Dev] Negative times behaviour in itertools.repeat for Python maintenance releases (2.7, 3.3 and maybe 3.4)

x27;t feed it untrusted data, because a large enough value that just fits into RAM can still cause you a lot of grief. Everything points to "times=-1" behaving as it does being a bug, but not a sufficiently critical one to risk breaking working code in a maintenance release. That makes d

Re: [Python-Dev] Negative times behaviour in itertools.repeat for Python maintenance releases (2.7, 3.3 and maybe 3.4)

een judged as posing too great a risk of breaking end user code to implement in a maintenance release, even when they're to resolve bugs. This is the one for 3.4: http://docs.python.org/dev/whatsnew/3.4.html#porting-to-python-3-4 Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com |

Re: [Python-Dev] Guidance regarding what counts as breaking backwards compatibility

#x27;re pretty much stuck. This is why you tend to see newer stdlib APIs often exposing functions that return private object types, rather than exposing the object type itself: exposed a function just promises a callable() API, while exposing a class directly promises a lot more in terms of suppor

Re: [Python-Dev] The docstring hack for signature information has to go

your 3.3 docstring, you must produce version specific binaries (which allows #ifdef hackery). Then PEP 457 can address this properly for 3.5 along with the other issues it needs to cover. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _

Re: [Python-Dev] Decision on the docstring hack (was Re: The docstring hack for signature information has to go)

Sounds like a good compromise to me - and we certainly have a lot of interesting experience to feed into the design of PEP 457 for 3.5 ;) Cheers, Nick. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev

Re: [Python-Dev] [Python-checkins] cpython: Close #20053: ignore default pip config settings

On 6 Feb 2014 05:27, "Jeremy Kloth" wrote: > > On Tue, Feb 4, 2014 at 6:03 AM, nick.coghlan wrote: > > http://hg.python.org/cpython/rev/1b8ba1346e67 > > changeset: 88955:1b8ba1346e67 > > user:Nick Coghlan > > date:Tue Feb 04 23:02:36 20

Re: [Python-Dev] Is the PIP requirement too strict?

Right, I think this is a genuine bug in the ensurepip CLI mode. http://bugs.python.org/issue19744 was still pending with Tim (to see if it solved the original problem), but we need to more gracefully handle the error at the CLI level as well. ___ Python-D

Re: [Python-Dev] MSI installer won't install on WinXP-SP2 (was Re: [RELEASED] Python 3.4.0 release candidate 1)

On 13 Feb 2014 04:06, "Bob Hanson" wrote: > > TL;DR: Solved. Thanks, Victor, for prodding me to jump through > all those Windows hoops. ;-) > > [More comments interleaved below:] > > On Wed, 12 Feb 2014 18:15:43 +0100, Victor Stinner wrote: > > > 2014-02-12 18:10 GMT+01:00 Bob Hanson : > > > > By

Re: [Python-Dev] python 3 niggle: None < 1 raises TypeError

de how they want None to be handled in the context of ordering operations. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python

Re: [Python-Dev] python 3 niggle: None < 1 raises TypeError

o this recently, in the context of "NULL == value" and "NULL != value" both being effectively false). We could theoretically do something similar, but the NULL handling in SQL is a frequent source of bugs in filter definitions, so that really doesn't sound like

Re: [Python-Dev] python 3 niggle: None < 1 raises TypeError

still occasionally wonder if "AlwaysMin" and "AlwaysMax" singletons might make sense, although that approach has problems of its own (specifically, it's hard to actually use without breaking the clean NULL -> None mapping and in many cases +/- infinity al

Re: [Python-Dev] Function to handle None in sort operation, was Re: python 3 niggle: None < 1 raises TypeError

haviour for all of those, such that you only needed to define the other methods if you wanted to override the defaults for some reason. (As noted in the issue, this is also amenable to being implemented as a third party module prior to proposing it as a language feature) Cheers, Nick. -- Ni

Re: [Python-Dev] python 3 niggle: None < 1 raises TypeError

s that we completely missed the use case of being able to sensibly map SQL NULL handling in ORDER BY clauses to the sorting of Python 3 containers. Having a concrete use case with widespread implications makes a big difference :) Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com |

Re: [Python-Dev] Add Py_REPLACE and Py_XREPLACE macros

th asking Larry for permission to make the late C API addition for 3.4, though) Regards, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listi

Re: [Python-Dev] Using more specific methods in Python unit tests

neral policy against large scale changes to take advantage of new features still applies to the test suite just as much as it does to the rest of the standard library. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Py

Re: [Python-Dev] pootle.python.org is down

On 17 Feb 2014 02:20, "Georg Brandl" wrote: > > Am 16.02.2014 16:32, schrieb Benjamin Peterson: > > On Sun, Feb 16, 2014, at 06:52 AM, A.M. Kuchling wrote: > >> I came across http://bugs.python.org/issue13663, which is about a > >> pootle.python.org installation. http://pootle.python.org/ current

Re: [Python-Dev] Add Py_REPLACE and Py_XREPLACE macros

On 17 Feb 2014 06:12, "Serhiy Storchaka" wrote: > > 16.02.14 02:05, Nick Coghlan написав(ла): > >> It's also likely than many of these crashes could only be reproduced >> through incorrect usage of the C API. > > > Rather through queer or malicious

Re: [Python-Dev] Python 3.4: What to do about the Derby patches

On 17 Feb 2014 08:36, "Greg Ewing" wrote: > > Larry Hastings wrote: > >> 3) We hold off on merging the rest of the Derby patches until after 3.4.0 final ships, then we merge them into the 3.4 maintenance branch so they go into 3.4.1. > > > But wouldn't that be introducing a new feature into a > ma

Re: [Python-Dev] python 3 niggle: None < 1 raises TypeError

On 17 Feb 2014 21:15, "M.-A. Lemburg" wrote: > > On 15.02.2014 07:03, Stephen J. Turnbull wrote: > > M.-A. Lemburg writes: > > > > > IMO, it was a mistake to have None return a TypeError in > > > comparisons, since it makes many typical data operations > > > fail, e.g. > > > > I don't understan

Re: [Python-Dev] Python 3.4: What to do about the Derby patches

On 18 Feb 2014 03:37, "Larry Hastings" wrote: > > > On 02/16/2014 04:03 PM, Victor Stinner wrote: >> >> Hi, >> >> The PEP 436 is still a draft and not mentionned in Python 3.4 >> changelog. The PEP proposes to add a DSL, not to modify all modules >> implemented in C. I think that it should be mark

Re: [Python-Dev] python 3 niggle: None < 1 raises TypeError

On 17 Feb 2014 22:25, "M.-A. Lemburg" wrote: > > On 17.02.2014 13:12, Nick Coghlan wrote: > > On 17 Feb 2014 21:15, "M.-A. Lemburg" wrote: > >> > >> On 15.02.2014 07:03, Stephen J. Turnbull wrote: > >>> M.-A. Lemburg writes: > >

Re: [Python-Dev] python 3 niggle: None < 1 raises TypeError

On 18 Feb 2014 08:25, "Nick Coghlan" wrote: > > > On 17 Feb 2014 22:25, "M.-A. Lemburg" wrote: > > > > On 17.02.2014 13:12, Nick Coghlan wrote: > > > On 17 Feb 2014 21:15, "M.-A. Lemburg" wrote: > > >> > > >> N

Re: [Python-Dev] python 3 niggle: None < 1 raises TypeError

On 19 Feb 2014 07:26, "Paul Moore" wrote: > > On 18 February 2014 21:17, Greg Ewing wrote: > > What I'd *really* like to be able to write is: > > > >sort(invoices, keyattr = 'duedate', none = 'first') > > Which is of course a pretty trivial utility function to write. But I > understand your p

Re: [Python-Dev] Preview of 3.4 rc2 (so far) is up

On 19 Feb 2014 14:05, "Larry Hastings" wrote: > > > > The URL has changed slightly. Please go here: >> >> http://midwinter.com/~larry/3.4.status/ > > You'll notice two things: > a "merge.status.html" file, which shows you the list of revisions that I've cherry-picked after rc1. > a tarball contai

Re: [Python-Dev] Preview of 3.4 rc2 (so far) is up

On 19 February 2014 20:09, Georg Brandl wrote: > Am 19.02.2014 11:04, schrieb Nick Coghlan: >> >> On 19 Feb 2014 14:05, "Larry Hastings" > <mailto:la...@hastings.org>> wrote: >>> >>> The URL has changed slightly. Please go here: >>&

Re: [Python-Dev] Python 3.4: Cherry-picking into rc2 and final

On 20 Feb 2014 04:18, "Georg Brandl" wrote: > > Am 19.02.2014 19:00, schrieb Georg Brandl: > > Am 19.02.2014 16:50, schrieb Guido van Rossum: > >> On Wed, Feb 19, 2014 at 1:42 AM, Georg Brandl >> > wrote: > >> > >> Am 19.02.2014 00:54, schrieb Barry Warsaw: > >> >

Re: [Python-Dev] Preview of 3.4 rc2 (so far) is up

On 20 February 2014 10:31, Larry Hastings wrote: > On 02/19/2014 02:04 AM, Nick Coghlan wrote: > > The release is still about a month away. And yes I still plan to go through > the release blockers. Thanks. I confess I had missed that rc2 -> final was already 3 weeks rather t

Re: [Python-Dev] Python 3.4: Cherry-picking into rc2 and final

On 20 Feb 2014 12:26, "Ethan Furman" wrote: > > On 02/19/2014 05:24 PM, Stephen J. Turnbull wrote: >> >> >> The conflict here is not Larry's >> process, it's the decision to make an ambitious release on a short >> time schedule. I sympathize with Ubuntu to some extent -- they have a >> business t

Re: [Python-Dev] Python 3.4: What to do about the Derby patches

On 20 February 2014 16:42, Ronald Oussoren wrote: > > On 17 Feb 2014, at 00:43, Nick Coghlan wrote: > >> >> On 17 Feb 2014 08:36, "Greg Ewing" wrote: >> > >> > Larry Hastings wrote: >> > >> >> 3) We hold off on merging the r

Re: [Python-Dev] Python 3.4: Cherry-picking into rc2 and final

On 21 Feb 2014 08:38, "Matthias Klose" wrote: > > Am 19.02.2014 22:18, schrieb Nick Coghlan: > > and the Ubuntu 14.04 deadline restricts our ability to add a 3rd rc. > > well, I think it would be wrong to restrict that for only that reason. I did > object to delay

Re: [Python-Dev] PEP 463: Exception-catching expressions

to be consistent, but if we don't allow capturing, then we can dispense with the closure entirely. However, if we do that, we can't decide to add capturing later, because that would mean adding the closure, which would be potentially backwards incompatible with usage at class

Re: [Python-Dev] cherry pick a change to Enum

orner cases here before deciding how to proceed, and if we uncover any more after rc2, such a change would probably be a trigger for a 3rd release candidate (although that would ultimately be Larry's call as release manager). Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane

Re: [Python-Dev] PEP 463: Exception-catching expressions

... pass ... >>> e Traceback (most recent call last): File "", line 1, in NameError: name 'e' is not defined >>> e = "Hello" >>> try: ... pass ... except Exception as e: ... pass ... >>> e 'Hello' Cheers, Nick.

Re: [Python-Dev] PEP 463: Exception-catching expressions

On 21 February 2014 22:42, Chris Angelico wrote: > On Fri, Feb 21, 2014 at 10:35 PM, Nick Coghlan wrote: >> On 21 February 2014 13:15, Chris Angelico wrote: >>> PEP: 463 >>> Title: Exception-catching expressions >> Great work on this Chris - this is one of the

Re: [Python-Dev] PEP 463: Exception-catching expressions

to be mandatory as part of the deferral, or else multiple except clause support needs to be listed as rejected rather than deferred. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Pytho

Re: [Python-Dev] PEP 463: Exception-catching expressions

o for exception handling is both a bug magnet (due to overbroad exception handlers), and a cause of creeping complexity in API design (as more and more APIs, both in the standard library and elsewhere, acquire ways to request implicit exception handling). That's why the comparison to PEP 308 is

[Python-Dev] Tangent on class level scoping rules (was Re: PEP 463: Exception-catching expressions)

nt frame). As Chris later noted, you likely *could* still implement expression local name binding for an except expression without a full closure, it would just be rather difficult. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___

Re: [Python-Dev] PEP 463: Exception-catching expressions

r() is *defined*, for example). Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/m

Re: [Python-Dev] Tangent on class level scoping rules (was Re: PEP 463: Exception-catching expressions)

Sorry folks, that was meant to go to python-ideas, not python-dev. I've been so used to the PEP 463 threads being on python-ideas, I missed that this was the python-dev one :) Cheers, Nick. ___ Python-Dev mailing list Python-Dev@python.org https://mail.p

Re: [Python-Dev] PEP 463: Exception-catching expressions

he trap where "-1" is a valid subscript for the string (but doesn't give you the answer you want). Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org ht

Re: [Python-Dev] PEP 463: Exception-catching expressions

On 22 February 2014 00:59, Chris Angelico wrote: > On Sat, Feb 22, 2014 at 12:53 AM, Nick Coghlan wrote: >> The deferral currently has this snippet: >> >> """In order to ensure compatibility with future versions, ensure that >> any consecutive except op

Re: [Python-Dev] PEP 463: Exception-catching expressions

On 22 February 2014 00:50, Antoine Pitrou wrote: > On Sat, 22 Feb 2014 00:28:01 +1000 > Nick Coghlan wrote: >> >> Neither of these objections addresses the problems with the status quo, >> though: >> >> - the status quo encourages overbroad exception handli

Re: [Python-Dev] Tangent on class level scoping rules (was Re: PEP 463: Exception-catching expressions)

On 22 Feb 2014 09:59, "Greg Ewing" wrote: > > Nick Coghlan wrote: >> >> As Chris later noted, you likely *could* still implement expression >> local name binding for an except expression without a full closure, it >> would just be rather difficult. >

Re: [Python-Dev] PEP 463: Exception-catching expressions

On 22 Feb 2014 22:15, "Stephen J. Turnbull" wrote: > > Antoine Pitrou writes: > > On Sat, 22 Feb 2014 22:13:58 +1100 > > Chris Angelico wrote: > > > > hasattr(x,"y") <-> (x.y or True except AttributeError: False) > > > But it's not the same. hasattr() returns a boolean, not an arbitrary > >

Re: [Python-Dev] PEP 463: Exception-catching expressions

but higher than comma, so: > > A if C else B except E: D > > would be parsed as: > > (A if C else B) except E: D > > I think that's because it's kind of replacing: > > try: > _ = expr > except E: > _ = D > > with the try..except en

Re: [Python-Dev] PEP 461: Adding % formatting to bytes and bytearray -- Final, Take 2

b"%s" % (("%x" % val).encode("ascii")) The rationale for including them is the unreadability of the latter form :) Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing li

Re: [Python-Dev] PEP 461: Adding % formatting to bytes and bytearray -- Final, Take 2

tions > == > > It has been suggested to use ``%b`` for bytes as well as ``%s``. > > - Pro: clearly says 'this is bytes'; should be used for new code. > > - Con: does not exist in Python 2.x, so we would have two ways of doing > the > same th

Re: [Python-Dev] PEP 461: Adding % formatting to bytes and bytearray -- Final, Take 2

On 24 Feb 2014 07:39, "Antoine Pitrou" wrote: > > On Sun, 23 Feb 2014 12:42:59 -0800 > Ethan Furman wrote: > > On 02/23/2014 03:33 AM, Antoine Pitrou wrote: > > > On Sat, 22 Feb 2014 17:56:50 -0800 > > > Ethan Furman wrote: > > >> > > >> ``%a`` will call :func:``ascii()`` on the interpolated val

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