Re: [Python-Dev] One-line abstractmethod function?

On Fri, Dec 06, 2013 at 07:28:57AM +0100, Gregory Salvan wrote: > Hi, > maybe a syntax like that can correspond: > > class MyObject(metaclass=ObjectSpec): > ''' MyObject doc''' > 'attr1 contains something' > attr1 = None > 'attr2 contains something' > attr2 = str > 'method1

Re: [Python-Dev] How long the wrong type of argument should we limit (or not) in the error message (C-api)?

On Sun, Dec 15, 2013 at 11:25:10AM +1000, Nick Coghlan wrote: > Oh, yes, a %T shortcut for "length limited type name of the supplied > object" would be brilliant. We need this frequently for C level error > messages, and I almost always have to look at an existing example to > remember the exact i

Re: [Python-Dev] How long the wrong type of argument should we limit (or not) in the error message (C-api)?

On Mon, Dec 16, 2013 at 07:30:56AM +1000, Nick Coghlan wrote: > On 16 Dec 2013 02:58, "Ethan Furman" wrote: > > > > On 12/14/2013 07:51 PM, Steven D'Aprano wrote: > >> > >> On Sun, Dec 15, 2013 at 11:25:10AM +1000, Nick Coghlan wrote: > >&

Re: [Python-Dev] Fwd: Python 2.x and 3.x usage survey

On Tue, Dec 31, 2013 at 08:16:33AM +0100, Lennart Regebro wrote: > On Tue, Dec 31, 2013 at 6:31 AM, Dan Stromberg wrote: > > So far the results are looking good for 3.x. > > Python-dev probably is a bit special. Why? Most Python-Dev people have day jobs, and the version of Python that they use

Re: [Python-Dev] Python3 "complexity"

On Thu, Jan 09, 2014 at 05:11:06PM +1000, Nick Coghlan wrote: > On 9 January 2014 10:07, Ben Finney wrote: > > So, if what you want is to parse text and not get gibberish, you need to > > *tell* Python what the encoding is. That's a brute fact of the world of > > text in computing. > > Set the m

Re: [Python-Dev] Python3 "complexity"

On Thu, Jan 09, 2014 at 01:00:59PM +, Kristján Valur Jónsson wrote: > Which reminds me, can Python3 read text files with BOM automatically yet? I'm not sure what you mean by that. If you mean, can Python3 distinguish between UTF-16BE and UTF-16LE on the basis of a BOM, then it's been able t

Re: [Python-Dev] Python3 "complexity"

On Thu, Jan 09, 2014 at 02:08:57PM -0800, Ethan Furman wrote: > If latin1 is used to convert binary to text, how convoluted is it to then > take chunks of that text and convert to int, or some other variety of > unicode? > > For example: b'\x01\x00\xd1\x80\xd1\83\xd0\x80' > > If that were dec

Re: [Python-Dev] Python3 "complexity"

On Fri, Jan 10, 2014 at 12:22:02PM +1100, Chris Angelico wrote: > On Fri, Jan 10, 2014 at 11:53 AM, anatoly techtonik > wrote: > > 2. introduce autodetect mode to open functions > > 1. read and transform on the fly, maintaining a buffer that > > stores original bytes > > and their

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

On Fri, Jan 10, 2014 at 06:17:02PM +0100, Juraj Sukop wrote: > As you may know, PDF operates over bytes and an integer or floating-point > number is written down as-is, for example "100" or "1.23". I'm sorry, I don't understand what you mean here. I'm honestly not trying to be difficult, but you

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

On Sat, Jan 11, 2014 at 01:56:56PM +0100, Juraj Sukop wrote: > On Sat, Jan 11, 2014 at 6:36 AM, Steven D'Aprano wrote: > > If you consider PDF as binary with occasional pieces of ASCII text, then > > working with bytes makes sense. But I wonder whether it might be better &g

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

On Sat, Jan 11, 2014 at 08:20:27AM -0800, Ethan Furman wrote: > On 01/11/2014 07:38 AM, Steven D'Aprano wrote: > > > >The point that I am making is that many people want to add formatting > >operations to bytes so they can put ASCII strings inside bytes. But (as > &

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

