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

[Georg Brandl]

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 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 of course depend
a lot on how much code from unicode formatting can be retained or
adapted as opposed to a rewrite from scratch.

cheers,
Georg


___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[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 involved show
> that it is a major holdup of 3.x uptake.)  It would of course depend
> a lot on how much code from unicode formatting can be retained or
> adapted as opposed to a rewrite from scratch.

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
considering the impact of delaying it till 3.5.

Paul.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Victor Stinner]

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
> considering the impact of delaying it till 3.5.

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.)

Victor
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Nick Coghlan]

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 updated it extensively over the past
several
> > days due to Alex's misunderstanding of the objectives for Python 3.4 as
> > well as Armin's latest piece on the increased difficulties in writing
wire
> > protocol handling code.
>
> A couple remarks:
>
> - the unicode section would gain being a little more on the practical
>   side; for example the "surrogateescape" paragraph is an obscure and
>   theoretical way of saying unicode filepaths (etc.) are fully
>   supported on all platforms
>
> - also, it doesn't seem very clear that the primary string type (str)
>   is now unicode; this has important consequences, for example
>   non-ASCII exception messages work fine in 3.x while they were very
>   delicate to work with in 2.x
>
> - when discussing Twisted / gevent alternatives, you should also mention
>   Tornado, which is especially interesting because it works on both
>   Python 2 and Python 3, and therefore presents a nice migration path

Thanks, I've addressed these and a couple of other points people brought up
(e.g. it is cx-freeze that supports Py3k, not py2exe).

> - perhaps you should discuss the idea that "uptake is slow", because
>   the numbers are rather conflicting on that point; see what I wrote in
>   https://mail.python.org/pipermail/python-list/2014-January/663922.html
>   and also Chris Angelico's elaboration in
>   https://mail.python.org/pipermail/python-list/2014-January/664003.html

I haven't incorporated these observations yet, but I will. It ties in
closely with the point that bootstrapping the new Python 3 application
ecosystem with cross-version libraries and frameworks is not the same thing
as migrating the existing Python 2 *application* ecosystem, and the latter
is expected to take *much* longer (since existing Python 2 users will have,
of necessity, already worked around or avoided the bugs and limitations of
that version of the language).

Cheers,
Nick.

>
> Regards
>
> Antoine.
>
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Donald Stufft]

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 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
>> considering the impact of delaying it till 3.5.
> 
> 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.)
> 
> Victor
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> https://mail.python.org/mailman/options/python-dev/donald%40stufft.io


-
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Nick Coghlan]

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), it also becomes
much easier to extract as an extension module on PyPI for wire protocol
formatting. That would allow folks to choose between just supporting 3.5+
and using the builtin formatting operations, or switching to the cross
version compatible formatting module (if one was created).

So I like the idea of restoring this capability for 3.5, but don't see a
reason to consider rushing it into 3.4.

Cheers,
Nick.

>
> On Jan 7, 2014, at 5:13 AM, Victor Stinner 
wrote:
>
> > 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
> >> considering the impact of delaying it till 3.5.
> >
> > 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.)
> >
> > Victor
> > ___
> > Python-Dev mailing list
> > Python-Dev@python.org
> > https://mail.python.org/mailman/listinfo/python-dev
> > Unsubscribe:
https://mail.python.org/mailman/options/python-dev/donald%40stufft.io
>
>
> -
> Donald Stufft
> PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372
DCFA
>
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Georg Brandl]

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 involved show
>> that it is a major holdup of 3.x uptake.)  It would of course depend
>> a lot on how much code from unicode formatting can be retained or
>> adapted as opposed to a rewrite from scratch.
> 
> 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
> considering the impact of delaying it till 3.5.

Yes, exactly.

Another, and probably better, proposal would be to make 3.5 the
"ultimate" viable porting target: we now know pretty well what the
major remaining roadblocks (real and perceived) are for our developers
and users.

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 came too early for 3.x porting to really profit.

