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

On 07/01/2014 22:11, Skip Montanaro wrote: On Tue, Jan 7, 2014 at 2:46 PM, Barry Warsaw wrote: I think we should be willing to entertain breaking feature freeze for getting this in Python 3.4. Maybe you could revert 3.4 to alpha status and give it a cycle or two there to get this done before

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

Benjamin Peterson writes: > I agree. This is a very important, much-requested feature for low-level > networking code. I hear it's much-requested, but is there any description of typical use cases? The ones I've seen on this list and on -ideas are typically stream-oriented, and seem like they

Re: [Python-Dev] The Great Argument Clinic Conversion Derby is now open!

On Tue, 07 Jan 2014 16:46:59 -0800, Larry Hastings wrote: > > I'm trying to get a huge chunk of work done on Python 3.4 in the next, > oh, week-and-a-half, and I could use your help. I'm trying to convert a > whole bunch of call sites in Python to use "Argument Clinic", a new > build utility

[Python-Dev] The Great Argument Clinic Conversion Derby is now open!

I'm trying to get a huge chunk of work done on Python 3.4 in the next, oh, week-and-a-half, and I could use your help. I'm trying to convert a whole bunch of call sites in Python to use "Argument Clinic", a new build utility for Python that makes argument parsing code much easier to write.

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

On Jan 07, 2014, at 11:13 PM, Antoine Pitrou wrote: >On Tue, 7 Jan 2014 15:46:50 -0500 >Barry Warsaw wrote: >> >> If adopted for Python 3.4, PEP 460 should be modest in its goals, but I think >> I'd still like to see the following excluded and unknown features added: >> >> * Attribute access:

Re: [Python-Dev] Changing Clinic's output

On 01/07/2014 03:38 PM, Brett Cannon wrote: On Tue, Jan 7, 2014 at 6:24 PM, Larry Hastings > wrote: For what it's worth, if we use the "accumulator" approach I propose that the generated code doesn't go at the very end of the file. Instead, I suggest the

Re: [Python-Dev] Changing Clinic's output

On Tue, Jan 7, 2014 at 6:24 PM, Larry Hastings wrote: > On 01/07/2014 12:46 PM, Mark Lawrence wrote: > > > Maybe overkill but why not follow 3 with 2 at the end of the file, the > marker to be a very clear /* Generated by Argument Clinic - DO NOT EDIT > BELOW THIS LINE */ or whatever wording is

Re: [Python-Dev] Changing Clinic's output

On 01/07/2014 12:51 PM, Ethan Furman wrote: On 01/07/2014 12:39 PM, Serhiy Storchaka wrote: * It clutters up hg log and hg blame results. Every time when you change clinic.py to generate different output, it touches multiple lines in all files which use Argument Clinic and clutters up their his

Re: [Python-Dev] Changing Clinic's output

On 01/07/2014 12:46 PM, Mark Lawrence wrote: Maybe overkill but why not follow 3 with 2 at the end of the file, the marker to be a very clear /* Generated by Argument Clinic - DO NOT EDIT BELOW THIS LINE */ or whatever wording is appropriate in this case. For what it's worth, if we use the

Re: [Python-Dev] Changing Clinic's output

On 8 Jan 2014 06:24, "Brett Cannon" wrote: > > > > > On Tue, Jan 7, 2014 at 4:44 PM, Stefan Krah wrote: >> >> Antoine Pitrou wrote: >> > Several solutions have been proposed: >> > - move all generated code to separate C files, which would then be >> > #included'd into the main module file >> >

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

On Tue, Jan 7, 2014, at 12:46 PM, Barry Warsaw wrote: > On Jan 07, 2014, at 10:40 AM, Georg Brandl wrote: > > >Very nice, thanks. If I was to make a blasphemous suggestion I would > >even target it for Python 3.4. (No, seriously, this is a big issue > >- see the recent discussion by Armin - and

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

On Tue, 7 Jan 2014 05:16:18 -0500 Donald Stufft wrote: > Given the low adoption rates for Python 3 It would be nice not repeating that mantra since there are no reliable usage figures available. Regards Antoine. ___ Python-Dev mailing list Python-De

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

On Jan 07, 2014, at 05:16 AM, Donald Stufft wrote: >Given the low adoption rates for Python 3 it would not surprise me if people >who are hampered by the lack of this change are willing to wait until a Python >version is released that has it. If that means waiting until 3.5, then I disagree. The

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

On Jan 07, 2014, at 11:13 AM, Victor Stinner wrote: >Twisted and Mercurial don't support Python 3. > >(I heard that Twisted Core supports Python 3, but I don't know if it's >true nor the Python 3 version.) Parts of Twisted do run on Python 3 (and are even available in Ubuntu), but if PEP 460 help

Re: [Python-Dev] Changing Clinic's output

Brett Cannon wrote: > I personally don't care about this whole discussion (and I suspect people > being > quiet don't either). At this point the amount of arguing on this topic could > have been used more constructively converting code and then, if necessary, > tweaking the output of Argument Cli

