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

On 2/11/2016 8:22 PM, Andrew Barnert wrote: On Thursday, February 11, 2016 8:10 PM, Glenn Linderman wrote: On 2/11/2016 7:56 PM, David Mertz wrote: Great PEP overall. We definitely don't want the restriction to grouping numbers only in threes. South Asian crore use grouping in twos.

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

On 2/12/2016 12:06 PM, Chris Barker wrote: On Fri, Feb 12, 2016 at 1:00 AM, Paul Moore > wrote: I have no opinion on anything other than that whatever syntax is implemented as long as it allows single underscores between digits, such as 1_000_000

Re: [Python-Dev] PEP 515: Underscores in Numeric Literals (revision 3)

On 2/13/2016 12:48 AM, Georg Brandl wrote: Instead of the relatively strict rule specified above, the use of underscores could be limited. This sentence doesn't really make sense. Either s/limited/more limited/ or s/limited/further limited/ or s/limited/relaxed/ Maybe the whole section should

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

On 2/16/2016 1:48 AM, Christoph Groth wrote: Hello, Recent Python versions randomize the hashes of str, bytes and datetime objects. I suppose that the choice of these three types is the result of a compromise. Has this been discussed somewhere publicly? Search archives of this list... it w

Re: [Python-Dev] What does a double coding cookie mean?

On 3/15/2016 11:07 PM, Chris Angelico wrote: On Wed, Mar 16, 2016 at 5:03 PM, Serhiy Storchaka wrote: On 15.03.16 22:30, Guido van Rossum wrote: I came across a file that had two different coding cookies -- one on the first line and one on the second. CPython uses the first, but mypy happens t

Re: [Python-Dev] What does a double coding cookie mean?

On 3/16/2016 12:09 AM, Serhiy Storchaka wrote: On 16.03.16 08:34, Glenn Linderman wrote: From the PEP 263: More precisely, the first or second line must match the regular expression "coding[:=]\s*([-\w.]+)". The first group of this expression is then interpreted as encodin

Re: [Python-Dev] What does a double coding cookie mean?

On 3/16/2016 5:29 PM, Guido van Rossum wrote: I've updated the PEP. Please review. I decided not to update the Unicode howto (the thing is too obscure). Serhiy, you're probably in a better position to fix the code looking for cookies to pick the first one if there are two on the same line (or do

Re: [Python-Dev] What does a double coding cookie mean?

On 3/19/2016 8:19 AM, Serhiy Storchaka wrote: On 16.03.16 08:03, Serhiy Storchaka wrote: On 15.03.16 22:30, Guido van Rossum wrote: I came across a file that had two different coding cookies -- one on the first line and one on the second. CPython uses the first, but mypy happens to use the seco

Re: [Python-Dev] What does a double coding cookie mean?

On 3/19/2016 2:37 PM, Serhiy Storchaka wrote: On 19.03.16 19:36, Glenn Linderman wrote: On 3/19/2016 8:19 AM, Serhiy Storchaka wrote: On 16.03.16 08:03, Serhiy Storchaka wrote: I just tested with Emacs, and it looks that when specify different codings on two different lines, the first coding

Re: [Python-Dev] What does a double coding cookie mean?

On 3/16/2016 12:59 AM, Serhiy Storchaka wrote: On 16.03.16 09:46, Glenn Linderman wrote: On 3/16/2016 12:09 AM, Serhiy Storchaka wrote: On 16.03.16 08:34, Glenn Linderman wrote: From the PEP 263: More precisely, the first or second line must match the regular expression "coding[

Re: [Python-Dev] The next major Python version will be Python 8

On 3/31/2016 2:40 PM, Victor Stinner wrote: Hi, Python 3 becomes more and more popular and is close to a dangerous point where it can become popular that Python 2. The PSF decided that it's time to elaborate a new secret plan to ensure that Python users suffer again with a new major release brea

Re: [Python-Dev] Defining a path protocol

On 4/6/2016 4:44 PM, Ethan Furman wrote: On 04/06/2016 04:27 PM, Brett Cannon wrote: On Wed, 6 Apr 2016 at 15:54 Gregory P. Smithwrote: So would module.__path__ become a Path instance in a potential future making module.__path__.__path__ meaningfully confusing? ;) I'm not worried about people