In short, I am increasingly concerned that although we are going a
pretty good way (and Nick's FAQ list makes that much clearer than
anything else I've read), but it is not perceived as such, and could
be better.  We have brought Python 3 on the community, and as such
we need to make it very very clear that we are working with them, not
against them.  A minor release dedicated to that end should be a
very direct representation of that.

I know about the "release everything to PyPI" strategy, but it just
doesn't have the same impact.

It would be very cool to have multiple projects working together with
us for this, and at the release of 3.5 final, present (say) a Mercurial
that works on 2.5 and 3.5.

Mostly pipe-dreams though...
Georg



___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Antoine Pitrou]

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" features. Here is a try as a PEP.
> 
> 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 of course depend
> a lot on how much code from unicode formatting can be retained or
> adapted as opposed to a rewrite from scratch.

>From what I've seen of the unicode formatting code, a lot would have to
be rewritten or refactored. It is a non-trivial task, definitely
inappropriate for 3.4.

Regards

Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[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 similar to the moratorium
> for 3.2, but that one came too early for 3.x porting to really profit.

The moratorium was for alternate Python implementations IIRC, not for
porting third-party libraries.

> It would be very cool to have multiple projects working together with
> us for this, and at the release of 3.5 final, present (say) a Mercurial
> that works on 2.5 and 3.5.

You seem to be forgetting that we are only one part of the equation
here. Unless you want to tackle Mercurial and Twisted porting yourself?
Good luck with that.

Regards

Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Stefan Krah]

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 of course depend
> > a lot on how much code from unicode formatting can be retained or
> > adapted as opposed to a rewrite from scratch.
> 
> From what I've seen of the unicode formatting code, a lot would have to
> be rewritten or refactored. It is a non-trivial task, definitely
> inappropriate for 3.4.

I do not know the stringlib well enough, so I have a silly question:

Would it be possible to re-use the 2.x stringlib just for the bytes type,
name it byteslib and disable features as appropriate?


Stefan Krah



___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Georg Brandl]

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 similar to the moratorium
>> for 3.2, but that one came too early for 3.x porting to really profit.
> 
> The moratorium was for alternate Python implementations IIRC, not for
> porting third-party libraries.

Yes, but this would be a similar moratorium with another purpose.

>> It would be very cool to have multiple projects working together with
>> us for this, and at the release of 3.5 final, present (say) a Mercurial
>> that works on 2.5 and 3.5.
> 
> You seem to be forgetting that we are only one part of the equation
> here. Unless you want to tackle Mercurial and Twisted porting yourself?
> Good luck with that.

No no, I did not forget :)  that's why I wrote "working together with
them".  It would need to be coordinated with the external projects, but
from what I've seen there are willing people.

Georg


___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Stephen J. Turnbull]

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 still don't think the 2.x bytestring is inherently evil, it's just
 >the wrong type to use as the core text type because of the problems
 >it has with silently creating mojibake and also with multi-byte
 >codecs and slicing. The current python-ideas thread is close to
 >convincing me even a stripped down version isn't a good idea, though
 >:P

Lack of it is obviously a major pain point for many developers, but --
it is inherently evil.  It's a structured data type passed around as
an unstructured blob of memory, with no way for one part of the
program to determine what (if anything) another part of the program
thinks it's doing.  It's the Python equivalent to the pointer type
aliasing that gcc likes to whine about.

Given that most wire protocols that benefit from this kind of thing
are based on ASCII-coded commands and parameters, I think there's a
better alternative to either adding 2.x bytestrings as a separate type
or to PEP 460.  This is to add a (minimal) structure we could call
"ASCII-compatible byte array" to the current set of Unicode
representations.  The detailed proposal is on -ideas (where I call it
"7-bit representation", but that has already caused misunderstanding.)
This representation would treat non-ASCII bytes as the current
representations do bytes encoded as surrogates.  This representation
would be produced only by a special "ascii-compatible" codec (which
implies the surrogateescape- like behavior).

It has the following advantages for bytestring-type processing:

- double-encoding/decoding is not possible
- uninterpreted bytes are marked as such -- they can be compared
  for equality, but other character manipulations are no-ops.
- representation is efficient
- output via the 'ascii-compatible' codec is just memcpy
- input via the 'ascii-compatible' codec is reasonably efficient
  (in the posted proposal detection of non-ASCII bytes is
  required, so it cannot be just memcpy)