On Sat, Jan 11, 2014 at 04:15:35PM +0100, M.-A. Lemburg wrote: > I think we need to step back a little from the purist view > of things and give more emphasis on the "practicality beats > purity" Zen. > > I complete agree with Stephen, that bytes are in fact often > an encoding of text. If that t

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

On Sat, Jan 11, 2014 at 05:33:17PM +0100, M.-A. Lemburg wrote: > FWIW: I quite liked the Python 2 model, but perhaps that's because > I already knww how Unicode works, so could use it to make my > life easier ;-) /incredulous I would really love to see you justify that claim. How do you use the

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

On Sat, Jan 11, 2014 at 07:22:30PM +, MRAB wrote: > >with open("outfile.pdf", "w", encoding="latin-1") as f: > > f.write(pdf) > > > [snip] > The second example won't work because you're forgetting about the > handling of line endings in text mode. So I did! Thank you for the correction.

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

On Sat, Jan 11, 2014 at 04:28:34PM -0500, Terry Reedy wrote: > The problem with some criticisms of using 'unicode in Python 3' is that > there really is no such thing. Unicode in 3.0 to 3.2 used the old > internal model inherited from 2.x. Unicode in 3.3+ uses a different > internal model that

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

On Sat, Jan 11, 2014 at 08:13:39PM -0200, Mariano Reingart wrote: > AFAIK (and just for the record), there could be both Latin1 text and UTF-16 > in a PDF (and other encodings too), depending on the font used: [...] > In Python2, txt is just a str, but in Python3 handling everything as latin1 > st

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

On Sat, Jan 11, 2014 at 11:05:36AM -0800, Ethan Furman wrote: > On 01/11/2014 10:36 AM, Steven D'Aprano wrote: > >On Sat, Jan 11, 2014 at 08:20:27AM -0800, Ethan Furman wrote: > >> > >> unicode to bytes > >> bytes to unicode using latin1 > >&g

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

On Sun, Jan 12, 2014 at 12:52:18PM +0100, Juraj Sukop wrote: > On Sun, Jan 12, 2014 at 2:35 AM, Steven D'Aprano wrote: > > > On Sat, Jan 11, 2014 at 08:13:39PM -0200, Mariano Reingart wrote: > > > > > AFAIK (and just for the record), there could be both Latin1 te

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