Re: [Python-Dev] Pathlib enhancments - method name only

On 4/8/2016 11:25 AM, Brett Cannon wrote: I personally still like __ospath__ as well. +1. Because they aren't always files... but what else they might be is os dependent. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman

Re: [Python-Dev] Pathlib enhancments - method name only

On 4/8/2016 3:28 PM, Eric Snow wrote: All this matters because it impacts the value returned from __ospath__(). Should it return the string representation of the path for the current OS or some standardized representation? I'd expect the former. However, if that is the expectation then somethi

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

On 4/14/2016 3:33 PM, Victor Stinner wrote: When we will be able to get ride of the GIL for the dict type, we will probably be able to get an atomic "global_version++" for 64-bit integer. Right now, I don't think that an atomic int64++ is available on 32-bit archs. By the time we get an atomic in

Re: [Python-Dev] runtime dlls on Windows

On 5/26/2016 3:18 PM, Steve Dower wrote: This has been deprecated. It sounded like a great idea at the time (~8 years ago) but caused more problems than it solved. Somehow I missed the announcement of the deprecation. When I first heard of Windows manifests, though, my first reaction was that

Re: [Python-Dev] Adding NewType() to PEP 484

On 5/29/2016 9:57 AM, jon wrote: The aspects we want to capture in a name or adjective for these types are: a) The types have identical implementations or definitions. b) They are distinct types. I think “Distinguished Type” or”Cloned Type” best captures these qualities. I think the following

Re: [Python-Dev] Adding NewType() to PEP 484

On 5/31/2016 12:55 PM, rndblnch wrote: Guido van Rossum gmail.com> writes: Also -- the most important thing. What to call these things? We're pretty much settled on the semantics and how to create them (A = NewType('A', int)) but what should we call types like A when we're talking about them?

Re: [Python-Dev] Adding NewType() to PEP 484

On 5/31/2016 4:58 PM, Nick Coghlan wrote: On 31 May 2016 3:12 pm, "Glenn Linderman" <mailto:v%2bpyt...@g.nevcal.com>> wrote: > > On 5/31/2016 12:55 PM, rndblnch wrote: >> >> Guido van Rossum gmail.com <http://gmail.com>> writes: >> >

Re: [Python-Dev] cpython: Rename contextlib.ignored() to contextlib.ignore().

First, thanks for the education. What you wrote is extremely edifying about more than just context managers, and I really appreciate the visionary understanding you reported from BrisPy and further elucidated on, regarding the educational pattern of using things before you learn how they work..

Re: [Python-Dev] Context management patterns

On 10/18/2013 11:38 PM, Nick Coghlan wrote: However, that's a confusion about exception handling in general, not about the suppress context manager in particular. The same potential for conceptual confusion exists between: for name in ("somefile.tmp", "someotherfile.tmp"): try:

Re: [Python-Dev] pip SSL

On 10/19/2013 12:46 PM, Ian Cordasco wrote: Also the three of us maintaining requests and the author of urllib3 are all very conscious that the packaged pem file is outdated. We have an open issue about how to rebuild it accurately while taking into consideration (and not including) the ones that

Re: [Python-Dev] [Python-checkins] cpython: Fiddled Thread.join() to be a little simpler. Kinda ; -)

On 10/26/2013 8:42 AM, Tim Peters wrote: Read "then" as an abbreviation of "in that case"? In that case, then, "then" is a very poor abbreviation of "in that case", and is unlikely to be interpreted with that expansion by many readers. ___ Python-Dev

Re: [Python-Dev] The pysandbox project is broken

On 11/12/2013 4:11 PM, Steven D'Aprano wrote: On Wed, Nov 13, 2013 at 12:58:42AM +0100, Victor Stinner wrote: >I now gave up on sandboxing Python. I just would like to warn other >core developers that trying to put a sandbox in Python is not a good >idea:-) Do you mean CPython? Do you think i

Re: [Python-Dev] PEP 0404 and VS 2010

On 11/21/2013 12:23 PM, Christian Tismer wrote: Maybe I would generate a cpython and spython exe and support them both in the same distribution? That sounds cool, if possible. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/m