- str operations are all available; only on I/O is any additional
  overhead imposed compared to str

There's one other possible advantage that I haven't thought through
yet: compatibility with 2.x literals (eg, "inputstring.find('To:')"
instead of "inputbytes.find(b'To:')").

It probably does impose overhead compared to bytes, especially with
the restricted functionality Victor proposes for .format() on bytes,
but as Victor points out so does any full-featured string-style
processing vs. low-level operations like .join().  I suppose it would
be acceptable, except possibly the extra copying for I/O.

The main disadvantage is additional complexity in the implementation
of the str type.  I don't think it imposes much runtime overhead,
however, since the checks for different representations when operating
on str must be done anyway.  Operations involving "ascii-compatible"
and other representations at the same time should be rare, except for
the combinations of "ascii-compatible" and 8-bit representations --
which just involve copying bytes as between 8-bit and 8-bit, plus a
bit of logic to set the type correctly.

Steve
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Serhiy Storchaka]

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 %(val)s
  5 %.0f
  5 %02x
  4 %f
  4 %c
  4 %12s
  3 %(user)s
  3 %(id)s
  3 %h
  3 %(bzdir)s
  3 %0.2f
  3 %02d


___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Daniel Holth]

+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.

Isn't it true that if you have bytes > 127 or surrogate escapes then
encoding to latin1 is no longer as fast as memcpy?

On Tue, Jan 7, 2014 at 8:22 AM, 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
>  23 %ld
>  19 %ln
>  12 %.3f
>  10 %a
>  10 %.1f
>   9 %(val)r
>   9 %p
>   9 %.2f
>   8 %I
>   6 %n
>   5 %(val)s
>   5 %.0f
>   5 %02x
>   4 %f
>   4 %c
>   4 %12s
>   3 %(user)s
>   3 %(id)s
>   3 %h
>   3 %(bzdir)s
>   3 %0.2f
>   3 %02d
>
>
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/dholth%40gmail.com
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Eric V. Smith]

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 it is a major holdup of 3.x uptake.)  It would of course depend
>>> a lot on how much code from unicode formatting can be retained or
>>> adapted as opposed to a rewrite from scratch.
>>
>> From what I've seen of the unicode formatting code, a lot would have to
>> be rewritten or refactored. It is a non-trivial task, definitely
>> inappropriate for 3.4.
> 
> I do not know the stringlib well enough, so I have a silly question:
> 
> Would it be possible to re-use the 2.x stringlib just for the bytes type,
> name it byteslib and disable features as appropriate?

I do know it pretty well. I think reusing stringlib from either 2.x or
3.x pre-PEP-393 version would be the best way to go about this.
Unfortunately, reusing (or sharing) the PEP-393 version currently in 3.4
is probably not realistic.

Eric.


___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Hrvoje Niksic]

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 the count?

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Serhiy Storchaka]

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" (the existed path only),
"/home/cutecat/aa" (the first non-existed path; my current strategy), or
"/home/cutecat/aa/bb/cc" (the default behaviour of os.path.realpath)?


The readlink command has three canonicalize modes

`-f'
`--canonicalize'
 Activate canonicalize mode.  If any component of the file name
 except the last one is missing or unavailable, `readlink' produces
 no output and exits with a nonzero exit code.  A trailing slash is
 ignored.

`-e'
`--canonicalize-existing'
 Activate canonicalize mode.  If any component is missing or
 unavailable, `readlink' produces no output and exits with a
 nonzero exit code.  A trailing slash requires that the name
 resolve to a directory.