On Sun, Jan 12, 2014 at 11:16:37PM +1000, Nick Coghlan wrote: > > content = '\n'.join([ > > 'header', > > 'part 2 %.3f' % number, > > binary_image_data.decode('latin-1'), > > utf16_string.encode('utf-16be').decode('latin-1'), > > 'trailer']).encode('lati

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

On Mon, Jan 13, 2014 at 07:31:16AM +0900, Stephen J. Turnbull wrote: > Steven D'Aprano writes: > > > then the name is horribly misleading, and it is best handled like this: > > > > content = '\n'.join([ > >

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

0, Ethan Furman wrote: > On 01/11/2014 06:29 PM, Steven D'Aprano wrote: [...] > Since you're talking to me, it would be nice if you addressed the same > use-case I was addressing, which is mixed: ascii-encoded text, > ascii-encoded numbers, ascii-encoded bools, binary-encoded

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

On Mon, Jan 13, 2014 at 01:03:15PM +1100, Steven D'Aprano wrote: > code speaks louder than words: http://www.pearwood.info/ethan_demo.py [...] Ethan refers to code like: template % ("срЃ".encode('cp1251').decode('latin-1'), 42, blob.decode('latin-1&#

Re: [Python-Dev] Automatic encoding detection [was: Re: Python3 "complexity" - 2 use cases]

On Mon, Jan 13, 2014 at 07:58:43PM -0500, Terry Reedy wrote: > This discussion strikes me as more appropriate for python-ideas. That > said, I am leery of a heuristics module in the stdlib. When is a change > a 'bug fix'? and when is it an 'enhancement'? Depends on the nature of the heuristic.

Re: [Python-Dev] magic method __bytes__

On Tue, Jan 14, 2014 at 10:58:49AM -0500, R. David Murray wrote: > On Mon, 13 Jan 2014 17:38:38 -0800, Ethan Furman wrote: > > Has anyone actually used __bytes__ yet? What for? > > bytes(email.message.Message()) returns the message object serialized to > "wire format". > > --David > > PS: I've

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

On Tue, Jan 14, 2014 at 10:16:17AM -0800, Guido van Rossum wrote: > Hm. It is beginning to sound more and more flawed. I also worry that > it will bring back the nightmare of data-dependent UnicodeError back. > E.g. this (from tests/basic.py): > > def test_asciistr_will_not_accept_codepoints_

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

On Wed, Jan 15, 2014 at 01:03:13PM +1300, Greg Ewing wrote: > Nick Coghlan wrote: > >That way lies the Python 2 text model, and we're not going there. It's > >probably best to think of asciistr as a way of demonstrating a > >rhetorical point about the superiority of the Python 3 text model > >

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

On Thu, Jan 16, 2014 at 10:55:31AM +1300, Greg Ewing wrote: > Neil Schemenauer wrote: > >Objects that implement __str__ can also implement __bytes__ if they > >can guarantee that ASCII characters are always returned, > > I think __ascii_ would be a better name. I'd expect > a method called __bytes

Re: [Python-Dev] Common subset of python 2 and python 3

On Wed, Jan 15, 2014 at 09:25:04AM -0500, Eric V. Smith wrote: > On 1/15/2014 8:21 AM, Chris Angelico wrote: > > On Wed, Jan 15, 2014 at 11:22 PM, "Martin v. Löwis" > > wrote: > >> I don't think that it is possible to write an interpreter that is fully > >> compatible for all it accepts. Would yo

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

On Wed, Jan 15, 2014 at 10:34:48PM +, Mark Lawrence wrote: > On 15/01/2014 22:22, Brett Cannon wrote: > > > > > > > >On Wed, Jan 15, 2014 at 5:00 PM, Steven D'Aprano ><mailto:st...@pearwood.info>> wrote: > > > >On Thu, Jan 16, 20

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

On Wed, Jan 15, 2014 at 05:46:07PM -0800, Glenn Linderman wrote: > 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

Re: [Python-Dev] PEP 461 updates

On Fri, Jan 17, 2014 at 11:19:44AM +0900, Stephen J. Turnbull wrote: > Meta enough that I'll take Guido out of the CC. > > Nick Coghlan writes: > > > There are plenty of data formats (like SMTP and HTTP) that are > > constrained to be ASCII compatible, > > "ASCII compatible" is a technical ter

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

On Thu, Jan 16, 2014 at 08:23:13AM -0800, Ethan Furman wrote: > As I understand it, str.format will call the object's __format__. So, for > example, if I say: > > u'the value is: %d' % myNum(17) > > then it will be myNum.__format__ that gets called, not int.__format__; I seem to have misse

Re: [Python-Dev] AC Derby and accepting None for optional positional arguments

On Thu, Jan 16, 2014 at 01:08:47PM -0800, Ryan Smith-Roberts wrote: > socket.getservbyname(servicename[, protocolname]) > > This is not an inspectable signature, since pure Python does not support > bracketed arguments. To make it inspectable, we must give protocolname a > (valid Python) default

Re: [Python-Dev] PEP 461 Final?

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 exceptions > that > could plague Py2 code, all object checking will be done by duck-typing, not > by > values contained

Re: [Python-Dev] PEP 461 Final?

On Fri, Jan 17, 2014 at 05:51:05PM -0800, Ethan Furman wrote: > On 01/17/2014 05:27 PM, Steven D'Aprano wrote: > >>Numeric Format Codes > >> > >> > >>To properly handle int and float subclasses, int(), index(), and float() > >

Re: [Python-Dev] str.rreplace

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, I beg to differ: I think that our communication in this regard actually is quite reasonable. Before s

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

On Fri, Jan 24, 2014 at 08:07:43PM -0800, Larry Hastings wrote: > > (Quick, because apparently nobody reads the long ones!) > > In Python 3.3: > > >>> class C: >...def foo(self, a): pass >... > >>> c = C() > >>> help(c.foo) > > shows you the signature "foo(self, a)". T

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

On Sun, Jan 26, 2014 at 11:40:33PM -0500, Alexander Belopolsky wrote: > I would say no fix is needed for this doc because the signature suggests > (correctly) that passing times by keyword is not supported. How do you determine that? Passing times by keyword works in Python 3.3: py> from itertoo

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

On Mon, Jan 27, 2014 at 04:29:04AM -0800, Larry Hastings wrote: > The code currently has semantics that cannot be accurately represented > in a Python signature. We could do one of three things: > > 1) Do nothing, and don't allow inspect.Signature to produce a signature > for the function. Th

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

