On 01/15/2014 05:17 PM, Carl Meyer wrote:
I think the PEP could really use a rationale section
It will have one before it's done.
Also I think it would be useful to have a section summarizing the
primary objections that have been raised, and why those objections have
been overruled
Excell
On 01/14/2014 10:58 PM, Stephen J. Turnbull wrote:
At the very least, the "iterated interpolation is a bad idea"
misfeature needs to be documented.
I'm not sure it needs any extra attention. Even with str, iterated interpolation is tricky -- I've been bitten by it
more than once, and that ev
On 01/15/2014 06:45 AM, Brett Cannon wrote:
This is why I have argued that if you specify it as "if there is a format spec
specified, then the return value from
calling __format__() will have str.decode('ascii', 'strict') called on it" you
get the support for the various
number-specific format
On 01/15/2014 06:12 PM, Glenn Linderman wrote:
On 1/15/2014 4:13 PM, Ethan Furman wrote:
- no value generated errors
...
%c will insert a single byte, either from an int in range(256), or from
a bytes argument of length 1.
what does
x = 354
b"%c" % x
produce? Seems that
On 01/16/2014 04:49 AM, Michael Urman wrote:
On Thu, Jan 16, 2014 at 1:52 AM, Ethan Furman wrote:
Is this an intended exception to the overriding principle?
Hmm, thanks for spotting that. Yes, that would be a value error if anything
over 255 is used, both currently in Py2, and for bytes in
On 01/16/2014 06:45 AM, Brett Cannon wrote:
On Thu, Jan 16, 2014 at 2:51 AM, Ethan Furman wrote:
On 01/15/2014 06:45 AM, Brett Cannon wrote:
This is why I have argued that if you specify it as
"if there is a format spec specified, then the return
value from calling __format__() will
On 01/16/2014 10:30 AM, Eric V. Smith wrote:
On 01/16/2014 11:23 AM, Ethan Furman wrote:
On 01/16/2014 06:45 AM, Brett Cannon wrote:
But that's **only** because the numeric types choose
to as part of their __format__() implementation; it is
not inherent to str.format().
As I understa
On 01/16/2014 05:32 PM, Greg wrote:
I don't think it matters whether the internal details of that
debate make sense to the rest of us. The main thing is that
a consensus seems to have been reached on bytes formatting
being basically a good thing.
And a good thing, too, on both counts! :)
A f
On 01/17/2014 07:15 AM, Mark Lawrence wrote:
For both options 1 and 2 surely you cannot be suggesting that
after people have written 2.x code to use format() as %f
formatting is to be deprecated
%f formatting is not deprecated, and will not be in 3.x's lifetime.
--
~Ethan~
__
=
PEP: 461
Title: Adding % formatting to bytes
Version: $Revision$
Last-Modified: $Date$
Author: Ethan Furman
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 2014-01-13
Python-Version: 3.5
Post-History: 2014-01-14, 2014-01-15, 2014-01-17
Resolution:
Abstract
This PE
On 01/16/2014 11:47 PM, Steven D'Aprano wrote:
On Thu, Jan 16, 2014 at 08:23:13AM -0800, Ethan Furman wrote:
As I understand it, str.format will call the object's __format__. So, for
example, if I say:
u'the value is: %d' % myNum(17)
then it will be myNum.__format__ t
On 01/17/2014 09:13 AM, Eric V. Smith wrote:
On 01/17/2014 11:58 AM, Brett Cannon wrote:
On Fri, Jan 17, 2014 at 11:16 AM, Barry Warsaw wrote:
On Jan 17, 2014, at 11:00 AM, Brett Cannon wrote:
I would rephrase it to "switch to %-formatting for bytes usage for
their common code base".
-1. %
On 01/17/2014 11:40 AM, Glenn Linderman wrote:
On 1/17/2014 8:49 AM, Ethan Furman wrote:
>>> b'%s' % 3.14
Traceback (most recent call last):
...
TypeError: 3.14 has no __bytes__ method
If you produce a helpful error message for str (re: encoding), might it
On 01/17/2014 08:53 AM, Brett Cannon wrote:
Don't abbreviate; spell out "Python 2".
Fixed.
Originally this PEP also proposed adding format style formatting, but it was
"format-style"
Fixed.
decided that format and its related machinery were all strictly text (aka
str)
ba
On 01/17/2014 05:27 PM, Steven D'Aprano wrote:
On Fri, Jan 17, 2014 at 08:49:21AM -0800, Ethan Furman wrote:
Overriding Principles
=
In order to avoid the problems of auto-conversion and Unicode
exceptions that could plague Py2 code, all object checking will
be do
On 01/17/2014 06:03 PM, Chris Angelico wrote:
On Sat, Jan 18, 2014 at 12:51 PM, Ethan Furman wrote:
It seems there are two possibilities with %a:
1) have it be ascii(repr(obj))
Wouldn't that be redundant? ascii() is already repr()-like.
Good point.
--
~
On 01/18/2014 03:40 AM, Antoine Pitrou wrote:
On Fri, 17 Jan 2014 08:49:21 -0800
Ethan Furman wrote:
PEP: 461
There are formatting issues in the HTML rendering, I think the ReST
code needs a bit massaging:
http
On 01/18/2014 05:48 AM, Nick Coghlan wrote:
On 18 Jan 2014 11:52, "Ethan Furman" wrote:
I'll admit to being somewhat on the fence about %a.
It seems there are two possibilities with %a:
1) have it be ascii(repr(obj))
2) have it be str(obj).encode('ascii', &
On 01/18/2014 10:49 AM, Larry Hastings wrote:
Later in the thread someone suggests that ".h" would be a better ending; I'm
willing to consider that.
I'll cast a vote for .clinic.h. :)
--
~Ethan~
___
Python-Dev mailing list
Python-Dev@python.org
ht
On 01/18/2014 05:21 PM, Neil Schemenauer wrote:
Ethan Furman wrote:
So, if %a is added it would act like:
-
"%a" % some_obj
-
tmp = str(some_obj)
res = b''
for ch in tmp:
if ord(ch) < 256:
res += bytes([ord(ch)]
On 01/18/2014 02:01 PM, Ethan Furman wrote:
where 'unicode_escape' would yield something like "\u0440" ?
Just to be clear, "\u0440" is the six bytes b'\\', b'u', b'0', b'4', b'4', b'0'.
--
~Ethan~
___
On 01/19/2014 03:32 AM, Georg Brandl wrote:
Am 19.01.2014 11:19, schrieb Larry Hastings:
On 01/18/2014 10:36 PM, Nick Coghlan wrote:
On 19 January 2014 10:44, Steve Dower wrote:
Visual Studio will try to compile them if they end with .c, though this can
be disabled on a per-file basis in the
On 01/19/2014 06:35 AM, Serhiy Storchaka wrote:
18.01.14 18:30, Eric V. Smith написав(ла):
Same here. There's some history for this, but not for generated code. In
Objects/stringlib, all of the files are .h files. They're really C code
designed to be included by other .c files.
Objects/string
On 01/19/2014 03:37 AM, Steven D'Aprano wrote:
On Fri, Jan 17, 2014 at 05:51:05PM -0800, Ethan Furman wrote:
On 01/17/2014 05:27 PM, Steven D'Aprano wrote:
Numeric Format Codes
To properly handle int and float subclasses, int(), index(), and float()
will be
On 01/19/2014 03:37 AM, Steven D'Aprano wrote:
On Fri, Jan 17, 2014 at 05:51:05PM -0800, Ethan Furman wrote:
On 01/17/2014 05:27 PM, Steven D'Aprano wrote:
Numeric Format Codes
To properly handle int and float subclasses, int(), index(), and float()
will be
On 01/19/2014 06:56 PM, Stephen J. Turnbull wrote:
Ethan Furman writes:
Well, that means that this PEP just further strengthens the notion
that format is for text (as then a custom numeric type could easily
override the display even for :d, :h, etc.) and % is for bytes
(where such glyphs are
On 01/19/2014 11:10 PM, Stephen J. Turnbull wrote:
Ethan Furman writes:
> > This argument is specious.
>
> I don't think so. I think it's a good argument for the future of
> Python code.
I agree that restricting bytes '%'-formatting to ASCII is a
On 01/20/2014 12:05 AM, Larry Hastings wrote:
Contestant 1: "Add .clinic.h"
foo.c -> foo.c.clinic.h
foo.h -> foo.h.clinic.h
-1
Contestant 2: "Add .ac.h"
foo.c -> foo.c.ac.h
foo.h -> foo.h.ac.h
-1
Contestant 3: "Add .clinic"
foo.c -> foo.c.clinic
foo.h -> foo.
On 01/20/2014 11:46 AM, Brett Cannon wrote:
On Mon, Jan 20, 2014 at 2:09 PM, Barry Warsaw wrote:
On Jan 20, 2014, at 12:05 AM, Larry Hastings wrote:
Contestant 5: "Put in __clinic__ directory, add .h"
foo.c -> __clinic__/foo.c.h
foo.h -> __clinic__/foo.h.h
This is cached output right?
On 01/20/2014 12:14 PM, Georg Brandl wrote:
Am 20.01.2014 21:05, schrieb Ethan Furman:
On 01/20/2014 11:46 AM, Brett Cannon wrote:
On Mon, Jan 20, 2014 at 2:09 PM, Barry Warsaw wrote:
On Jan 20, 2014, at 12:05 AM, Larry Hastings wrote:
Contestant 5: "Put in __clinic__ directory, a
On 01/20/2014 01:57 PM, Larry Hastings wrote:
If that's what you meant, then: yes, and yes. It's possible to skip the second
pass if you're comfortable guessing the
generated name of the macro, but that's just one more thing for people to
remember, and hunting for it is easier. And
yes, whet
On 01/21/2014 07:59 AM, Yury Selivanov wrote:
2. Adopt PEP 457 style: using “/“ to separate positional-only parameters
from the rest.
+1
--
~Ethan~
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
On 01/22/2014 04:15 AM, Donald Stufft wrote:
As I’ve said multiple times, I think it’s fine to send it through the
deprecation process which is still pretty long and gives people
a good chunk of time to update.
Agreed.
--
~Ethan~
___
Python-Dev mail
On 01/22/2014 05:16 AM, M.-A. Lemburg wrote:
On 22.01.2014 13:43, Jesse Noller wrote:
Donald is perfectly right: today, it's trivial to MITM an application
that relies off of the current behavior; this is bad news bears for
users and developers as it means they need domain knowledge to secure
On 01/24/2014 09:19 AM, Ram Rachum wrote:
Hmm, on one hand I understand the need for the separation between python-dev
and python-list, but on the other hand I
don't think python-list is a good place to discuss Python, the language.
[snip]
it's full of people asking about third-party Python
On 01/25/2014 05:29 AM, Ezio Melotti wrote:
a couple of years ago I suggested to define and document our
deprecation policy
+1
--
~Ethan~
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscri
On 01/25/2014 04:34 AM, Chris Angelico wrote:
On Sat, Jan 25, 2014 at 3:07 PM, Larry Hastings wrote:
What should it be?
A) pydoc and help() should not show bound parameters in the signature, like
inspect.signature.
Vote for A. As far as I'm concerned, all these foo are equally
callable and
On 01/28/2014 04:37 AM, Steven D'Aprano wrote:
On Mon, Jan 27, 2014 at 10:06:57PM -0800, Larry Hastings wrote:
If I were writing it, it might well come out like this:
[snip example]
+1 on this wording, with one minor caveat:
.. note: if "times" is specified using a keyword argument, an
On 01/28/2014 06:50 PM, Larry Hastings wrote:
See the recent discussion "Deprecation policy" right here in python-dev for a
cogent discussion on this issue. I agree
with Raymond's view, posted on 1/25:
* A good use for deprecations is for features that were flat-out misdesigned
and pr
On 01/31/2014 07:23 PM, Larry Hastings wrote:
On 01/28/2014 09:18 PM, Ethan Furman wrote:
On 01/28/2014 06:50 PM, Larry Hastings wrote:
I think the "times behaves differently when passed by name versus passed by
position" behavior falls exactly into this
category, and its advice
On 02/01/2014 04:20 AM, Nick Coghlan wrote:
No, we make a judgment call based on the severity and likelihood of
encountering the bug, the consequences of encountering it, and the
difficulty of working around it after you *do* encounter it.
Thanks for the explanation.
--
~Ethan~
__
On 02/01/2014 04:20 AM, Nick Coghlan wrote:
[snip very nice summary]
So you agree that the bug should be fixed. So do I. My disagreement with Larry is that he would leave the bug in until
Py4k.
--
~Ethan~
___
Python-Dev mailing list
Python-Dev@pyt
On 02/03/2014 09:16 AM, Phil Thompson wrote:
So there *is* code that will fail if a particular Latin-1 string just
happens not to contains any character greater than 127?
Yes, because if it does not contain a character > 127 it is not a latin-1
string as far as Python is concerned.
--
~Etha
On 02/03/2014 09:52 AM, Guido van Rossum wrote:
Can we provide a convenience API (or even a few lines of code one could
copy+paste) that determines if a particular
8-bit string should have max-char equal to 127 or 255?
Isn't that what this is?
My apologies if this is a stupid question (actually, two stupid questions! ;) ,
but:
- is there someplace I can look to see what all the meta commands mean? Things like :class: or .. index:: pair:
class; constructor
- when I click on a link (using FireFox 16.0.1) instead of showing the t
On 02/06/2014 01:51 PM, Berker Peksağ wrote:
I use the following links as reference:
- http://docs.python.org/devguide/documenting.html#id3
- http://sphinx-doc.org/domains.html#the-python-domain
- http://sphinx-doc.org/markup/inline.html#xref-syntax
Many thanks!
--
~Ethan~
__
On 02/12/2014 02:02 PM, yury.selivanov wrote:
http://hg.python.org/cpython/rev/920304e1f36b
changeset: 89175:920304e1f36b
user:Yury Selivanov
date:Wed Feb 12 17:01:52 2014 -0500
summary:
asyncio.events: Use __slots__ in Handle and TimerHandle
files:
Lib/asyncio/events.py
On 02/16/2014 10:31 AM, Larry Hastings wrote:
I'm very sorry that many people contributed to the Derby expecting
their patches to go in to 3.4. This is my fault, for severely
miscalculating how the Derby would play out. And I feel awful
about it.
Don't worry too much. It was a great effor
On 02/18/2014 02:08 AM, M.-A. Lemburg wrote:
This is not garbage data, it's just missing information for
a particular field [...]
I think the basic problem is that None was over-used (or even mis-used?) to the point where 3.0 had to make a choice to
bring consistency back to the language.
I
On 02/15/2014 11:01 AM, Serhiy Storchaka wrote:
How Enum items should be pickled, by value or by name?
I think that Enum will be used to collect system-depending constants, so the
value of AddressFamily.AF_UNIX can be 1 on
one platform and 2 on other. If pickle enums by value, then pickled
Add
On 02/18/2014 09:47 AM, Guido van Rossum wrote:
I'm confused. Hasn't this all been decided by the PEP long ago?
The PEP only mentions pickling briefly, as in "the normal rules apply". How pickling occurs is an implementation
detail, and it turns out that pickling by name is more robust.
Se
On 02/18/2014 10:05 AM, Guido van Rossum wrote:
Hm. But there's an implementation that has made it unscathed through several
betas and an RC. AFAICT that beta pickles
enums by value. And I happen to think that that is the better choice (but I
don't have time to explain this gut feeling
until af
On 02/18/2014 11:20 AM, Guido van Rossum wrote:
I'm confused. AFAICT enums are pickled by value too. What am I missing? Are we
confused about terminology or about
behavior? (I'm just guessing that the pickling happens by value because I don't
see the string AF_INET.)
There's an open issue [1
On 02/18/2014 11:37 AM, Guido van Rossum wrote:
Well, I'm against that.
Given the lack of a tidal wave of support for the idea, I'll let it die with
that.
Still, many thanks to Serhiy for greatly improving the way pickling is
implemented for Enums, even using values.
--
~Ethan~
___
On 02/18/2014 11:53 AM, Serhiy Storchaka wrote:
18.02.14 21:20, Guido van Rossum написав(ла):
I'm confused. AFAICT enums are pickled by value too. What am I missing?
Are we confused about terminology or about behavior? (I'm just guessing
that the pickling happens by value because I don't see the
On 02/19/2014 05:24 PM, Stephen J. Turnbull wrote:
The conflict here is not Larry's
process, it's the decision to make an ambitious release on a short
time schedule. I sympathize with Ubuntu to some extent -- they have a
business to run, after all. But should Ubuntu desires be distorting a
vol
On 02/20/2014 07:15 PM, Chris Angelico wrote:
PEP: 463
Title: Exception-catching expressions
Version: $Revision$
Last-Modified: $Date$
Author: Chris Angelico
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 15-Feb-2014
Python-Version: 3.5
Post-History: 16-Feb-2014, 21-Feb-20
Now that Larry is working on the 3.4.0 branch away from default, what is
default pointing to? 3.4.1 or 3.5?
--
~Ethan~
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.pyt
On 02/20/2014 09:00 PM, Chris Angelico wrote:
On Fri, Feb 21, 2014 at 3:54 PM, Ethan Furman wrote:
(I'll vote on the syntax when the bikeshedding begins ;).
Go get the keys to the time machine! Bikeshedding begins a week ago.
Oh, no, not on PyDev it hasn't! Get ready f
Greetings, all!
Larry asked me to bring this to PyDev, so here it is.
The issues involved are:
http://bugs.python.org/issue20534 -> already in RC1
http://bugs.python.org/issue20653 -> hoping to get cherry-picked
Background
==
When I put Enum together, my knowledge of pickle and its p
On 02/20/2014 07:15 PM, Chris Angelico wrote:
PEP: 463
Title: Exception-catching expressions
[snip]
Deferred sub-proposals
==
Multiple except clauses
---
An examination of use-cases shows that this is not needed as often as
it would be with the statemen
On 02/21/2014 02:26 PM, Eric V. Smith wrote:
On 2/21/2014 5:06 PM, Greg Ewing wrote:
On 21 February 2014 13:15, Chris Angelico wrote:
Generator expressions require parentheses, unless they would be
strictly redundant. Ambiguities with except expressions could be
resolved in the same way, forc
On 02/21/2014 03:29 PM, Greg Ewing wrote:
Antoine Pitrou wrote:
lst = [1, 2]
value = lst[2] except IndexError: "No value"
the gain in concision is counterbalanced by a loss in
readability,
This version might be more readable:
value = lst[2] except "No value" if IndexError
It do
On 02/21/2014 11:04 AM, Yury Selivanov wrote:
On 2/20/2014, 10:15 PM, Chris Angelico wrote:
* list.pop() - no way to return a default
We can fix that in 3.5.
How many are you going to "fix"? How are you going to "fix" the routines you
don't control?
* seq[index] - no way to handle a bou
On 02/21/2014 05:21 PM, Steven D'Aprano wrote:
On Sat, Feb 22, 2014 at 01:15:13PM +1300, Greg Ewing wrote:
With an except expression, it could be written:
result = computation(int(arg)
except ValueError: abort("Invalid int"))
Nice example! Except I'd lay the code out a bit better
On 02/21/2014 07:46 PM, Chris Angelico wrote:
but not this:
value = expr except Exception: default except Exception: default
This should be the way it works. Nothing is gained in readability by turning a try with multiple except statements into
an expression.
--
~Ethan~
__
On 02/21/2014 10:57 PM, Stephen J. Turnbull wrote:
Ethan Furman writes:
On 02/21/2014 07:46 PM, Chris Angelico wrote:
but not this:
value = expr except Exception: default except Exception: default
This should be the way it works. Nothing is gained in readability
by turning a try with
dding % formatting to bytes and bytearray
Version: $Revision$
Last-Modified: $Date$
Author: Ethan Furman
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 2014-01-13
Python-Version: 3.5
Post-History: 2014-01-14, 2014-01-15, 2014-01-17, 2014-02-22
Resolution:
Abstract
Sorry, found a couple more comments in a different thread. Here's what I added:
+Objections
+==
+
+The objections raised against this PEP were mainly variations on two themes::
+
+ - the ``bytes`` and ``bytearray`` types are for pure binary data, with no
+assumptions about encodings
On 02/22/2014 07:29 PM, Mark Lawrence wrote:
On 23/02/2014 02:30, Ethan Furman wrote:
+be any more of a nuisance than the already existing methdods.
Typo "methdods".
Thanks, fixed.
--
~Ethan~
___
Python-Dev mailing list
Python-Dev@
On 02/22/2014 07:47 PM, Cameron Simpson wrote:
On 22Feb2014 17:56, Ethan Furman wrote:
Please let me know if anything else needs tweaking.
[...]
This area of programming is characterized by a mixture of binary data and
ASCII compatible segments of text (aka ASCII-encoded text
On 02/23/2014 03:31 AM, Antoine Pitrou wrote:
On Sat, 22 Feb 2014 20:48:04 -0800 Ethan Furman wrote:
All the numeric formatting codes (such as ``%x``, ``%o``, ``%e``, ``%f``,
``%g``, etc.) will be supported, and will work as they do for str, including
the padding, justification and other
On 02/22/2014 10:50 PM, Nikolaus Rath wrote:
Ethan Furman writes:
Example::
>>> b'%4x' % 10
b' a'
>>> '%#4x' % 10
' 0xa'
>>> '%04X' % 10
'000A'
Shouldn't the
On 02/23/2014 03:33 AM, Antoine Pitrou wrote:
On Sat, 22 Feb 2014 17:56:50 -0800
Ethan Furman wrote:
``%a`` will call :func:``ascii()`` on the interpolated value's :func:``repr()``.
This is intended as a debugging aid, rather than something that should be used
in production. Non-ascii v
On 02/23/2014 03:30 AM, Victor Stinner wrote:
First, this is a warning in reST syntax:
System Message: WARNING/2 (pep-0461.txt, line 53)
Yup, fixed that.
This area of programming is characterized by a mixture of binary data and
ASCII compatible segments of text (aka ASCII-encoded text). B
On 02/23/2014 11:26 AM, Thomas Wouters wrote:
On Feb 23, 2014 7:52 PM, "Stefan Behnel" mailto:stefan...@behnel.de>> wrote:
Chris Angelico, 21.02.2014 04:15:
> Just as PEP 308 introduced a means of value-based conditions in an
> expression, this system allows exception-based conditions to be us
On 02/23/2014 02:54 PM, Nick Coghlan wrote:
It's a harm containment tactic, based on the assumption people *will*
want to include the output of ascii() in binary protocols containing
ASCII segments, regardless of whether or not we consider their reasons
for doing so to be particularly good.
O
On 02/24/2014 09:43 AM, Antoine Pitrou wrote:
On Mon, 24 Feb 2014 09:15:29 -0800
Ethan Furman wrote:
On 02/23/2014 02:54 PM, Nick Coghlan wrote:
It's a harm containment tactic, based on the assumption people *will*
want to include the output of ascii() in binary protocols containing
Okay, types corrected, most comments taken into account.
%b is right out, %a is still suffering scrutiny.
The arguments seem to boil down to:
We don't need it.
vs
Somebody might, and it's better than having them inappropriately add a
__bytes__ method if we don't have it.
"We don't need it"
On 02/24/2014 11:54 AM, Mark Lawrence wrote:
On 24/02/2014 18:40, Ethan Furman wrote:
So, any last thoughts about %a?
I placed it under your nose
https://mail.python.org/pipermail/python-dev/2014-January/131636.html but
personally I
wouldn't lose any sleep whether it stays or goes.
On 02/24/2014 02:33 PM, Nick Coghlan wrote:
Allowing %a also improves the consistency with text interpolation. In the case
of %r, the inconsistency is based on
needing to disallow arbitrary Unicode code points in the result and not wanting
to redefine %r as a second way to spell
%a. There's no
On 02/25/2014 12:13 PM, Terry Reedy wrote:
On 2/25/2014 8:32 AM, Chris Angelico wrote:
On Wed, Feb 26, 2014 at 12:21 AM, Donald Stufft wrote:
Instead of pre-generating one set of values that can be be used to DoS things
you have to pre-generate 256 sets of values and try them until you get the
On 03/04/2014 06:46 PM, Larry Hastings wrote:
On 03/04/2014 03:59 PM, Barry Warsaw wrote:
I too would like an rc3, especially to see if issue 19021 can be fixed, which
I suspect will hit a lot of people.
I talked to the other guys on the 3.4 team, and we're all willing to do an rc3
this weeke
On 03/07/2014 01:20 PM, Jim J. Jewett wrote:
(E) Exceptions are not released even during cyclic gc, because
of ambiguity over which __del__ to run first.
+ This may be like case B or case E
Um, this is case E. ;)
--
~Ethan~
___
Python-Dev mailing
On 03/10/2014 06:55 AM, Victor Stinner wrote:
What do you think?
I think Python 4.0 will follow Python 3.9. No need to rush things [1].
--
~Ethan~
[1] The Python 2 line ended early because we had a major paradigm shift with moving to Unicode by default. Unless we
experience another major
On 03/10/2014 11:21 AM, MRAB wrote:
What does "irregardless" mean?
The same thing as "regardless", with an extra syllable just for fun.
--
~Ethan~
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
On 03/09/2014 07:16 PM, Jim J. Jewett wrote:
because I cannot imagine reading an embedded version of either of those
without having to mentally re-parse at the colon. An example assuming
a precedence level that may not be what the PEP proposes:
if myfunc(5, expr1 except expr2: expr3, "lab
I sure hope this is accepted. I could have used it at least a half-dozen times in the last week -- which is more often
than I would have used the ternary-if! :)
--
~Ethan~
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mail
On 03/12/2014 10:09 AM, Guido van Rossum wrote:
I want to reject this PEP. [...]
But the thing I can't get behind are the motivation and rationale. I don't
think that e.g. dict.get() would be
unnecessary once we have except expressions, and I disagree with the position
that EAFP is better th
On 03/14/2014 01:25 PM, R. David Murray wrote:
Not Provisional:
enum
This is correct.
--
~Ethan~
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/opt
I just made a change to some error messages [1] (really, just one):
old behavior:
'%o' % 3.14
'float' object cannot be interpreted as an integer
new behavior:
'%o' % 3.14
%o format: an integer is required, not float
Would we normally add a test for that?
--
~Ethan~
[1] Issue 19995:
Here's the code in question:
class PsuedoFloat:
def __init__(self, value):
self.value = float(value)
def __int__(self):
return int(self.value)
pi = PsuedoFloat(3.1415)
self.assertRaisesRegex(TypeError, '%x format: a
On 03/19/2014 03:13 PM, Antoine Pitrou wrote:
On Wed, 19 Mar 2014 14:37:42 -0700
Ethan Furman wrote:
Here's the code in question:
class PsuedoFloat:
def __init__(self, value):
self.value = float(value)
def __int__
On 03/19/2014 03:57 PM, Antoine Pitrou wrote:
On Wed, 19 Mar 2014 15:17:53 -0700
Ethan Furman wrote:
On 03/19/2014 03:13 PM, Antoine Pitrou wrote:
On Wed, 19 Mar 2014 14:37:42 -0700
Ethan Furman wrote:
Here's the code in question:
class PsuedoFloat:
def __i
On 03/19/2014 04:41 PM, Thomas Wouters wrote:
What Antoine is trying to tell you is that the traceback you pasted shows this:
File "/home/ethan/source/python/__issue19995/Lib/test/test___unicode.py",
line 1156, in test_formatting
self.assertRaisesRegex(__TypeError, '%c'.__mod__, pi),
-Modified: $Date$
Author: Ethan Furman
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 2014-01-13
Python-Version: 3.5
Post-History: 2014-01-14, 2014-01-15, 2014-01-17, 2014-02-22, 2014-03-25
Resolution:
Abstract
This PEP proposes adding % formatting operations
%s is a string.
%U is unicode?
If so, then %s should only be used when it is certain the string in question
has no unicode in it?
--
~Ethan~
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubsc
On 03/26/2014 03:48 AM, Antoine Pitrou wrote:
On Tue, 25 Mar 2014 18:43:30 -0700
Ethan Furman wrote:
%s is a string.
%U is unicode?
What is the context?
A patch I'm adapting has these lines:
static PyObject*
module_getattr(PyObject *m, PyObject *name)
{
char *mod_nam
On 03/26/2014 06:22 AM, � wrote:
[Assuming you are talking about PyUnicode_FromFormatV]
%s is a string.
No. %s is a char*; C does not have a "string" type.
The string behind the pointer should be UTF-8 encoded;
other encodings are tolerated through the "replace" error
handler.
%U is unicode?
On 03/26/2014 03:10 AM, Victor Stinner wrote:
2014-03-25 23:37 GMT+01:00 Ethan Furman:
``%a`` will call ``ascii()`` on the interpolated value.
I'm not sure that I understood correctly: is the "%a" format
supported? The result of ascii() is a Unicode string. Does it mean
t
601 - 700 of 1590 matches
Mail list logo