`-m'
`--canonicalize-missing'
 Activate canonicalize mode.  If any component is missing or
 unavailable, `readlink' treats it as a directory.

Behavior of os.path.realpath() is equivalent to --canonicalize-missing. 
Current behavior of pathlib.Path.resolve() is equivalent to 
--canonicalize-existing.


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.resolve()
if not path.exists():
raise FileNotFoundError(errno.ENOENT, 'No such file or 
directory: %r' % str(path))

return path

So perhaps two main modes should be --canonicalize (default) and 
--canonicalize-missing (with missing=True)?


___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Stephen J. Turnbull]

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 my str contains characters in the range
128-255?", the answer is encoding a str in 8-bit representation to
latin1 is effectively memcpy.  If you read in latin1, it's memcpy all
the way (unless you combine it with a non-latin1 string, in which case
you're in the cases below).

If you mean "what happens when my str contains characters in the range
> 255", you have to truncate 16-bit units to 8 bit units; no memcpy.

Surrogates require >= 16 bits; no memcpy.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Martin v. Löwis]

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 _PyUnicode_FromUCS1).

Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[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 these?

Stefan


___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Victor Stinner]

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 these?

The idea of the PEP is to simply the portage work of Twisted and
Mercurial developers. So the same code should work on Python 2 and
Python 3.

Extending struct features would not help. This is like adding a new
type or function in a third-party module, it requires also to modify
the source code for Python 2. And struct.pack() does not even support
"%s", the current format for bytes strings requires to specify the
length of the string in the format.

Juraj Sukop asked me privately to support floating points in the PEP
460 for its PDF generator. Would you really like to add many features
to the struct module? Padding, format as integer as decimal (maybe
also binary, octal and hexadecimal), format floatting points as
decimal, etc.?

Victor
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Toshio Kuratomi]

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 improvement" until the two implementations
> converge.
>

Reading about the proposed differences reminded me of how in older python2
versions unicode() took keyword arguments but str.decode() only took
positional arguments.  I squashed a lot of trivial bugs in people's code
where that difference wasn't anticpated.  In later python2 versions both of
those came to understand how to take their arguments as keywords which saved
me from further unnecessary pain.

-Toshio


pgpuZ4S1f5GEP.pgp
Description: PGP signature
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Changing Clinic's output

[Antoine Pitrou]

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 separate C files, which would then be
  #included'd into the main module file

- gather all generated code to a single place in the C module file, for
  example near the end (Larry's "accumulator" idea)

- prefix all Clinic-generated lines with a recognizable marker, e.g.
  "/* AC */"

What do you think?

Regards

Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Benjamin Peterson]

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 solutions have been proposed:
> - move all generated code to separate C files, which would then be
>   #included'd into the main module file

+1
I believe this is the "standard" solution for code generation. For
example, Qt's moc uses it.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Ethan Furman]

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
   example near the end (Larry's "accumulator" idea)


+1



- prefix all Clinic-generated lines with a recognizable marker, e.g.
   "/* AC */"


+0

--
~Ethan~
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Larry Hastings]

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 been proposed:
- move all generated code to separate C files, which would then be
   #included'd into the main module file

- gather all generated code to a single place in the C module file, for
   example near the end (Larry's "accumulator" idea)

- prefix all Clinic-generated lines with a recognizable marker, e.g.
   "/* AC */"

What do you think?


For what it's worth, I don't have a strong opinion about it.  I had the 
first one (separate files) working at one point, as as memory serves 
Guido he didn't like that approach and I should remove the feature.  I'm 
happy for Argument Clinic to do any/all/none of the above.



//arry/
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Antoine Pitrou]

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 own opinion too? Otherwise it shouldn't count as a -1.



___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Antoine Pitrou]

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.resolve()
>  if not path.exists():
>  raise FileNotFoundError(errno.ENOENT, 'No such file or 
> directory: %r' % str(path))
>  return path
> 
> 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.

Regards

Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Barry Warsaw]

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 module file, for
>  example near the end (Larry's "accumulator" idea)

+1

>- prefix all Clinic-generated lines with a recognizable marker, e.g.
>  "/* AC */"

+0

-Barry
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Serhiy Storchaka]

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:
- 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:

* It increases the number of lines of code.

  now   with Argument Clinic

  1770   2704 Modules/audioop.c
  1572   1997 Modules/binascii.c
  3772   4558 Modules/_elementtree.c
  2712   3360 Modules/_sre.c
  3060   3742 Modules/_tkinter.c

More PageUp/PageDown needed to list the sources, and you should be more 
accurate wish positioning the scrollbar.


* It adds a lot of names which clutter up lists for navigation in your 
editor/IDE. For example if now there is only one name for the a2b_uu 
function in navigation list, with Argument Clinic there are three names: 
BINASCII_A2B_UU_METHODDEF, binascii_a2b_uu, and binascii_a2b_uu_impl 
(and only the last is interested for humans). If now the list of names 
fits in one screen, with Argument Clinic it will need three screens.


* It makes harder to use search for navigation. Now a2b_uu is occurred 
in the source file 6 times, and with Argument Clinic it will be occurred 
13 times (however moving generated code to separate file will decrease 
this number to 3).


* It mixes manually written code with generated boilerplate

* 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 history.


* It makes the code more errorprone. Peoples can edit generated code 
instead of clinic declaration.


I have converted enough code to Argument Clinic last days and I seen how 
peoples work with already converted code, so I known what I say. If this 
doesn't convince you, I don't know what I can add.


___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Serhiy Storchaka]

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 
--canonicalize-missing is least strict. When you have a function which 
have non-strict behavior (--canonicalize), you can implement a wrapper 
with strict behavior (--canonicalize-existing), but not vice verse.


___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Mark Lawrence]

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 proposed:
- move all generated code to separate C files, which would then be
   #included'd into the main module file

- gather all generated code to a single place in the C module file, for
   example near the end (Larry's "accumulator" idea)

- prefix all Clinic-generated lines with a recognizable marker, e.g.
   "/* AC */"

What do you think?

Regards

Antoine.




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.


--
My fellow Pythonistas, ask not what our language can do for you, ask 
what you can do for our language.


Mark Lawrence

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Antoine Pitrou]

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.
> 
> --canonicalize is not strict. --canonicalize-existing is most strict and 
> --canonicalize-missing is least strict. When you have a function which 
> have non-strict behavior (--canonicalize), you can implement a wrapper 
> with strict behavior (--canonicalize-existing), but not vice verse.

Yes, I meant --canonicalize should be the default.

Regards

Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Ethan Furman]

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 dislike for this method)


Is it your own opinion too? Otherwise it shouldn't count as a -1.


Yes it is.

--
~Ethan~
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Antoine Pitrou]

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
> >>> #included'd into the main module file
> >>
> >> -1  (Guido has stated a strong dislike for this method)
> >
> > Is it your own opinion too? Otherwise it shouldn't count as a -1.
> 
> Yes it is.

Would you care to elaborate on why you're against it?

Regards

Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Ethan Furman]

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]


* 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 history.


I think this is the reason to focus on -- the others seem like editor issues, or easily resolved by the second or third 
options.


--
~Ethan~
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Tres Seaver]

-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.::

/* - Begin ArgumentClinic  */
/* - End ArgumentClinic -- */

I think delineating gencode blocks this way makes it easier to ignore
them (or find them, if needed).



Tres.
- -- 
===
Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   "Excellence by Design"http://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlLMcssACgkQ+gerLs4ltQ5dSACfSEpN2E1EU/AAJhOiaQr1TKgg
jZAAn2Wok6cr1suhwOfEgFZmqlsJ6HB8
=AT9/
-END PGP SIGNATURE-

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Ethan Furman]

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 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 own opinion too? Otherwise it shouldn't count as a -1.


Yes it is.


Would you care to elaborate on why you're against it?


Seriously?  Are you going to now ask all the other respondents who didn't 
explain themselves to do so?

I don't care for it because I like to have all the code be in one file.  I will say that Serhiy's comment about code 
churn has given me some pause to think...


Okay, changing my vote to:

- Use both /* AC */ markers for every line *and* have all the code be in one 
spot

+1

This way the diffs will easily be clear on what was code generator and what was human.  (Thanks, Breamoreboy, for the 
idea! ;)


--
~Ethan~
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Stefan Krah]

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 even more space (look e.g.
at Cython's custom parsers).


Stefan Krah



___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Barry Warsaw]

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 uptake.)  It would of course depend
>a lot on how much code from unicode formatting can be retained or
>adapted as opposed to a rewrite from scratch.

I think we should be willing to entertain breaking feature freeze for getting
this in Python 3.4.  It's a serious enough problem, and Python 3.4 will be
fairly widely distributed.  For example, it will be a supported version in the
next Debian release and in Ubuntu 14.04 LTS, and *possibly* the default Python
3 version.  However, I think we'd need to see how disruptive the code changes
are first, and get good review of any proposed patches.  Larry and Guido would
have to be on board with the exemption as well.

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? b'{arg}'.format(arg=5)
 * str % dict ? b'%(arg)s' % {'arg': 5)

These are just lookup mechanisms for finding the wanted interpolation value
and don't have encoding or conversion effects.

Cheers,
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Skip Montanaro]

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
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Antoine Pitrou]

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? b'{arg}'.format(arg=5)
>  * str % dict ? b'%(arg)s' % {'arg': 5)

I don't think integer values should be supported.

Regards

Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Brett Cannon]

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 custom parsers
> are implemented, the generated code will take up even more space (look e.g.
> at Cython's custom parsers).
>

Guido has already said he hates constructing files that way so that simply
isn't going to happen.

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 Clinic later.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Stefan Krah]

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 Clinic later.

Serhiy, who started the discussion in another thread, is converting modules at
a rapid pace.



Stefan Krah



___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Barry Warsaw]

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 speed up the transition of the rest of the suite, I'm all for
trying to squeeze it into 3.4.

-Barry
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Barry Warsaw]

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 Python interpreter is
the lowest rung of the food chain, so there's a natural delay in having
required support percolate up.  Imposing another 18 month delay would be
unfortunate.  (Obviously, if technical matters prevent it, that's another
thing.)

-Barry


signature.asc
Description: PGP signature
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Antoine Pitrou]

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-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Benjamin Peterson]

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 names involved show
> >that it is a major holdup of 3.x uptake.)  It would of course depend
> >a lot on how much code from unicode formatting can be retained or
> >adapted as opposed to a rewrite from scratch.
> 
> I think we should be willing to entertain breaking feature freeze for
> getting
> this in Python 3.4.  It's a serious enough problem, and Python 3.4 will
> be
> fairly widely distributed.  For example, it will be a supported version
> in the
> next Debian release and in Ubuntu 14.04 LTS, and *possibly* the default
> Python
> 3 version.  However, I think we'd need to see how disruptive the code
> changes
> are first, and get good review of any proposed patches.  Larry and Guido
> would
> have to be on board with the exemption as well.

I agree. This is a very important, much-requested feature for low-level
networking code.

> 
> 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? b'{arg}'.format(arg=5)
>  * str % dict ? b'%(arg)s' % {'arg': 5)

Yes, I don't think we need to support very much of the formatting
language cover 99.8% of formating cases for bytes.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Nick Coghlan]

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
>>
>> +1 for the reasons that Serhiy has listed.  Additionally, if custom
parsers
>> are implemented, the generated code will take up even more space (look
e.g.
>> at Cython's custom parsers).
>
>
> Guido has already said he hates constructing files that way so that
simply isn't going to happen.
>
> 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 Clinic later.

I haven't had a chance to look at any of the newly converted code (due to
vacation and linux.conf.au), so I'm happy to take the word of the folks
doing the conversion that the current behaviour is inconvenient.

I think the split VCS history where changing clinic's output without
changing the function declarations *doesn't* show up as altering the
manually maintained source files (but only clinic and separate generated
"XYZ_clinic.c" files) is a compelling practical argument in favour of the
split file approach, even if it makes execution jump around a little
strangely.

Failing that, I like Larry's proposal to switch to generating only
prototypes inline and having the wrapper implementations at a common point
in each file, reducing the visible boilerplate when looking at individual
functions.

Cheers,
Nick.

>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Larry Hastings]

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 "accumulator" approach I propose that 
the generated code doesn't go at the very end of the file. Instead, I 
suggest they should go *near* the end, below the implementations of the 
module / class methods, but above the methoddef/type structures and the 
module init function.


My reasoning: when I navigate CPython C files implementing a module or a 
type, when I know what entry point I want I just search for its name.  
When I don't know what I want, I jump to the end, then scroll up until I 
find the name in the init function or the structures.  So I wouldn't 
want the code at the very end; that would screw up that navigation mode.



//arry/
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Larry Hastings]

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 history.


I think this is the reason to focus on -- the others seem like editor 
issues, or easily resolved by the second or third options.


I don't think this is a particularly compelling reason.  Once things 
settle down, I'm not anticipating the clinic.py code generator will 
change very often.



//arry/
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Brett Cannon]

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 appropriate in this case.
>
>
> 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 they should go *near* the end, below the implementations of the
> module / class methods, but above the methoddef/type structures and the
> module init function.
>

If it is accumulated in a single location should it just be a single block
for everything towards the end? Then forward declarations would go away
(you could still have it as a comment to copy-and-paste where you define
the implementation) and you can have a single macro for the PyMethodDef
values, each class, etc. If you accumulated the PyMethodDef values into a
single macro it would help make up for the convenience lost of converting a
function by just cutting the old call signature up to the new *_impl()
function.


>
> My reasoning: when I navigate CPython C files implementing a module or a
> type, when I know what entry point I want I just search for its name.  When
> I don't know what I want, I jump to the end, then scroll up until I find
> the name in the init function or the structures.  So I wouldn't want the
> code at the very end; that would screw up that navigation mode.
>

That's how I navigate as well.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Larry Hastings]

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 they should go *near* the end, below the
implementations of the module / class methods, but above the
methoddef/type structures and the module init function.


If it is accumulated in a single location should it just be a single 
block for everything towards the end? Then forward declarations would 
go away (you could still have it as a comment to copy-and-paste where 
you define the implementation) and you can have a single macro for the 
PyMethodDef values, each class, etc. If you accumulated the 
PyMethodDef values into a single macro it would help make up for the 
convenience lost of converting a function by just cutting the old call 
signature up to the new *_impl() function.


I *think* that would complicate some use cases.  People occasionally 
call these parsing functions from other functions, or spread their 
methoddef / typeobject structures throughout the file rather than 
putting them all at the end.


I'm proposing that the blob of text immediately between the Clinic input 
and the body of the impl contain (newlines added here for clarity):


   static char *parsing_function_doc;

   static PyObject *
   parsing_function(...);

   #define PARSING_FUNCTION_METHODDEF \
{ ... }

   static PyObject *
   parsing_function_impl(...)

Then the "accumulator" would get the text of the docstring and the 
definition of the parsing_function.



On the other hand, if we wanted to take this opportunity to force 
everyone to standardize (all methoddefs and typeobjects go at the end!) 
we could probably make it work with one giant block near the end.


Or I could make it flexible on what went into the accumulator and what 
went into the normal output block, and the default could be 
everything-in-the-accumulator.  Making the common easy and the uncommon 
possible and all that.  Yeah, that seems best.



//arry/
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Barry Warsaw]

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: {obj.attr}
>>  * Indexing: {dict[key]}
>>  * format keywords? b'{arg}'.format(arg=5)
>>  * str % dict ? b'%(arg)s' % {'arg': 5)
>
>I don't think integer values should be supported.

Sorry, the point I was making was about the interpolation and lookup features,
not the specific values.

-Barry
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Larry Hastings]

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.  But I don't think I can do it all myself.


To learn more about what Argument Clinic is, and get a sense for what 
the work will be like, please read the howto in the documentation:


   http://docs.python.org/dev/howto/clinic.html


How can you help?  I've split up the files in the Python source tree 
between about two dozen issues on the issue tracker, each having roughly 
50 call sites in them to examine*.  You can find the issues by searching 
for the word "Derby".  This URL should do the trick:


   
http://bugs.python.org/issue?%40search_text=Derby&ignore=file%3Acontent&title=&%40columns=title&id=&%40columns=id&stage=&creation=&creator=&activity=&%40columns=activity&%40sort=activity&actor=&nosy=&type=&components=&versions=&dependencies=&assignee=&keywords=&priority=&%40group=priority&status=1&%40columns=status&resolution=&nosy_count=&message_count=&%40pagesize=50&%40startwith=0&%40queryname=&%40old-queryname=&%40action=search

To participate, find an issue that isn't assigned to anyone and assign 
it to yourself.  (As far as I can tell there's no way to search for 
issues owned by "nobody", so you'll have to hunt around.)  Once you own 
an issue, open up those files, search for "PyArg_ParseTuple(args" and 
"PyArg_ParseTupleAndKeywords(args", and start converting!


In case you have questions / find bugs / need help, I'll be highly 
available on IRC in #python-dev during the derby, as well as responding 
to email and changes on the issue tracker.  I'm very willing to review 
patches.


Help!


//arry/

* The original plan was, one file per issue on the tracker.  But there 
are 129 files, and I was informed that people would come to my house and 
make my life unpleasant if I created 129 issues on the tracker.  Please 
forgive me for the mildly-random way the files got bundled together.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[R. David Murray]

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 for Python that makes argument parsing code much easier to 
> write.  But I don't think I can do it all myself.
> 
> To learn more about what Argument Clinic is, and get a sense for what 
> the work will be like, please read the howto in the documentation:
> 
> http://docs.python.org/dev/howto/clinic.html
> 
> 
> How can you help?  I've split up the files in the Python source tree 
> between about two dozen issues on the issue tracker, each having roughly 
> 50 call sites in them to examine*.  You can find the issues by searching 
> for the word "Derby".  This URL should do the trick:
> 
> 
> http://bugs.python.org/issue?%40search_text=Derby&ignore=file%3Acontent&title=&%40columns=title&id=&%40columns=id&stage=&creation=&creator=&activity=&%40columns=activity&%40sort=activity&actor=&nosy=&type=&components=&versions=&dependencies=&assignee=&keywords=&priority=&%40group=priority&status=1&%40columns=status&resolution=&nosy_count=&message_count=&%40pagesize=50&%40startwith=0&%40queryname=&%40old-queryname=&%40action=search
> 
> To participate, find an issue that isn't assigned to anyone and assign 
> it to yourself.  (As far as I can tell there's no way to search for 
> issues owned by "nobody", so you'll have to hunt around.)  Once you own 
> an issue, open up those files, search for "PyArg_ParseTuple(args" and 
> "PyArg_ParseTupleAndKeywords(args", and start converting!

Note: you can still help even if you are not someone who can assign
the issue to themselves.  Just make a note that you want to work on the
issue in a message posted to the issue.  Obviously, everyone should also
check for such messages before picking one to work on...

If all the issues get claimed, we can start worrying about divvying
up the work further.  That would be a nice problem to have :)

> In case you have questions / find bugs / need help, I'll be highly 
> available on IRC in #python-dev during the derby, as well as responding 
> to email and changes on the issue tracker.  I'm very willing to review 
> patches.
> 
> Help!
> 
> 
> //arry/
> 
> * The original plan was, one file per issue on the tracker.  But there 
> are 129 files, and I was informed that people would come to my house and 
> make my life unpleasant if I created 129 issues on the tracker.  Please 
> forgive me for the mildly-random way the files got bundled together.
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> https://mail.python.org/mailman/options/python-dev/rdmurray%40bitdance.com
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Stephen J. Turnbull]

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 would be perfectly
well-served in terms of code readability and algorithmic accuracy by
reading with .decode('ascii', errors='surrogateescape') and writing
with .encode() and the same parameters (or as latin1).

 > Yes, I don't think we need to support very much of the formatting
 > language cover 99.8% of formating cases for bytes.

And the other 0.02% will be continuous excuses for RFEs and gratuitous
bugs in rarely used format specs and ports from str processing to
bytes processing.

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Mark Lawrence]

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 returning to beta status.

Skip



When I first saw the suggestion from Georg I had visions of men in white 
coats gragging him off :)  Having giving the idea more thought I think 
there's any opportunity here and now to make a very profound long term 
impact for Python 3.  Skip's idea seems to me a clean way to do this. 
Short term pain, long term gain?


--
My fellow Pythonistas, ask not what our language can do for you, ask 
what you can do for our language.


Mark Lawrence

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com