On Mon, Jan 27, 2014 at 10:06:57PM -0800, Larry Hastings wrote: > If I were writing it, it might well come out like this: [snip example] +1 on this wording, with one minor caveat: >.. note: if "times" is specified using a keyword argument, and >provided with a negative value, repeat yie

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

On Fri, Jan 31, 2014 at 07:23:52PM -0800, Larry Hastings wrote: > Python is the language that cares about backwards-compatibility--bugs > and all. If your code runs on version X.Y, it should run without > modification on version X.(Y+Z) where Z is a positive integer. > > Therefore it would be

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

On Sat, Feb 01, 2014 at 10:20:24PM +1000, Nick Coghlan wrote: > On 1 February 2014 16:04, Ethan Furman wrote: > > So we only fix bugs that don't work at all? By which I mean, if the > > interpreter doesn't crash, we don't fix it? > > No, we make a judgment call based on the severity and likeliho

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

Hi all, Over on the Python-ideas list, there's a thread about the new statistics module, and as the author of that module, I'm looking for a bit of guidance regarding backwards compatibility. Specifically two issues: (1) With numeric code, what happens if the module become more[1] accurate in

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

On Sat, Feb 22, 2014 at 01:15:13PM +1300, Greg Ewing wrote: > Eli Bendersky wrote: > >For instance, it is sometime non-trivial to know which exceptions some > >function may throw. When you write a try...raise statement, you think > >hard about covering all the bases. In an expression you're unlik

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

On Fri, Feb 21, 2014 at 04:42:36PM -0800, Ethan Furman wrote: > This is not just about better handling of [missing] default values, but of > better exception handling. This PEP adds the ability to use a scalpel > instead of a sledge hammer. Beautifully said! -- Steven __

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

On Fri, Feb 21, 2014 at 02:04:45PM -0500, Yury Selivanov wrote: > Inconvenience of dict[] raising KeyError was solved by > introducing the dict.get() method. And I think that > > dct.get('a', 'b') > > is 1000 times better than > > dct['a'] except KeyError: 'b' I don't think it is better. I thi

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

On Wed, Mar 05, 2014 at 12:57:03PM -0800, Thomas Wouters wrote: > On Thu, Feb 27, 2014 at 1:29 PM, Chris Angelico wrote: > > > +Had this facility existed early in Python's history, there would have been > > +no need to create dict.get() and related methods; > > > FWIW, after experimenting and s

Re: [Python-Dev] Python 4: don't remove anything, don't break backward compatibility

On Mon, Mar 10, 2014 at 02:55:26PM +0100, Victor Stinner wrote: [...] > So can we please try to stop scheduling another major Python version > breaking almost all modules and all applications just to be pendantic? > > No, we should not remove any old feature in Python 4. Python 4 should > be just

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

On Thu, Mar 13, 2014 at 07:54:18AM +1100, Chris Angelico wrote: > On Thu, Mar 13, 2014 at 7:26 AM, "Martin v. Löwis" wrote: > > I think you (or someone) first needs to find a BDFL delegate. > > Traditionally, with syntax changes, there is a good chance that Guido > > doesn't want to delegate at al

Re: [Python-Dev] Intricacies of calling __eq__

On Tue, Mar 18, 2014 at 05:05:56AM -0400, Terry Reedy wrote: > On 3/18/2014 3:52 AM, Maciej Fijalkowski wrote: > >Hi > > > >I have a question about calling __eq__ in some cases. > > > >We're thinking about doing an optimization where say: > > > >if x in d: > >return d[x] > > if d.__contains__(

Re: [Python-Dev] Intricacies of calling __eq__

On Tue, Mar 18, 2014 at 01:21:05PM +0200, Maciej Fijalkowski wrote: > note that this is specifically about dicts, where __eq__ will be > called undecided number of times anyway (depending on collisions in > hash/buckets which is implementation specific to start with) Exactly. Using a __eq__ metho

Re: [Python-Dev] Intricacies of calling __eq__

On Tue, Mar 18, 2014 at 04:42:29PM -0700, Kevin Modzelewski wrote: > My 2 cents: it feels like a slippery slope to start guaranteeing the number > and ordering of calls to comparison functions -- for instance, doing that > for the sort() function would lock in the sort implementation. Although I a

