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 make a
On 7 January 2014 09:40, Georg Brandl g.bra...@gmx.net 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
2014/1/7 Paul Moore p.f.mo...@gmail.com:
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
On 7 Jan 2014 08:03, Antoine Pitrou solip...@pitrou.net wrote:
On Tue, 7 Jan 2014 09:16:10 +1000
Nick Coghlan ncogh...@gmail.com 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
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 victor.stin...@gmail.com wrote:
2014/1/7 Paul Moore
On 7 Jan 2014 18:18, Donald Stufft don...@stufft.io 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
Am 07.01.2014 10:59, schrieb Paul Moore:
On 7 January 2014 09:40, Georg Brandl g.bra...@gmx.net 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
On Tue, 07 Jan 2014 10:40:15 +0100
Georg Brandl g.bra...@gmx.net 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
On Tue, 07 Jan 2014 11:33:55 +0100
Georg Brandl g.bra...@gmx.net 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
Antoine Pitrou solip...@pitrou.net 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
Am 07.01.2014 12:16, schrieb Antoine Pitrou:
On Tue, 07 Jan 2014 11:33:55 +0100
Georg Brandl g.bra...@gmx.net 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.
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
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
+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
On 01/07/2014 06:24 AM, Stefan Krah wrote:
Antoine Pitrou solip...@pitrou.net 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
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
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
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 when
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
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
2014/1/7 Stefan Behnel stefan...@behnel.de:
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
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
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
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.
Several
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
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
On Tue, 07 Jan 2014 12:03:00 -0800
Ethan Furman et...@stoneleaf.us 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
On Tue, 07 Jan 2014 17:26:20 +0200
Serhiy Storchaka storch...@gmail.com 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):
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
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
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
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
On Tue, 07 Jan 2014 22:45:54 +0200
Serhiy Storchaka storch...@gmail.com 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
On 01/07/2014 12:07 PM, Antoine Pitrou wrote:
On Tue, 07 Jan 2014 12:03:00 -0800
Ethan Furman et...@stoneleaf.us 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
On Tue, 07 Jan 2014 12:33:11 -0800
Ethan Furman et...@stoneleaf.us wrote:
On 01/07/2014 12:07 PM, Antoine Pitrou wrote:
On Tue, 07 Jan 2014 12:03:00 -0800
Ethan Furman et...@stoneleaf.us wrote:
On 01/07/2014 11:53 AM, Antoine Pitrou wrote:
- move all generated code to separate C files,
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]
-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.::
/*
On 01/07/2014 01:04 PM, Antoine Pitrou wrote:
On Tue, 07 Jan 2014 12:33:11 -0800
Ethan Furman et...@stoneleaf.us wrote:
On 01/07/2014 12:07 PM, Antoine Pitrou wrote:
On Tue, 07 Jan 2014 12:03:00 -0800
Ethan Furman et...@stoneleaf.us wrote:
On 01/07/2014 11:53 AM, Antoine Pitrou wrote:
-
Antoine Pitrou solip...@pitrou.net 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
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
On Tue, Jan 7, 2014 at 2:46 PM, Barry Warsaw ba...@python.org 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.
On Tue, 7 Jan 2014 15:46:50 -0500
Barry Warsaw ba...@python.org 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
On Tue, Jan 7, 2014 at 4:44 PM, Stefan Krah ste...@bytereef.org wrote:
Antoine Pitrou solip...@pitrou.net 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
Brett Cannon br...@python.org 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
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 helps
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
On Tue, 7 Jan 2014 05:16:18 -0500
Donald Stufft don...@stufft.io 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
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 the big
On 8 Jan 2014 06:24, Brett Cannon br...@python.org wrote:
On Tue, Jan 7, 2014 at 4:44 PM, Stefan Krah ste...@bytereef.org wrote:
Antoine Pitrou solip...@pitrou.net wrote:
Several solutions have been proposed:
- move all generated code to separate C files, which would then be
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
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
On Tue, Jan 7, 2014 at 6:24 PM, Larry Hastings la...@hastings.org 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
On 01/07/2014 03:38 PM, Brett Cannon wrote:
On Tue, Jan 7, 2014 at 6:24 PM, Larry Hastings la...@hastings.org
mailto:la...@hastings.org 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.
On Jan 07, 2014, at 11:13 PM, Antoine Pitrou wrote:
On Tue, 7 Jan 2014 15:46:50 -0500
Barry Warsaw ba...@python.org 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
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.
On Tue, 07 Jan 2014 16:46:59 -0800, Larry Hastings la...@hastings.org 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
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
On 07/01/2014 22:11, Skip Montanaro wrote:
On Tue, Jan 7, 2014 at 2:46 PM, Barry Warsaw ba...@python.org 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
58 matches
Mail list logo