Re: [Python-Dev] potential argparse problem: bad mix of parse_known_args and prefix matching

Eli did give his use case... a front end for a program that has a parameter "--sync", and a front end preprocessor of some sort was trying to use "--sync-foo" as an argument, and wanted "--sync" to be left in the parameters to send on to the back end program. Design of the front-end might bett

Re: [Python-Dev] py.ini documentation improvement

On 11/28/2013 1:04 PM, Tim Delaney wrote: %LOCALAPPDATA% should always contain the same value as would be returned from SHGetFolderPath with CSIDL_LOCAL_APPDATA. Except when it gets changed. Documentation should reflect the actual use in the code. If it uses the SHGetFolderPath, that is what s

Re: [Python-Dev] RFC: PEP 460: Add bytes % args and bytes.format(args) to Python 3.5

On 1/11/2014 1:44 AM, Stephen Hansen wrote: There's been a number of examples given: PDF, HTTP, network streams that switch inline from text-ish to binary and back-again.. But, we can focus that down to a very narrow and not at all uncommon situation in the latter. PDF has been mentioned a fe

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

On 1/11/2014 1:50 PM, Ethan Furman wrote: Perhaps that's the problem. According to the docs: object.__bytes__(self) Called by bytes() to compute a byte-string representation of an object. This should return a bytes o

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

On 1/12/2014 11:14 AM, Ethan Furman wrote: And a core principle of the bytes/text separation in Python 3 is that encoding should never happen implicitly. That could be. And yet the bytes type already has several concessions to ASCII encoding. "%d" % 26 => an explicit request to convert bina

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

On 1/12/2014 2:57 PM, Stephen J. Turnbull wrote: > But bytes already acknowledges an ASCII bias. True, but that bias is implemented without use of encoding or decoding. b'%d' % (123,) -> b'123' does require encoding, at the very least in the sense of type change and serialization. b'%d' all

Re: [Python-Dev] PEP 460 reboot

On 1/12/2014 6:11 PM, Guido van Rossum wrote: On Sun, Jan 12, 2014 at 5:27 PM, Ethan Furman wrote: >On 01/12/2014 04:47 PM, Guido van Rossum wrote: >>%s seems the trickiest: I think with a bytes argument it should just >>insert those bytes (and the padding modifiers should work too), and >>for

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

On 1/12/2014 8:00 PM, Ethan Furman wrote: Okay, I've thought somewhat. Under the definition above would it be fair to say that Db3Table (a class in my dbf module) is a boundary type? It sits between the actual file and the program, and transforms bytes into actual Python types. Yes. Tha

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

On 1/12/2014 4:08 PM, Stephen J. Turnbull wrote: Glenn Linderman writes: > the proposals to embed binary in Unicode by abusing Latin-1 > encoding. Those aren't "proposals", they are currently feasible techniques in Python 3 for *some* use cases. The question is why in

Re: [Python-Dev] PEP 460 reboot

On 1/13/2014 12:46 AM, Mark Shannon wrote: On 13/01/14 03:47, Guido van Rossum wrote: On Sun, Jan 12, 2014 at 6:24 PM, Ethan Furman wrote: On 01/12/2014 06:16 PM, Ethan Furman wrote: If you do : --> b'%s' % 'some text' Ignore what I previously said. With no encoding the result would be

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

On 1/13/2014 6:43 AM, Stephen J. Turnbull wrote: Glenn Linderman writes: > On 1/12/2014 4:08 PM, Stephen J. Turnbull wrote: >> Glenn Linderman writes: >>> the proposals to embed binary in Unicode by abusing Latin-1 >>> encoding. >> Those aren&

Re: [Python-Dev] PEP 460 reboot

On 1/13/2014 1:49 AM, Mark Shannon wrote: So why not replace '%s' with '%a' for the ascii case and with '%b' for directly inserting bytes. Because %a and %b don't exist in Python 2.7? I thought this was about 3.5, not 2.7 ;) '%s' can't work in 3.5, as we must differentiate between strings whi

Re: [Python-Dev] PEP 460 reboot and a bitter fight