Re: [Python-Dev] Making proxy types easier to write and maintain

On Wed, Mar 19, 2014 at 11:01:39PM +0100, Antoine Pitrou wrote: > On Thu, 20 Mar 2014 07:54:39 +1000 > Nick Coghlan wrote: > > > > Graeme Dumpleton has also subsequently written a library to handle easier > > creation of correct proxy types: https://pypi.python.org/pypi/wrapt > > (is "Graeme" an

[Python-Dev] Negative timedelta strings

There's a furious discussion going on at the python-list mailing list, about negative timedelta strings: py> str(timedelta(0, -1)) '-1 day, 23:59:59' This is documented. It's even documented as being "somewhat unusual". I found a tracker item for it, back in July 2010: http://bugs.python.org/

Re: [Python-Dev] collections.sortedtree

On Fri, Mar 28, 2014 at 09:20:35AM +, Kristján Valur Jónsson wrote: > I'll be willing to experiment with extending the heapq. methods to take an > optional "map" argument. > 'map' would be a dict, mapping objects in the heap to indices. If provided, > each of the heapq methouds would > take

Re: [Python-Dev] PEP 465: A dedicated infix operator for matrix multiplication

On Mon, Apr 07, 2014 at 03:04:18PM -0700, Benjamin Peterson wrote: > On Mon, Apr 7, 2014, at 14:58, Barry Warsaw wrote: > > On Apr 07, 2014, at 05:47 PM, Alexander Belopolsky wrote: > > > > >Python used to have an alias <> for != and I for one miss <> in 3.x. I > > >don't think TOOWTDI should be

Re: [Python-Dev] PEP 465: A dedicated infix operator for matrix multiplication

On Mon, Apr 07, 2014 at 06:06:17PM -0700, Benjamin Peterson wrote: > On Mon, Apr 7, 2014, at 18:04, Steven D'Aprano wrote: > > On Mon, Apr 07, 2014 at 03:04:18PM -0700, Benjamin Peterson wrote: > > > On Mon, Apr 7, 2014, at 14:58, Barry Warsaw wrote: > > > > On A

Re: [Python-Dev] PEP 465: A dedicated infix operator for matrix multiplication

On Tue, Apr 08, 2014 at 06:49:13PM +0200, Antoine Pitrou wrote: > Le 08/04/2014 04:02, Steven D'Aprano a écrit : > > > >Many, many more people take part in the CPython core developer culture > >than just the core developers themselves. Look at the readership of this >

Re: [Python-Dev] issue with itertools leads the crash