Re: [Python-Dev] Changing Clinic's output

On Tue, Jan 7, 2014 at 4:44 PM, Stefan Krah wrote: > Antoine Pitrou wrote: > > Several solutions have been proposed: > > - move all generated code to separate C files, which would then be > > #included'd into the main module file > > +1 for the reasons that Serhiy has listed. Additionally, if

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

On Tue, 7 Jan 2014 15:46:50 -0500 Barry Warsaw wrote: > > If adopted for Python 3.4, PEP 460 should be modest in its goals, but I think > I'd still like to see the following excluded and unknown features added: > > * Attribute access: {obj.attr} > * Indexing: {dict[key]} > * format keywords?

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

On Tue, Jan 7, 2014 at 2:46 PM, Barry Warsaw wrote: > I think we should be willing to entertain breaking feature freeze for getting > this in Python 3.4. Maybe you could revert 3.4 to alpha status and give it a cycle or two there to get this done before returning to beta status. Skip ___

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

On Jan 07, 2014, at 10:40 AM, Georg Brandl wrote: >Very nice, thanks. If I was to make a blasphemous suggestion I would >even target it for Python 3.4. (No, seriously, this is a big issue >- see the recent discussion by Armin - and the big names involved show >that it is a major holdup of 3.x up

Re: [Python-Dev] Changing Clinic's output

Antoine Pitrou wrote: > Several solutions have been proposed: > - move all generated code to separate C files, which would then be > #included'd into the main module file +1 for the reasons that Serhiy has listed. Additionally, if custom parsers are implemented, the generated code will take up

Re: [Python-Dev] Changing Clinic's output

On 01/07/2014 01:04 PM, Antoine Pitrou wrote: On Tue, 07 Jan 2014 12:33:11 -0800 Ethan Furman wrote: On 01/07/2014 12:07 PM, Antoine Pitrou wrote: On Tue, 07 Jan 2014 12:03:00 -0800 Ethan Furman wrote: On 01/07/2014 11:53 AM, Antoine Pitrou wrote: - move all generated code to separate C fi

Re: [Python-Dev] Changing Clinic's output

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/07/2014 02:53 PM, Antoine Pitrou wrote: > - prefix all Clinic-generated lines with a recognizable marker, e.g. > "/* AC */" +1. I would wrap generated code in even-more-visually-distinct markers, both before and after, e.g.:: /* -

Re: [Python-Dev] Changing Clinic's output

On 01/07/2014 12:39 PM, Serhiy Storchaka wrote: 07.01.14 21:53, Antoine Pitrou написав(ла): - move all generated code to separate C files, which would then be #included'd into the main module file Only this option will solve all my issues. My arguments against current behavior: [snip]

Re: [Python-Dev] Changing Clinic's output

On Tue, 07 Jan 2014 12:33:11 -0800 Ethan Furman wrote: > On 01/07/2014 12:07 PM, Antoine Pitrou wrote: > > On Tue, 07 Jan 2014 12:03:00 -0800 > > Ethan Furman wrote: > >> On 01/07/2014 11:53 AM, Antoine Pitrou wrote: > >>> > >>> - move all generated code to separate C files, which would then be >

Re: [Python-Dev] Changing Clinic's output

On 01/07/2014 12:07 PM, Antoine Pitrou wrote: On Tue, 07 Jan 2014 12:03:00 -0800 Ethan Furman wrote: On 01/07/2014 11:53 AM, Antoine Pitrou wrote: - move all generated code to separate C files, which would then be #included'd into the main module file -1 (Guido has stated a strong disl

Re: [Python-Dev] The desired behaviour for resolve() when the path doesn't exist

On Tue, 07 Jan 2014 22:45:54 +0200 Serhiy Storchaka wrote: > 07.01.14 22:28, Antoine Pitrou написав(ла): > >> So perhaps two main modes should be --canonicalize (default) and > >> --canonicalize-missing (with missing=True)? > > > > That sounds reasonable. And I think strict should be the default.

Re: [Python-Dev] Changing Clinic's output

On 07/01/2014 19:53, Antoine Pitrou wrote: Hello, Several core developers a bit unhappy with the way Argument Clinic currently scatters generated code into hand-written C modules. The opinion is that it makes C files more confusing and annoying to navigate through. Several solutions have been

Re: [Python-Dev] The desired behaviour for resolve() when the path doesn't exist

07.01.14 22:28, Antoine Pitrou написав(ла): So perhaps two main modes should be --canonicalize (default) and --canonicalize-missing (with missing=True)? That sounds reasonable. And I think strict should be the default. --canonicalize is not strict. --canonicalize-existing is most strict and

Re: [Python-Dev] Changing Clinic's output

07.01.14 21:53, Antoine Pitrou написав(ла): Several core developers a bit unhappy with the way Argument Clinic currently scatters generated code into hand-written C modules. The opinion is that it makes C files more confusing and annoying to navigate through. Several solutions have been proposed

Re: [Python-Dev] Changing Clinic's output

On Jan 07, 2014, at 08:53 PM, Antoine Pitrou wrote: >- move all generated code to separate C files, which would then be > #included'd into the main module file I'm not a big fan of this approach either, but maybe not as vehemently, so -0. >- gather all generated code to a single place in the C

Re: [Python-Dev] The desired behaviour for resolve() when the path doesn't exist

On Tue, 07 Jan 2014 17:26:20 +0200 Serhiy Storchaka wrote: > > Behavior of --canonicalize-existing can be derived from --canonicalize, > just check that resulting patch exists. But other modes can't be derived > from --canonicalize-existing. > > def resolve_existing(path): > path = path.r

Re: [Python-Dev] Changing Clinic's output

On Tue, 07 Jan 2014 12:03:00 -0800 Ethan Furman wrote: > On 01/07/2014 11:53 AM, Antoine Pitrou wrote: > > > > - move all generated code to separate C files, which would then be > >#included'd into the main module file > > -1 (Guido has stated a strong dislike for this method) Is it your ow

Re: [Python-Dev] Changing Clinic's output

On 01/07/2014 11:53 AM, Antoine Pitrou wrote: Hello, Several core developers a bit unhappy with the way Argument Clinic currently scatters generated code into hand-written C modules. The opinion is that it makes C files more confusing and annoying to navigate through. Several solutions have bee

Re: [Python-Dev] Changing Clinic's output

On 01/07/2014 11:53 AM, Antoine Pitrou wrote: - move all generated code to separate C files, which would then be #included'd into the main module file -1 (Guido has stated a strong dislike for this method) - gather all generated code to a single place in the C module file, for exampl

Re: [Python-Dev] Changing Clinic's output

On Tue, Jan 7, 2014, at 11:53 AM, Antoine Pitrou wrote: > > Hello, > > Several core developers a bit unhappy with the way Argument Clinic > currently scatters generated code into hand-written C modules. The > opinion is that it makes C files more confusing and annoying to > navigate through. > >

[Python-Dev] Changing Clinic's output

Hello, Several core developers a bit unhappy with the way Argument Clinic currently scatters generated code into hand-written C modules. The opinion is that it makes C files more confusing and annoying to navigate through. Several solutions have been proposed: - move all generated code to separa

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

On Tue, Jan 07, 2014 at 09:26:20PM +0900, Stephen J. Turnbull wrote: > Is this really a good idea? PEP 460 proposes rather different > semantics for bytes.format and the bytes % operator from the str > versions. I think this is going to be both confusing and a continuous > target for "further imp

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

2014/1/7 Stefan Behnel : > Victor Stinner, 06.01.2014 14:24: >> ``struct.pack()`` is incomplete. For example, a number cannot be >> formatted as decimal and it does not support padding bytes string. > > Then what about extending the struct module in a way that makes it cover > more use cases like t

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

Victor Stinner, 06.01.2014 14:24: > ``struct.pack()`` is incomplete. For example, a number cannot be > formatted as decimal and it does not support padding bytes string. Then what about extending the struct module in a way that makes it cover more use cases like these? Stefan __

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

Am 07.01.14 15:08, schrieb Daniel Holth: > Isn't it true that if you have bytes > 127 or surrogate escapes then > encoding to latin1 is no longer as fast as memcpy? You mean "decoding from latin1" (i.e. bytes to string)? No, the opposite is true. It couldn't use memcpy before, but does now (see _

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

Daniel Holth writes: > Isn't it true that if you have bytes > 127 or surrogate escapes then > encoding to latin1 is no longer as fast as memcpy? Be careful. As phrased, the question makes no sense. You don't "have bytes" when you are encoding, you have characters. If you mean "what happens w

Re: [Python-Dev] The desired behaviour for resolve() when the path doesn't exist

06.01.14 12:38, Vajrasky Kok написав(ла): This is related with ticket 19717: "resolve() fails when the path doesn't exist". Assuming /home/cutecat exists but not /home/cutecat/aa, what is the desired output of Path('/home/cutecat/aa/bb/cc').resolve(strict=False)? Should it be: "/home/cutecat"

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

On 01/07/2014 02:22 PM, Serhiy Storchaka wrote: Most popular formatting codes in Mercurial sources: 2519 %s 493 %d 102 %r 48 %Y 47 %M 41 %H 39 %S 38 %m 33 %i 29 %b [...] Are you sure you're not including str[fp]time formats in t

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

On 01/07/2014 06:24 AM, Stefan Krah wrote: > Antoine Pitrou wrote: >>> Very nice, thanks. If I was to make a blasphemous suggestion I would >>> even target it for Python 3.4. (No, seriously, this is a big issue >>> - see the recent discussion by Armin - and the big names involved show >>> that i

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

+1 I have always been delighted that it is possible to manipulate binary data in Python using string operations. It's not just immoral non-Unicode text processing. A poor man's ASN.1 generator is an example of a very non-text thing that might be convenient to write with a few %s fill-in-the-blanks

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

Most popular formatting codes in Mercurial sources: 2519 %s 493 %d 102 %r 48 %Y 47 %M 41 %H 39 %S 38 %m 33 %i 29 %b 23 %ld 19 %ln 12 %.3f 10 %a 10 %.1f 9 %(val)r 9 %p 9 %.2f 8 %I 6 %n 5 %(va

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

Is this really a good idea? PEP 460 proposes rather different semantics for bytes.format and the bytes % operator from the str versions. I think this is going to be both confusing and a continuous target for "further improvement" until the two implementations converge. Nick Coghlan writes: >I

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

Am 07.01.2014 12:16, schrieb Antoine Pitrou: > On Tue, 07 Jan 2014 11:33:55 +0100 > Georg Brandl wrote: >> >> The proposal would be to focus entirely on addressing these roadblocks >> in the 3.5 version, and no other new features -- the release cycle >> needn't be 18 months for this one. This is

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

Antoine Pitrou wrote: > > Very nice, thanks. If I was to make a blasphemous suggestion I would > > even target it for Python 3.4. (No, seriously, this is a big issue > > - see the recent discussion by Armin - and the big names involved show > > that it is a major holdup of 3.x uptake.) It would

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

On Tue, 07 Jan 2014 11:33:55 +0100 Georg Brandl wrote: > > The proposal would be to focus entirely on addressing these roadblocks > in the 3.5 version, and no other new features -- the release cycle > needn't be 18 months for this one. This is similar to the moratorium > for 3.2, but that one ca

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

On Tue, 07 Jan 2014 10:40:15 +0100 Georg Brandl wrote: > Am 06.01.2014 14:24, schrieb Victor Stinner: > > Hi, > > > > bytes % args and bytes.format(args) are requested by Mercurial and > > Twisted projects. The issue #3982 was stuck because nobody proposed a > > complete definition of the "new" f

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

Am 07.01.2014 10:59, schrieb Paul Moore: > On 7 January 2014 09:40, Georg Brandl wrote: >> Very nice, thanks. If I was to make a blasphemous suggestion I would >> even target it for Python 3.4. (No, seriously, this is a big issue >> - see the recent discussion by Armin - and the big names involv

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

On 7 Jan 2014 18:18, "Donald Stufft" wrote: > > Given the low adoption rates for Python 3 it would not surprise me if people > who are hampered by the lack of this change are willing to wait until a Python > version is released that has it. Once the code exists (regardless of the exact spelling),

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

Given the low adoption rates for Python 3 it would not surprise me if people who are hampered by the lack of this change are willing to wait until a Python version is released that has it. On Jan 7, 2014, at 5:13 AM, Victor Stinner wrote: > 2014/1/7 Paul Moore : >> Will the relevant projects act

Re: [Python-Dev] General Q&A regarding Python 3, adoption etc.

On 7 Jan 2014 08:03, "Antoine Pitrou" wrote: > > On Tue, 7 Jan 2014 09:16:10 +1000 > Nick Coghlan wrote: > > For anyone that isn't already aware, I wrote a Q & A about Python 3 last > > year (in response to an article about how we should have fixed the GIL > > instead of Unicode), and I've update

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

2014/1/7 Paul Moore : > Will the relevant projects actually support only 2.X and 3.4/5+? If > they expect to or have to support 3.2 or 3.3, then this change isn't > actually going to help them much. If they will only support versions > of Python 3 containing this change, then it may well be worth >

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

On 7 January 2014 09:40, Georg Brandl wrote: > Very nice, thanks. If I was to make a blasphemous suggestion I would > even target it for Python 3.4. (No, seriously, this is a big issue > - see the recent discussion by Armin - and the big names involved show > that it is a major holdup of 3.x upt

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

Am 06.01.2014 14:24, schrieb Victor Stinner: > Hi, > > bytes % args and bytes.format(args) are requested by Mercurial and > Twisted projects. The issue #3982 was stuck because nobody proposed a > complete definition of the "new" features. Here is a try as a PEP. Very nice, thanks. If I was to ma