On 1/13/2014 5:06 AM, Nick Coghlan wrote: I figured out tonight that it's only positioning ASCII interpolation as an*alternative* to adding binary interpolation that I have a problem with. It isn't, because you lose the structural assurance that you haven't inadvertently introduced an assumption

Re: [Python-Dev] PEP 460 reboot

On 1/13/2014 10:40 AM, Brett Cannon wrote: This even gives people in-place ASCII encoding for strings by always using '{:s}' with text which they can do when they port their code to run under both Python 2 and 3. So you should be able to do ``b'Content-Type: {:s}'.format('image/jpeg')`` and hav

Re: [Python-Dev] PEP 460 reboot

On 1/13/2014 9:38 AM, Ethan Furman wrote: On 01/13/2014 09:31 AM, Antoine Pitrou wrote: On Mon, 13 Jan 2014 08:36:05 -0800 Ethan Furman wrote: You mean crash all the time? I'd be fine with that for both the str case and the bytes case. But's probably too late to change the str case, and th

Re: [Python-Dev] PEP 460 reboot

On 1/13/2014 12:09 PM, Guido van Rossum wrote: Yeah, the %s behavior with a string argument was a messy attempt at compromise. I was hoping to mimick a common use of %s in Python 2, where it can be used with either an 8-bit string or a number as argument, acting like %b in the former case and lik

Re: [Python-Dev] PEP 460 reboot

On 1/13/2014 1:59 PM, Guido van Rossum wrote: On Mon, Jan 13, 2014 at 1:29 PM, Glenn Linderman wrote: On 1/13/2014 12:09 PM, Guido van Rossum wrote: Yeah, the %s behavior with a string argument was a messy attempt at compromise. I was hoping to mimick a common use of %s in Python 2, where it

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

On 1/13/2014 9:06 PM, Guido van Rossum wrote: Sorry to butt in, but can you post a link to the asciistr code? Google has too many hits for other things to be useful to find it, it seems. https://github.com/jeamland/asciicompat ___ Python-Dev mailing l

Re: [Python-Dev] PEP 460 reboot

On 1/13/2014 9:03 PM, Guido van Rossum wrote: Of course, nobody in their right mind would use a format string containing UTF-16 or EBCDIC. And that is precisely my point. When you're using a format string, all of the format string (not just the part between { and }) had better use ASCII or an ASC

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

On 1/13/2014 8:58 PM, Stephen J. Turnbull wrote: Glenn Linderman writes: > On 1/13/2014 6:43 AM, Stephen J. Turnbull wrote: >> Glenn Linderman writes: >>> "smuggled binary" (great term borrowed from a different >>> subthread) muddies the waters of

Re: [Python-Dev] PEP 460 reboot

On 1/13/2014 9:25 PM, Nick Coghlan wrote: since this observation makes it clear that there's*no* coherent way to offer a pure binary interpolation API - the only general purpose combination mechanism for segments of binary data that can avoid making assumptions about the encodings of metacharact

Re: [Python-Dev] PEP 460 reboot

On 1/14/2014 4:46 AM, Nick Coghlan wrote: The one remaining way I could potentially see a formatb method working is along the lines of what Glenn (I think) suggested: just like struct definitions, the formatb specifier would have to consist*solely* of substitution fields. However, that's getting

Re: [Python-Dev] PEP 460 reboot

On 1/14/2014 10:11 AM, Jim J. Jewett wrote: Virtual subclass ASCIIStructuredBytes You would first have to define what you meant by a virtual subclass, and that somewhere would have to be linked every place you use the term, because it is a new term. Why not just call the sections of the doc

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

On 1/14/2014 2:38 PM, Nick Coghlan wrote: I think Brett has the right idea: we shouldn't try to accept numbers for %s in binary interpolation. If we limit it to just buffer exporters and objects with a __bytes__ method then the problem goes away. The numeric codes all exist in Python 2, so t

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

On 1/15/2014 7:52 AM, Eric V. Smith wrote: So basically I think we'll have to hard-code the types that .format() will support, and never call __format__, or only call __format__ if we know that it's a exact type where we know that __format__ will return (strict ASCII). Either that, or we're back

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

On 1/15/2014 4:03 PM, Steven D'Aprano wrote: What precisely does it do? If it's so obvious, why is this thread so long? It produces a formatted representation of the object in bytes. For numbers, that would probably be expected to be ASCII digits and punctuation. But other items are not as