On Wed, Apr 09, 2014 at 02:40:21PM -0400, Geoffrey Spear wrote: > Of course, this raises the question of whether making slice assignment > not go into an infinite loop when the programmer asks it to is a > bugfix or a new feature. Definitely a new feature. > Calling: > > list(itertools.cycl

Re: [Python-Dev] dict and required hashing

On Fri, Apr 18, 2014 at 02:57:55PM -0700, Benjamin Peterson wrote: > On Fri, Apr 18, 2014, at 14:46, Jim J. Jewett wrote: > > (1) I believe the recent consensus was that the number of comparisons > > made in a dict lookup is an implementation detail. (Please correct me > > if I am wrong.) > > Ab

Re: [Python-Dev] PEP 469: Restoring the iterkeys/values/items() methods

On Fri, Apr 18, 2014 at 10:31:29PM -0400, Nick Coghlan wrote: > After spending some time talking to the folks at the PyCon Twisted > sprints, they persuaded me that adding back the iterkeys/values/items > methods for mapping objects would be a nice way to eliminate a key > porting hassle for them (

Re: [Python-Dev] PEP 469: Restoring the iterkeys/values/items() methods

On Sat, Apr 19, 2014 at 11:41:35AM +, Kristján Valur Jónsson wrote: > Wouldn't "iterkeys" simply be an alias for "keys" and so on? > I'm +1 on that. No. [steve@ando ~]$ python2.7 -c "it = {}.iterkeys(); print it is iter(it)" True [steve@ando ~]$ python3.3 -c "it = {}.keys(); print(it is iter(

Re: [Python-Dev] PEP 469: Restoring the iterkeys/values/items() methods

On Sat, Apr 19, 2014 at 10:38:39AM -0400, Nick Coghlan wrote: > On 19 Apr 2014 00:27, "Steven D'Aprano" wrote: > > > > On Fri, Apr 18, 2014 at 10:31:29PM -0400, Nick Coghlan wrote: > > > After spending some time talking to the folks at the PyCon Twiste

Re: [Python-Dev] PEP 469: Restoring the iterkeys/values/items() methods

On Sun, Apr 20, 2014 at 03:07:39PM +, Kristján Valur Jónsson wrote: > Does one ever use iteritems() et al without first invoking iter() on > it? I can't speak for others, but I never invoke iteritems *with* iter(). What would be the point? iteritems is documented as returning an interato

Re: [Python-Dev] PEP 469: Restoring the iterkeys/values/items() methods

On Sun, Apr 20, 2014 at 07:27:08PM +, Kristján Valur Jónsson wrote: > Well, "for i in x" and other iteration constructs already call "iter > ()" on their iterable. That's the point. Unless you want to manually > iterate using "next ()" then the distinction between an iterable and > an itera

Re: [Python-Dev] pep8 reasoning

On Thu, Apr 24, 2014 at 01:57:38PM +0100, Tim Golden wrote: > On 24/04/2014 12:59, Tal Einat wrote: > > As far as I know that reason for these examples being frowned upon is > > that they are needlessly redundant. > > Oh, the irony! (Sorry, couldn't resist) Not really ironic, since not all redun

Re: [Python-Dev] ConfigParser mangles keys with special chars

On Fri, Apr 25, 2014 at 12:46:42PM -0400, Fred Drake wrote: > On Fri, Apr 25, 2014 at 10:22 AM, Florian Bruhin > wrote: > > While it seems ConfigParser doesn't do any escaping as all, I'm > > thinking it should at least raise some exception when such a value is > > trying to be set. > > > > I'd e

Re: [Python-Dev] pep8 reasoning

On Fri, Apr 25, 2014 at 08:13:35PM -0400, Donald Stufft wrote: > I agree that I’ve never taken the name to mean that you’re claiming any > sort of endorsement. There are a *vast* number of projects that implement > something that was defined somewhere else and I don’t think any reasonable > person

Re: [Python-Dev] pep8 reasoning

On Fri, Apr 25, 2014 at 08:42:02PM -0400, Donald Stufft wrote: > > On Apr 25, 2014, at 7:20 PM, Ethan Furman wrote: > > > On 04/25/2014 03:26 PM, Donald Stufft wrote: > >> > >> pep8.py doesn’t violate PEP8, it just takes a stricter view of it. > > > > If pep8 reports errors on things that PEP

Re: [Python-Dev] ConfigParser mangles keys with special chars

On Sat, Apr 26, 2014 at 01:59:27AM -0400, Fred Drake wrote: > On Sat, Apr 26, 2014 at 1:34 AM, Steven D'Aprano wrote: > > I think that a line beginning with "#spam" is ambiguous, it isn't clear > > if it is intended as a comment "spam" or a key sta

Re: [Python-Dev] pep8 reasoning

On Sun, Apr 27, 2014 at 04:28:20PM -0400, Terry Reedy wrote: > On 4/27/2014 3:34 PM, Chris Barker wrote: > >On Sun, Apr 27, 2014 at 9:40 AM, Barry Warsaw >> wrote: > > > >On Apr 26, 2014, at 12:33 AM, Janzert wrote: > > > > >So the one example under discussion is:

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

On Tue, Apr 29, 2014 at 12:07:00PM +0900, Stephen J. Turnbull wrote: > Mike Miller writes: > > > Microsoft's guidelines on where to install software are clear, and > > don't make exceptions that "tools" should be installed to the root > > of the drive to bypass file system permissions, for conv

Re: [Python-Dev] [issue6839] zipfile can't extract file

On Tue, Apr 29, 2014 at 07:48:00PM -0700, Jessica McKellar wrote: > Hi Adam, > > Gentlemen, > > > > Thanks for contributing to Python! But not everyone on this list is a guy. And not all of the guys are gentlemen :-) The term I sometimes use is "gentlefolks", or even just "folks". "Ladies and

Re: [Python-Dev] Returning None from methods that mutate object state

On Sat, May 17, 2014 at 04:26:12AM -0400, Terry Reedy wrote: > On 5/17/2014 1:14 AM, Nick Coghlan wrote: > >During a conversation today, I realised that the convention of > >returning None from methods that change an object's state isn't > >captured the Programming Recommendations section of PEP 8.

[Python-Dev] Should standard library modules optimize for CPython?

I think I know the answer to this, but I'm going to ask it anyway... I know that there is a general policy of trying to write code in the standard library that does not disadvantage other implementations. How far does that go the other way? Should the standard library accept slower code because

Re: [Python-Dev] Should standard library modules optimize for CPython?

On Sun, Jun 01, 2014 at 06:11:39PM +1000, Steven D'Aprano wrote: > I think I know the answer to this, but I'm going to ask it anyway... > > I know that there is a general policy of trying to write code in the > standard library that does not disadvantage other implementa

[Python-Dev] Internal representation of strings and Micropython

There is a discussion over at MicroPython about the internal representation of Unicode strings. Micropython is aimed at embedded devices, and so minimizing memory use is important, possibly even more important than performance. (I'm not speaking on their behalf, just commenting as an interested

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

On Wed, Jun 04, 2014 at 01:14:04PM +, 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. I'm afraid I don't understand this argument. The language semantics says that a string i

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

On Wed, Jun 04, 2014 at 01:38:57PM +0300, Paul Sokolovsky wrote: > That's another reason why people don't like Unicode enforced upon them Enforcing design and language decisions is the job of the programming language. You might as well complain that Python forces C doubles as the floating point

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

On Wed, Jun 04, 2014 at 03:32:25PM +, Steve Dower wrote: > Steven D'Aprano wrote: > > The language semantics says that a string is an array of code points. Every > > index relates to a single code point, no code point extends over two or more > > indexes. > > Th

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

On Wed, Jun 04, 2014 at 11:17:18AM +1000, Steven D'Aprano wrote: > There is a discussion over at MicroPython about the internal > representation of Unicode strings. Micropython is aimed at embedded > devices, and so minimizing memory use is important, possibly even > mo

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

On Fri, Jun 06, 2014 at 12:51:11PM +1200, Greg Ewing wrote: > Steven D'Aprano wrote: > >(1) I asked if it would be okay for MicroPython to *optionally* use > >nominally Unicode strings limited to ASCII. Pretty much the only > >response to this as been Guido saying &qu

Re: [Python-Dev] namedtuple implementation grumble

On Fri, Jun 06, 2014 at 07:50:57PM +0100, Chris Withers wrote: > Hi All, > > I've been trying to add support for explicit comparison of namedtuples > into testfixtures and hit a problem which lead me to read the source and > be sad. > > Rather than the mixin and class assembly in the function I

Re: [Python-Dev] namedtuple implementation grumble

On Sun, Jun 08, 2014 at 03:13:55PM -0400, Eric V. Smith wrote: > On 6/7/2014 10:46 AM, Nick Coghlan wrote: > > On 7 June 2014 04:50, Chris Withers wrote: > >> Curious as to what lead to that implementation approach? What does it buy > >> that couldn't have been obtained by a mixin providing the fu

Re: [Python-Dev] Criticism of execfile() removal in Python3

On Tue, Jun 10, 2014 at 05:23:12AM +0300, Paul Sokolovsky wrote: > execfile() builtin function was removed in 3.0. This brings few > problems: > > 1. It hampers interactive mode - instead of short and easy to type > execfile("file.py") one needs to use exec(open("file.py").read()). If the amount

Re: [Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

On Wed, Jun 27, 2018 at 09:52:43PM -0700, Chris Barker wrote: > It seems everyone agrees that scoping rules should be the same for > generator expressions and comprehensions, Yes. I dislike saying "comprehensions and generator expressions" over and over again, so I just say "comprehensions". P

Re: [Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

On Sat, Jun 30, 2018 at 06:30:56PM +1000, Nick Coghlan wrote: > The significant semantic differences between "{x : 1}" and "{x := 1}" > are also rather surprising :) *Significant* and obvious differences are good. It's the subtle differences that you don't notice immediately that really hurt:

Re: [Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

On Thu, Jun 28, 2018 at 03:42:49PM -0700, Chris Barker via Python-Dev wrote: > If we think hardly anyone is ever going to do that -- then I guess it > doesn't matter how it's handled. That's how you get a language with surprising special cases, gotchas and landmines in its behaviour. (Cough PHP

Re: [Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

On Sat, Jun 30, 2018 at 11:32:03PM -0500, Tim Peters wrote: [...] > So, no, gaining performance is _not_ the motivation here. You already had > a way to make it "run fast'. The motivation is the _brevity_ assignment > expressions allow while _retaining_ all of the two-statement form's > advantag

Re: [Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

On Sun, Jul 01, 2018 at 08:35:08AM -0700, Michael Selik wrote: > On Sun, Jul 1, 2018 at 12:39 AM Tim Peters wrote: > > > So, ya, when someone claims [assignment expressions will] make Python > > significantly harder to teach, I'm skeptical of that claim. > > > > I don't believe anyone is making

Re: [Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

On Wed, Jun 27, 2018 at 03:31:42PM -0700, Guido van Rossum wrote: > I'd also like to keep the rule prohibiting use of the same name as a > comprehension loop control variable and as an inline assignment target; > this rule would also prohibit shenanigans with nested comprehensions (for > any set o

Re: [Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

On Wed, Jun 27, 2018 at 07:29:52PM -0500, Tim Peters wrote: [...] > For example, if the name is declared "global" in the outer scope, you'll > get a compile-time error if you try to declare it "nonlocal" in the > contained scope. "parentlocal" adjusts its meaning accordingly, becoming a > synonym

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

On Wed, Jul 04, 2018 at 11:13:20AM +1200, Greg Ewing wrote: > Terry Reedy wrote: > >If we had followed the math precedent, instead of >language>, we would have set builders, list builders, dict builders, and > >generator builders. > > I was intending to suggest something like that back when > co

Re: [Python-Dev] Examples for PEP 572

On Tue, Jul 03, 2018 at 09:54:22PM -0400, Terry Reedy wrote: > >     results = [(x, y, x/y) for x in input_data for y in [f(x)] if y > 0] > > Would (f(x),) be faster? There is a deferred feature request to optimize "for x in [item]" as equivalent to "for x in (item,)", to avoid constructing a

Re: [Python-Dev] PEP 572: Write vs Read, Understand and Control Flow

On Wed, Jul 04, 2018 at 03:21:29PM +0400, Abdur-Rahmaan Janhangeer wrote: > was going to tell > > instead of := maybe => better > > := too close to other langs The fact that := will be familiar to many people (especially if they know Go, Pascal or Eiffel etc) is a point in its favour. https://

Re: [Python-Dev] Examples for PEP 572

On Tue, Jul 03, 2018 at 03:24:09PM -0700, Chris Barker via Python-Dev wrote: > Over the years I've been using it (most of its life), Python has evolved to > become much less of a "scripting" language, and much more of a "systems" > language, and this addition is a (pretty significant) step more in

Re: [Python-Dev] Examples for PEP 572

On Wed, Jul 04, 2018 at 01:03:02AM -0700, Devin Jeanpierre wrote: > The PEP doesn't talk about it, but FWIW, Go and C++17 if statements > allow you to put arbitrary simple statements in the suite header, and > by doing that, solves all the issues you and the PEP mentioned. Whether they solve "all

Re: [Python-Dev] Examples for PEP 572

On Wed, Jul 04, 2018 at 05:02:07PM +1000, Chris Angelico wrote: > On Wed, Jul 4, 2018 at 4:07 PM, Serhiy Storchaka wrote: > "Assignment is a statement" -- that's exactly the point under discussion. Not any more it isn't. We've now gone from discussion to bitter recriminations *wink* > "del i

Re: [Python-Dev] Examples for PEP 572

On Wed, Jul 04, 2018 at 12:10:11AM -0700, Nathaniel Smith wrote: > Right, Python has a *very strong* convention that each line should > have at most one side-effect, import math, fractions, decimal (PEP 8 be damned, sometimes, especially in the REPL, this is much better than three separate imp

Re: [Python-Dev] Examples for PEP 572

On Wed, Jul 04, 2018 at 10:20:35AM -0400, David Mertz wrote: > Hmmm... I admit I didn't expect quite this behavior. I'm don't actually > understand why it's doing what it does. > > >>> def myfun(): > ...print(globals().update({'foo', 43}), foo) Try it with a dict {'foo': 43} instead of a set

<    1   2   3   4   5   6   7   8   9   10   >