Re: [Python-Dev] PEP 461 updates

On 1/15/2014 4:13 PM, Ethan Furman wrote: - no value generated errors ... %c will insert a single byte, either from an int in range(256), or from a bytes argument of length 1. what does x = 354 b"%c" % x produce? Seems that construct produces a value dependent error in both python 2 &

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

On 1/16/2014 8:41 AM, Brett Cannon wrote: That's a very good catch, Michael! I think that makes sense if there is precedence. Unfortunately that bit from the PEP never made it into the documentation so I'm not sure if there is a backwards-compatibility worry. No. If __format__ is called with

Re: [Python-Dev] PEP 461 updates

On 1/16/2014 9:46 PM, Nick Coghlan wrote: On 17 January 2014 11:51, Ethan Furman wrote: On 01/16/2014 05:32 PM, Greg wrote: I don't think it matters whether the internal details of that debate make sense to the rest of us. The main thing is that a consensus seems to have been reached on bytes

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

On 1/17/2014 6:50 AM, Eric V. Smith wrote: Following up, I think this leaves us with 3 choices: 1. Do not implement bytes.format(). We tell any 2.x code that's written to use str.format() to switch to %-formatting for their common code base. 2. Add the simplistic version of bytes.format() that

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

On 1/17/2014 7: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, they now have to change the code back to the way they may well have written it in the first place?

Re: [Python-Dev] PEP 461 Final?

On 1/17/2014 8:49 AM, Ethan Furman wrote: %s is restricted in what it will accept:: - input type supports Py_buffer? use it to collect the necessary bytes - input type is something else? use its __bytes__ method; if there isn't one, raise a TypeError Examples: >>> b'%s' % b'ab

Re: [Python-Dev] Migration from Python 2.7 and bytes formatting

On 1/17/2014 2:49 AM, Neil Schemenauer wrote: As I see it, there are two separate goals in adding formatting methods to bytes. One is to make it easier to write new programs that manipulate byte data. Another is to make it easier to upgrade Python 2.x programs to Python 3.x. Here is an idea to

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

On 2/18/2014 7:57 AM, Brett Cannon wrote: Yes, I see your point, but please also consider that None is used in database applications as natural mapping for SQL NULL and in other data processing applications to mean "no value". Fine, but not everything uses a database. =) Python N

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

On 2/18/2014 1:27 PM, Greg Ewing wrote: M.-A. Lemburg wrote: The alternative would be adding a new singleton to mean mostly the same thing as None, but having the property of comparing less than all other objects and then recommend its use in the DB-API for Python 3 applications... Which I thi

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

On 2/19/2014 2:53 AM, Lennart Regebro wrote: On Tue, Feb 18, 2014 at 5:10 PM, Mark Lawrence wrote: Sorry if this has already been suggested, but why not introduce a new singleton to make the database people happier if not happy? To avoid confusion call it dbnull? A reasonable compromise or co

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

On 2/21/2014 3:29 PM, Greg Ewing wrote: Antoine Pitrou wrote: lst = [1, 2] value = lst[2] except IndexError: "No value" the gain in concision is counterbalanced by a loss in readability, This version might be more readable: value = lst[2] except "No value" if IndexError since it

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

On 2/21/2014 5:06 PM, Jan Kaliszewski wrote: Or even (still being my favorite): msg = seq[i] except (IndexError: "nothing") This syntax actually has a benefit: the parenthesized syntax after except could become a list, to allow handling different exceptions from the tried expression wit

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

On 2/21/2014 7:57 PM, Chris Angelico wrote: On Sat, Feb 22, 2014 at 12:10 PM, Glenn Linderman wrote: Here's a challenge: There has been a big thread about None versus (SQL) Null. Show how an except: expression can help the DB API more easily convert from using None to using a new

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

On 2/23/2014 1:37 PM, Antoine Pitrou wrote: And you certainly*don't* print debugging output into a wire protocol. Web server applications do, so they can be displayed in the browser. ___ Python-Dev mailing list Python-Dev@python.org https://mail.pyth

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

On 2/23/2014 2:25 PM, Antoine Pitrou wrote: On Sun, 23 Feb 2014 14:14:55 -0800 Glenn Linderman wrote: On 2/23/2014 1:37 PM, Antoine Pitrou wrote: And you certainly*don't* print debugging output into a wire protocol. Web server applications do, so they can be displayed in the browser.

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

On 2/24/2014 10:40 AM, Ethan Furman wrote: Somebody might, and it's better than having them inappropriately add a __bytes__ method if we don't have it. I'll admit my first thought on reading the initial discussions about adding bytes % formatting was "Oh, if I want to display custom objects

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

On 2/27/2014 4:57 AM, Nick Coghlan wrote: The way I get the colon in the proposed syntax to make sense to my brain is to view it as being more like the colon in a dictionary key:value pair than it is like the one that introduces a suite or the body of a lambda expression: (lst[2] except {In

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

On 2/27/2014 3:40 PM, Chris Angelico wrote: On Fri, Feb 28, 2014 at 10:33 AM, Nick Coghlan wrote: On 28 Feb 2014 05:56, "Chris Angelico" wrote: On Fri, Feb 28, 2014 at 6:36 AM, Glenn Linderman wrote: +1 f() except ((TypeError, AttributeError): "No value") is a n

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

On 2/27/2014 7:46 PM, Chris Angelico wrote: On Fri, Feb 28, 2014 at 1:12 PM, Glenn Linderman wrote: Yes. But the point is really the location of the (), sorry if my "nice extension" comment is throwing you off that track. Ah! I see. We touched on this syntax on -ideas, but at the

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

On 2/28/2014 12:41 AM, Chris Angelico wrote: On Fri, Feb 28, 2014 at 6:38 PM, Glenn Linderman wrote: Whereas the current PEP syntax has ambiguity regarding how to interpret a-expr except except-list-b: b-expr except except-list-c: c-expr (does the 2nd except apply to a-expr or b-expr

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

On 2/28/2014 4:51 AM, Nick Coghlan wrote: The preferred notation in the PEP most resembles the existing lambda use case, with "except" instead of "lambda", an exception handling spec instead of an argument list and an additional leading expression: (expr except Exception: default) Lots of

Re: [Python-Dev] What is the precise problem? [was: Reference cycles in Exception.__traceback__]

On 3/7/2014 1:25 PM, Ethan Furman wrote: On 03/07/2014 01:20 PM, Jim J. Jewett wrote: (E) Exceptions are not released even during cyclic gc, because of ambiguity over which __del__ to run first. + This may be like case B or case E Um, this is case E. ;) Yeah, quite a bit like case E :) _

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

On 3/27/2014 11:59 AM, Guido van Rossum wrote: On Thu, Mar 27, 2014 at 11:52 AM, Daniel Holth > wrote: I feel not including %s is nuts. Should I write .replace('%b', '%s')? I assume you meant .replace('%s', '%b') (unless you're converting Python 3 code to Python 2

Re: [Python-Dev] Status of PEP 3145 - Asynchronous I/O for subprocess.popen

On 3/28/2014 11:35 AM, Josiah Carlson wrote: If it were me, I'd define three methods, with longer names to clarify what they do, e.g. proc.write_nonblocking(data) data = proc.read_nonblocking() data = proc.read_stderr_nonblocking() Easily doable. I'd appreciate being not

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

On 3/29/2014 12:01 PM, Gregory P. Smith wrote: From a 2.x-3.x compatible code standpoint the above could exist but the container class constructor would be a no-op on Python 2. if sys.version_info[0] == 2: BytesFormatter = str else: class BytesFormatter: ... def __mod__ ... If done

Re: [Python-Dev] Python 4?

On 4/3/2014 4:02 PM, Emile van Sebille wrote: Can't we just refer to PySky and leave it at that? Hey! That's an excellent idea! And it avoids the version number prediction/expectation too. ___ Python-Dev mailing list Python-Dev@python.org https://m

Re: [Python-Dev] this is what happens if you freeze all the modules required for startup

On 4/14/2014 2:51 PM, Brett Cannon wrote: consider freezing all the modules ... Now the question is whether the maintenance cost of having to rebuild Python for a select number of stdlib modules "all" versus "select number". So I'm guessing the proposal is to freeze all the modules that Pyth

Re: [Python-Dev] this is what happens if you freeze all the modules required for startup

On 4/14/2014 2:51 PM, Brett Cannon wrote: Freezing everything except encodings.__init__, os, and _sysconfigdata, I suppose these are omitted because they can vary in different environments? But isn't Python built for a particular environment... seems like os could be included? Seems like it

Re: [Python-Dev] pep8 reasoning

On 4/24/2014 11:01 AM, Daniel Holth wrote: Fortunately, Unicode provides us with the COMBINING LOW LINE character, combining the horizontal space-savings of camelCase with the underscore-indicates-separation properties of _. And it's a valid Python identifier. convertx̲mlt̲oj̲son That should b

Re: [Python-Dev] Python 2.7.7. on Windows

On 4/28/2014 8:52 PM, Steven D'Aprano wrote: I think that's unfair. I'm not a MS fan, not even close. I think their business practices in the past have been reprehensible. But if there is anyone who takes backwards-compatibility even more seriously than Python-Dev, it is them. I guess there is no

Re: [Python-Dev] %x formatting of floats - behaviour change since 3.4

On 6/3/2014 3:05 PM, Chris Angelico wrote: On Wed, Jun 4, 2014 at 8:03 AM, Victor Stinner wrote: 2014-06-03 23:38 GMT+02:00 Chris Angelico : Is this an intentional change? And if so, is it formally documented somewhere? I don't recall seeing anything about it, but my recollection doesn't mean

Re: [Python-Dev] Internal representation of strings and Micropython

On 6/4/2014 6:14 AM, Steve Dower wrote: I'm agree with Daniel. Directly indexing into text suggests an attempted optimization that is likely to be incorrect for a set of strings. Splitting, regex, concatenation and formatting are really the main operations that matter, and MicroPython can optim

Re: [Python-Dev] Internal representation of strings and Micropython

On 6/4/2014 2:28 PM, Chris Angelico wrote: On Thu, Jun 5, 2014 at 6:50 AM, Glenn Linderman wrote: 8) (Content specific variable size caches) Index each codepoint that is a different byte size than the previous codepoint, allowing indexing to be used in the intervals. Worst case size is like 2

Re: [Python-Dev] Internal representation of strings and Micropython

On 6/4/2014 5:03 PM, Greg Ewing wrote: Serhiy Storchaka wrote: html.HTMLParser, json.JSONDecoder, re.compile, tokenize.tokenize don't use iterators. They use indices, str.find and/or regular expressions. Common use case is quickly find substring starting from current position using str.find or

Re: [Python-Dev] Internal representation of strings and Micropython

On 6/4/2014 5:08 PM, Glenn Linderman wrote: On 6/4/2014 5:03 PM, Greg Ewing wrote: Serhiy Storchaka wrote: html.HTMLParser, json.JSONDecoder, re.compile, tokenize.tokenize don't use iterators. They use indices, str.find and/or regular expressions. Common use case is quickly find subs

Re: [Python-Dev] Internal representation of strings and Micropython

On 6/5/2014 3:10 AM, Paul Sokolovsky wrote: Hello, On Wed, 04 Jun 2014 22:15:30 -0400 Terry Reedy wrote: think you are again batting at a strawman. If you mean 'read from a file', and all you want to do is read bytes from and write bytes to external 'files', then there is obviously no need to

Re: [Python-Dev] Internal representation of strings and Micropython

On 6/5/2014 11:41 AM, Daniel Holth wrote: discover new things like dance-encoded strings, bytes decoded using an incorrect encoding intended to be transcoded into the correct encoding later, surrogates that work perfectly until .encode(), str(bytes), APIs that disagree with you about whether the

Re: [Python-Dev] namedtuple implementation grumble

On 6/7/2014 7:50 AM, Antoine Pitrou wrote: Le 07/06/2014 09:25, R. David Murray a écrit : On Fri, 06 Jun 2014 19:50:57 +0100, Chris Withers wrote: I guess I could duck-type it based on the _fields attribute but that feels implicit and fragile. What do you guys suggest? I seem to remember a

Re: [Python-Dev] Naming comprehension syntax [was Re: Informal educator feedback on PEP 572 ...]

On 7/6/2018 11:20 AM, Brett Cannon wrote: On Fri, 6 Jul 2018 at 08:52 Chris Barker - NOAA Federal via Python-Dev mailto:python-dev@python.org>> wrote: Are we just having fun here? Or might we actually start using a new naming convention for the-syntax-formerly-known-as-generator

Re: [Python-Dev] Naming comprehension syntax [was Re: Informal educator feedback on PEP 572 ...]

On 7/6/2018 9:01 PM, Terry Reedy wrote: In any case, Python's comprehensions use an English-syntax version of extended set builder notation.  "In Python, the set-builder's braces are replaced with square brackets, parentheses, or curly braces, giving list, generator, and set objects, respective

Re: [Python-Dev] PEP 572: Assignment Expressions -- intention to accept, near-final draft

On 7/9/2018 6:00 PM, Guido van Rossum wrote: This rule is included to simplify the choice for the user between an   assignment statements and an assignment expression -- there is no "statements" should not be plural in the above line. syntactic position where both are valid. An exception

Re: [Python-Dev] PEP 572: Assignment Expressions -- intention to accept, near-final draft

On 7/9/2018 8:43 PM, Guido van Rossum wrote: An exception to this special case applies when the target name is the same as a loop control variable for a comprehension containing it. This is invalid.  This exception exists to rule out edge cases of the above scope rules as illust

Re: [Python-Dev] why is not 64-bit installer the default download link for Windows?

On 7/10/2018 11:14 PM, Stephen J. Turnbull wrote: Ivan Pozdeev via Python-Dev writes: > "One or more issues caused the setup to fail. Please fix the issues and > the retry setup. For more information see the log file . > > 0x80070661 - This installation package is not supported by this

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

On 10/9/2018 7:46 PM, Chris Jerdonek wrote: On Tue, Oct 9, 2018 at 7:13 PM Benjamin Peterson wrote: On Tue, Oct 9, 2018, at 17:14, Barry Warsaw wrote: On Oct 9, 2018, at 16:21, Steven D'Aprano wrote: On Tue, Oct 09, 2018 at 10:26:50AM -0700, Guido van Rossum wrote: My feeling is that limiti

Re: [Python-Dev] Standardize error message for non-pickleable types

On 10/29/2018 12:51 PM, Victor Stinner wrote: Le lun. 29 oct. 2018 à 20:42, Serhiy Storchaka a écrit : 1. "pickle" or "serialize"? serialize 2. "can't", "Cannot", "can not" or "cannot"? cannot 3. "object" or "objects"? object 4. Use the "a" article or not? no: "cannot serialize xxx ob

Re: [Python-Dev] short-circuiting runtime errors/exceptions in python debugger.

On 10/29/2018 3:07 PM, Greg Ewing wrote: When I have a bug that only happens after hours of run time, I try to find a much shorter test case that reproduces it. Mmm. Yeah.  But that's often a guessing game, with a low chance of success. ___ Python-Dev

Re: [Python-Dev] Standardize error message for non-pickleable types

On 10/30/2018 1:12 AM, Serhiy Storchaka wrote: 29.10.18 23:17, MRAB пише: 1. If you're pickling, then saying "pickle" is more helpful. 2. In English the usual long form is "cannot". Error messages tend to avoid abbreviations, and also tend to have lowercase after the colon, e.g.: "Zero

Re: [Python-Dev] Need discussion for a PR about memory and objects

On 11/19/2018 4:14 PM, Chris Barker via Python-Dev wrote: On Mon, Nov 19, 2018 at 1:41 AM Antoine Pitrou > wrote: I'd rather keep the reference to memory addressing than start doing car analogies in the reference documentation. I agree -- and any of the

Re: [Python-Dev] Experiment an opt-in new C API for Python? (leave current API unchanged)

On 11/20/2018 2:17 PM, Victor Stinner wrote: Le mar. 20 nov. 2018 à 23:08, Stefan Krah a écrit : Intuitively, it should probably not be part of a limited API, but I never quite understood the purpose of this API, because I regularly need any function that I can get my hands on. (...) Reading ty

<    1   2   3   4   5   6   7   >