[Python-Dev] Re: enum in the stable ABI (Was: PEP 558: Defined semantics for locals)

[Devin Jeanpierre]

On Fri, Jul 23, 2021 at 7:40 AM Petr Viktorin  wrote:
[snip]
> On 21. 07. 21 14:18, Nick Coghlan wrote:

> [snip]
> > Please don't put the enum in the stable ABI. If we would add another
> > value and then an older extension would receive it, we'd get
> undefined
> > behavior.
> >
> >
>
> After researching a bit more, I see that casting unknown values to enum
> is only undefined/unspecified behavior in C++. But we do support C++
> extensions, and so I'll try to get enums out of the stable ABI.
>
> (In both C & C++, the size of an `enum` is implementation-defined.
> That's unlikely to be a problem in practice, but one more point against
> enum.)
>

I can't speak much for C, but for C++ this is fine I think? enums have the
same range of values as their "underlying type" (see e.g.
[basic.fundamental]  and
[dcl.enum] ). Aside from representation,
[expr.static.cast]  explicitly
allows conversion when in-range: "the value is unchanged if the original
value is within the range of the enumeration values". (Note if you click
the link -- "fixed underlying type" refers to a form of enum which doesn't
exist in C; the C-like enums are the ones without a fixed underlying type.)

And as Larry points out, you can force the range of values to be as large
as you want by specifying a large enumerator.

However, the standard is not meant for reading by us mere mortals, so I
usually use cppreference, which has this to say at
https://en.cppreference.com/w/cpp/language/enum :

Values of integer, floating-point, and enumeration types can be converted
> by static_cast 
> or explicit cast
> , to any
> enumeration type. If the underlying type is not fixed and the source value
> is out of range, [the result is unspecified (until C++17) | the behavior
> is undefined (since C++17)]. [...] Note that the value after such
> conversion may not necessarily equal any of the named enumerators defined
> for the enumeration.


-- Devin
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/IRRUAJWZVPH6XXOP2NJKOH2UHEGM2JDH/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Future PEP: Include Fine Grained Error Locations in Tracebacks

[Devin Jeanpierre]

> What are people thoughts on the feature?

I'm +1, this level of detail in the bytecode is very useful. My main
interest is actually from the AST though. :) In order to be in the
bytecode, one assumes it must first be in the AST. That information is
incredibly useful for refactoring tools like https://github.com/ssbr/refex
(n.b. author=me) or https://github.com/gristlabs/asttokens (which refex
builds on). Currently, asttokens actually attempts to re-discover that kind
of information after the fact, which is error-prone and difficult.

This could also be useful for finer-grained code coverage tracking and/or
debugging. One can actually imagine highlighting the spans of code which
were only partially executed: e.g. if only x() were ever executed in "x()
and y()" . Ned Batchelder once did wild hacks in this space, and maybe this
proposal could lead in the future to something non-hacky?
https://nedbatchelder.com/blog/200804/wicked_hack_python_bytecode_tracing.html
I say "in the future" because it doesn't just automatically work, since as
I understand it, coverage currently doesn't track spans, but lines hit by
the line-based debugger. Something else is needed to be able to track which
spans were hit rather than which lines, and it may be similarly hacky if
it's isolated to coveragepy. If, for example, enough were exposed to let a
debugger skip to bytecode for the next different (sub) span, then this
would be useful for both coverage and actual debugging as you step through
an expression. This is probably way out of scope for your PEP, but even so,
the feature may be laying some useful ground work here.

-- Devin

On Fri, May 7, 2021 at 2:52 PM Pablo Galindo Salgado 
wrote:

> Hi there,
>
> We are preparing a PEP and we would like to start some early discussion
> about one of the main aspects of the PEP.
>
> The work we are preparing is to allow the interpreter to produce more
> fine-grained error messages, pointing to
> the source associated to the instructions that are failing. For example:
>
> Traceback (most recent call last):
>
>   File "test.py", line 14, in 
>
> lel3(x)
>
> ^^^
>
>   File "test.py", line 12, in lel3
>
> return lel2(x) / 23
>
>^^^
>
>   File "test.py", line 9, in lel2
>
> return 25 + lel(x) + lel(x)
>
> ^^
>
>   File "test.py", line 6, in lel
>
> return 1 + foo(a,b,c=x['z']['x']['y']['z']['y'], d=e)
>
>  ^
>
> TypeError: 'NoneType' object is not subscriptable
>
> The cost of this is having the start column number and end column number
> information for every bytecode instruction
> and this is what we want to discuss (there is also some stack cost to
> re-raise exceptions but that's not a big problem in
> any case). Given that column numbers are not very big compared with line
> numbers, we plan to store these as unsigned chars
> or unsigned shorts. We ran some experiments over the standard library and
> we found that the overhead of all pyc files is:
>
> * If we use shorts, the total overhead is ~3% (total size 28MB and the
> extra size is 0.88 MB).
> * If we use chars. the total overhead is ~1.5% (total size 28 MB and the
> extra size is 0.44MB).
>
> One of the disadvantages of using chars is that we can only report columns
> from 1 to 255 so if an error happens in a column
> bigger than that then we would have to exclude it (and not show the
> highlighting) for that frame. Unsigned short will allow
> the values to go from 0 to 65535.
>
> Unfortunately these numbers are not easily compressible, as every
> instruction would have very different offsets.
>
> There is also the possibility of not doing this based on some build flag
> on when using -O to allow users to opt out, but given the fact
> that these numbers can be quite useful to other tools like coverage
> measuring tools, tracers, profilers and the such adding conditional
> logic to many places would complicate the implementation considerably and
> will potentially reduce the usability of those tools so we prefer
> not to have the conditional logic. We believe this is extra cost is very
> much worth the better error reporting but we understand and respect
> other points of view.
>
> Does anyone see a better way to encode this information **without
> complicating a lot the implementation**? What are people thoughts on the
> feature?
>
> Thanks in advance,
>
> Regards from cloudy London,
> Pablo Galindo Salgado
>
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/DB3RTYBF2BXTY6ZHP3Z4DXCRWPJIQUFD/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe 

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

[Devin Jeanpierre]

On Sun, Jul 12, 2020 at 7:36 PM Greg Ewing 
wrote:

> On 13/07/20 7:12 am, Larry Hastings wrote:
> > I dimly recall a precedent where the
> > presence of locals() in a function body affected code generation,
>
> The presence of exec used to do that, which is why it was a
> statement rather than a function. But I don't think locals()
> ever did -- how would the compiler know that it was calling
> the builtin locals function and not something else?
>

super() does something similar:

 >>> class A:
...   def super_locals(self):
... super
... return locals()
...   def superless_locals(self):
... return locals()
...
>>> A().super_locals()
{'self': <__main__.A object at 0x01FF53BCE6D8>, '__class__': }
>>> A().superless_locals()
{'self': <__main__.A object at 0x01FF53BCE7B8>}

The compiler changes what local variables exist if there is a read from a
variable named 'super', in order to support zero-argument super() calls. It
presumably could do the same sort of thing for locals(). I don't think this
is a good idea, since locals() is a debugging tool, and changing reality
based on the presence of debugging calls may make life more difficult for
the user.

-- Devin
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/QSP3RISE5HTLIUMLDMHTN7B7EEXPVVRP/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Flexible assignment targets

[Devin Jeanpierre]

 On Wed, Jul 1, 2020 at 11:31 AM Elliott Chen 
wrote:

> I guess it might work in a separate PEP, but I'm also a little worried
> because the current PEP would make that impossible with its subtle
> incompatibilities with the existing unpacking syntax. Or even more
> inconsistent, if the assignment target syntax is extended to become similar
> to the match syntax but still slightly different for backwards
> compatibility.
>

In my view 1 = x is a sneaky degenerate case, and what we should really be
asking is if it's cool to be able to do, say, (x, 0) = a compared with "x,
y = a; if y != 0: raise ValueError".

BTW, +100% to the idea that match should extend assignment semantics (e.g.
to allow multiple clauses). The totally new match semantics have come up a
lot when I discussed this PEP with my friends at work. Even if we get
awkward corner cases out of unifying the two, the simplicity of only having
one notion of lvalue, instead of two lvalue-like things, is IMO an
overriding benefit. This is also more or less how match and assignment tend
to work in the languages that have pattern matching, .

If we are repulsed by "1 = x" and (x, 0) = y, one solution is to do what
Rust did and forbid refutable patterns on the left-hand side of an
assignment, but allow them on the left hand side of a match case. (With the
historically-minded exception of list and tuple literals). This still makes
match an extension of assignment (it's assignment + multiple cases +
refutable patterns) and gives us the simplicity benefits, while forbidding
"1 = x".

-- Devin
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/IM6NZJSZHID46K3QYGG4GUJ5D6GMMX4P/
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-Dev] Examples for PEP 572

[Devin Jeanpierre]

On Wed, Jul 4, 2018 at 7:42 PM Steven D'Aprano  wrote:
> On Wed, Jul 04, 2018 at 01:00:41PM -0700, Devin Jeanpierre wrote:
> > On Wed, Jul 4, 2018 at 11:04 AM Steven D'Aprano  wrote:
> > > Did you actually mean arbitrary simple statements?
> > >
> > > if import math; mylist.sort(); print("WTF am I reading?"); True:
> > > pass
> >
> > Yes.
>
> Okay, you just broke my brain.
>
> I was *sure* that you were going to complain that I was misrepresenting
> your position, or attacking a strawman, or something.

This "brain-breaking" experience is something to keep in mind when we
read the reactions to the acceptance assignment expressions, so that
we can better empathize with the people who are so shocked by it.
After all, assignment expressions allow nearly word for word the same
abuse you posted:

if [(math := __import__('math')), mylist.sort(), print('WTF?'), True][-1]:
  ...

Anything that allows assignment in an if statement is going to allow
some messed up stuff. The PEP seems to intentionally take the stance
that it is OK to allow super-ugly code, because we can trust people to
just not do that.

> I did not imagine for a second that you *actually* would prefer
> to allow the above code over assignment expressions.

I don't really know how to bridge that disconnect. I thought Nathaniel
argued very well what is lost with assignment expressions.

-- Devin
___
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] Examples for PEP 572

[Devin Jeanpierre]

On Wed, Jul 4, 2018 at 11:04 AM Steven D'Aprano  wrote:
> Did you actually mean arbitrary simple statements?
>
> if import math; mylist.sort(); print("WTF am I reading?"); True:
> pass

Yes. To quote PEP 572: "This is a tool, and it is up to the programmer
to use it where it makes sense, and not use it where superior
constructs can be used."

> A more reasonable suggestion would be to only allow *assignments*, not
> arbitrary simple statements. But that's another special case:

I don't agree that it is more reasonable, for exactly the reasons you
describe it to be surprising.

> with one or more semicolon-separated statements between the "if" and the
> condition:
>
> if statement; statement; condition:
>
> If we stick to the rule that semicolons separate statements, that means
> we have:
>
>
> if statement  # SyntaxError
> statement # okay
> condition:# SyntaxError
>
>
> If we don't want that, we need a new rule to treat semicolons
> differently inside if statements that they're treated elsewhere.

Yes. This is analogous to complaining that [1, 2, 3] should be a
syntax error because clearly this is a tuple with three elements:
"[1", "2", and "3]". In as far as it's a new parsing rule, it is a
"special case" indeed.

> If we applied this rule "allow statements separated by semicolons"
> everywhere, we'd get this:
[snip]

Nobody said anything about allowing semicolon-delimited statements in
arbitrary places in the grammar.

-- Devin
___
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] Examples for PEP 572

[Devin Jeanpierre]

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

The only issue that PEP 572 has with limiting to if statements is:
"Disadvantages: Answers only a fraction of possible use-cases, even in
if/whilestatements."  The Go/C++17 syntax resolves that (while still
being limited to if statements and while statements -- the primary use
cases AFAIK, and the only ones Nathaniel agrees with).

> > In Python it'd look like this:
> >
> > if x = expr(); x < 0:
> >   do_stuff()
>
>
> That's even more doubtful, since the semicolon in Python already has a
> meaning of separating statements on a line. That could be equivalent to:
>
> if x = expr()
> x < 0:
>  do_stuff()
>
> which would clearly have to be a syntax error. *Two* syntax errors.
>
> Python's parser is restricted to LL(1) by design, so treating semicolons
> in "if" statements as a special case might not even be possible.
> But even if it is possible, not only would this special case
> break the Zen, but it would be UGLY too.

It isn't a special case, and it's still LL(1). Once you encounter an
"if", you parse n simple statements separated by a ";", until you
reach a colon. Where LL(1) runs into trouble is that last statement
must be an Expr statement, but that can be checked after parsing (e.g.
during compilation). I don't understand why you think this is
"clearly" a syntax error. (So is ":=", if you restrict yourself to the
current Python syntax.)

As for ugly... well, compare:

while (kv := x.pop())[0] is not None:
  foo(kv[1])

while k, v = x.pop(); k is not None:
  foo(v)

if (v := d[k]) == _EOF:
  return None

if v = d[k]; v == _EOF:
  return None

I like ":=" when it is the only thing in the expression: "if a:= b:"
etc.  Every other time I would prefer C++/Go's syntax.

-- Devin
___
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] Examples for PEP 572

[Devin Jeanpierre]

On Wed, Jul 4, 2018 at 12:26 AM Nathaniel Smith  wrote:
> The only cases that seem potentially valuable to me are the ones that
> are literally the form 'if  := ` and 'while  :=
> '. (I suspect these are the only cases that I would allow in
> code that I maintain.) The PEP does briefly discuss the alternative
> proposal of restricting to just these two cases, but rejects it
> because it would rule out code like 'if ( := )
>  '. But those are exactly the cases that I want to
> rule out, so that seems like a plus to me :-).

The PEP doesn't talk about it, but FWIW, Go and C++17 if statements
allow you to put arbitrary simple statements in the suite header, and
by doing that, solves all the issues you and the PEP mentioned. In
Python it'd look like this:

if x = expr(); x < 0:
  do_stuff()

(and presumably, the same for while: "while line = f.readline(); line: ...")

-- Devin
___
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] PEP 572: Write vs Read, Understand and Control Flow

[Devin Jeanpierre]

On Wed, Apr 25, 2018 at 2:17 PM, Terry Reedy  wrote:
> On 4/25/2018 6:10 AM, Steve Holden wrote:
>> Indeed, in the cases where I currently find myself unwrapping expressions
>> to capture their values in local variables for debugging purposes it would
>> usually be far less intrusive to bind a name to the expression inline, then
>> use the debugger to inspect the value.
>
>
> I agree that this is a definite plus feature.  Being able to tag
> subexpressions would make visual debuggers that show all local variables as
> one steps (like IDLE's) even more useful relative to print statements.

Some other programming languages (thinking of Racket) solve this by
having the debugger let you step through expression evaluation,
without editing the code.

e.g. in the line x = 1 + 2 * 3, we might step through and first
evaluate 2*3 (-> 6), and then 1 +  (-> 7). Similar to how
Python already lets you step into and see the result of function
calls. This is especially powerful in visual debuggers, where the
stepping and output can be displayed very intuitively.

-- Devin
___
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] Deprecating float.is_integer()

[Devin Jeanpierre]

> [Mark Dickinson  ]
>> If you have a moment to share it, I'd be interested to know what value of
>> `x` you used to achieve this, and what system you were on. This can't happen
>> under IEEE 754 arithmetic.
>
> I expect it might happen under one of the directed rounding modes
> (like "to +infinity").

PyPy (5.8):

 x = 1e300
 x.is_integer()
True
 math.sqrt(x**2).is_integer()
False
 x**2
inf

(It gives an OverflowError on my CPython installs.)

I believe this is allowed, and Python is not required to raise
OverflowError here:
https://docs.python.org/3.6/library/exceptions.html#OverflowError
says:

> for historical reasons, OverflowError is sometimes raised for integers that 
> are outside a required range. Because of the lack of standardization of 
> floating point exception handling in C, most floating point operations are 
> not checked

-- Devin
___
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] Am I allowed to use C++-style // comments?

[Devin Jeanpierre]

I actually realized right after I sent this that I am writing C++, so
maybe it's a moot point. (Still trying to figure out how to use C for
this, but it's an optional extension module only exposed for testing,
so maybe it really doesn't matter.)

Context is https://github.com/python/cpython/pull/2878

-- Devin

On Tue, Jul 25, 2017 at 9:59 PM, Devin Jeanpierre
<jeanpierr...@gmail.com> wrote:
> https://www.python.org/dev/peps/pep-0007/ says two things:
>
>> Python versions greater than or equal to 3.6 use C89 with several select C99 
>> features:
>> [...]
>> C++-style line comments
>
> and also:
>
>> Never use C++ style // one-line comments.
>
> Which is it?
>
> -- Devin
___
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] Am I allowed to use C++-style // comments?

[Devin Jeanpierre]

https://www.python.org/dev/peps/pep-0007/ says two things:

> Python versions greater than or equal to 3.6 use C89 with several select C99 
> features:
> [...]
> C++-style line comments

and also:

> Never use C++ style // one-line comments.

Which is it?

-- Devin
___
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] PyWeakref_GetObject() borrows its reference from... whom?

[Devin Jeanpierre]

> Huh?  In all other circumstances, a "borrowed" reference is exactly that:
X has a reference, and you are relying on X's reference to keep the object
alive.  Borrowing from a borrowed reference is simply a chain of these; Z
borrows from Y, Y borrows from X, and X is the original person who did the
incref.  But you're borrowing from something specific, somebody who the API
guarantees has a legitimate reference on the object and won't drop it while
you're using it.  I bet for every other spot in the API I can tell you from
whom you're borrowing the reference.
>
> In contrast, the "borrowed" reference returned by PyWeakRef_GetObject()
seems to be "borrowed" from some unspecified entity.  The fact that the
object is live in Python directly implies that, yes, *somebody* must have a
reference, somewhere.  But ISTM (and apparently you) that this is relying
on the GIL preventing that unknown other actor from dropping their
reference while you've borrow it.  A guarantee that the post-Gilectomy
Python interpreter can no longer make!

Let me try again. The only rule for borrowing: x (borrowed reference) is
only guaranteed to be alive for as long as y (source) is guaranteed to be
alive. At least if you phrase it carefully enough, weakrefs still fit the
bill -- your borrowed reference is alive for as long as the weakref is
alive. Of course, the lifetime for a weakref is completely undefined in
GILectomized Python, and barely controllable even in regular CPython. So
this is not a great API.

At the very least we can contort definitions into making it plausible that
we borrowed from the weakref.  If we can only analyze code through the lens
of borrowing, we have no choice except to look at it this way.

> In any case, I see nothing in the documentation that suggests "borrowed
only means unowned" as you suggest.  In contrast, the documentation seems
to suggest that the metaphor is how I understood it; that when you "borrow"
a reference, there is another object who has a reference and you're relying
on their reference to keep the object alive.

This is its own big tangent. Sorry,

Your link is all I have too. It doesn't spell it out. AFAIK there are
exactly two kinds of references discussed anywhere in the docs: owned
references, where you are obligated to call Py_DECREF, and everything else.
Python exclusively uses the term "borrowed references" for that "everything
else". I don't know why. It's a good way to encourage reasonable practices,
I guess.

As the docs themselves note, this metaphor is useful but flawed: e.g. you
can "borrow" the same thing and the original is still usable. But I'd go in
another direction -- the metaphor is sufficient to show safety of some
code, but some safe code exists where we can't as easily use "borrowing" to
talk about why it's safe, and might need to introduce new concepts or
switch tactics.

PyObject* x = PyList_New(0); // x is a new owned reference.
PyObject* y = x;  // y is a borrowed reference.
PyObject* z = x;  // z is also a borrowed reference.
Py_INCREF(y);  // y has been upgraded to an owned reference.
Py_CLEAR(x);  // the original reference z borrowed from disappeared.
// This is provably safe, but you can't use the "borrowing" metaphor for
that proof without introducing new concepts.

do_stuff(z);


// You might wonder, "why would anyone ever do that?!?"
// One reason is because some functions "steal" references, so you need to
borrow before handing off ownership:

// y is an owned reference.
my_struct->foo = y // borrowed a reference to y.
PyTuple_SetItem(my_strict->some_tuple, 0, y); // stole y.
// Now, in a super-strict interpretation, y is no longer "valid", and the
original borrowing relationship has been broken.
// We should ideally reason "as if" it borrowed from my_struct->some_tuple,
even though it didn't.
// (Obviously, this example is still a little overcomplicated, but you get
how this might happen IRL, yeah?
//  e.g. maybe z already existed and the API stealing a reference doesn't
have a GET_ITEM macro.)
// [Note that this has a similar problem to weakref: another thread could
mutate the tuple and delete the object. Yikes!]


I hope those examples made sense.

weakref is playing with fire in a similar way: PyWeakref_GetObject is safe
because someone still exists, and there is a lock that guarantees they
exist as long as you don't release that lock and don't run any code that
might delete a reference.  (In particular, it's guaranteed safe to
immediately upgrade the borrowed reference -- or is without gilectomy.)
 Unlike the stealing tuple example, it isn't clear where the owned
reference is.

So what I mean by saying it's a red herring, is that the correctness of
code doesn't hinge on how easy it is to apply the concept of borrowing, but
exclusively on lifetimes and whether your borrowed reference can be proven
to lie within the object lifetime. If it could not at all be explained
sensibly as a "borrow" from anyone, it can still be right -- that would
only make it 

Re: [Python-Dev] PyWeakref_GetObject() borrows its reference from... whom?

[Devin Jeanpierre]

> It's my contention that this API is simply untenable under the Gilectomy

Yeah, I agree with your contention. The only circumstance PyWeakref_GetObject
would still be valid without a GIL is if you happened to know you had a
reference elsewhere that was keeping it alive. But if you did, you probably
wouldn't need to use the weakref. If you don't, then with GILectomy you
have no thread-safe options.

Trivial bikeshedding:  rather than change the existing API, wouldn't it be
better to add a new API, and not support the old one in GILectomized
CPython? Introducing memory leaks would be a little unfortunate, and it's
hard to audit C code for correct use of refcounted pointers even *before*
you change the ownership of returned pointers across versions.

w.r.t. the exact question:

> whose reference is it borrowing?

I think this is a red herring sort of question. "borrowed" only means
"unowned". But anyway, we borrowed from the weakref. (Borrowing from
somebody doesn't imply they own a reference -- we can borrow from a
borrowed reference, for example, and this is common.)

The term "borrowed" is supposed to imply a sensible scope during which
you're free to use the object, and weakrefs don't have that (except for
what is granted by the GIL), so this does sound wacky. I bet it was for
performance.

-- Devin
___
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] PEP 492 vs. PEP 3152, new round

[Devin Jeanpierre]

On Thu, Apr 30, 2015 at 6:13 PM, Greg greg.ew...@canterbury.ac.nz wrote:
 It's not about requiring or not requiring parens. It's about
 making the simplest possible change to the grammar necessary
 to achieve the desired goals. Keeping the grammar simple
 makes it easy for humans to reason about.

 The question is whether syntactically disallowing certain
 constructs that are unlikely to be needed is a desirable
 enough goal to be worth complicating the grammar. You think
 it is, some others of us think it's not.

+1. It seems weird to add a whole new precedence level when an
existing one works fine. Accidentally negating a future/deferred is
not a significant source of errors, so I don't get why that would be a
justifying example.

-- Devin
___
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] Status of C compilers for Python on Windows

[Devin Jeanpierre]

On Sun, Oct 26, 2014 at 3:41 PM, Paul Moore p.f.mo...@gmail.com wrote:
 Not really, to be honest. I still don't understand why anyone not
 directly involved in CPython development would need to build their own
 Python executable on Windows.

Late Python bugfix releases are source-only, so if you suffer from a
bug and need to get it fixed, you need to build Python from source.

https://www.python.org/download/releases/2.6.9/ has no windows binary
and includes several security fixes.

-- Devin
___
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] Critical bash vulnerability CVE-2014-6271 may affect Python on *n*x and OSX

[Devin Jeanpierre]

On Thu, Sep 25, 2014 at 4:53 PM, Antoine Pitrou solip...@pitrou.net wrote:
 In other words, os.system is *already* an attack vector, unless you only
 use it with trusted strings. I don't think the bash env vulnerability
 adds to the attack surface.

 Have I missed something?

 The part where the attack payload is passed through the environment, not
 through hypothetical user-injected command-line arguments.

As I understand it, if the attacker can help specify the environment
(e.g. this is a CGI script), and you run os.system('echo hi'), you can
get pwned. Even safe uses of os.system are vulnerable unless you point
/bin/sh at a secure shell (e.g. patched bash).

-- Devin
___
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] PEP 467: Minor API improvements for bytes bytearray

[Devin Jeanpierre]

On Sun, Aug 17, 2014 at 7:14 PM, Alex Gaynor alex.gay...@gmail.com wrote:
 I've hit basically every problem everyone here has stated, and in no uncertain
 terms am I completely opposed to deprecating anything. The Python 2 to 3
 migration is already hard enough, and already proceeding far too slowly for
 many of our tastes. Making that migration even more complex would drive me to
 the point of giving up.

Could you elaborate what problems you are thinking this will cause for you?

It seems to me that avoiding a bug-prone API is not particularly
complex, and moving it back to its 2.x semantics or making it not work
entirely, rather than making it work differently, would make porting
applications easier. If, during porting to 3.x, you find a deprecation
warning for bytes(n), then rather than being annoying code churny
extra changes, this is actually a bug that's been identified. So it's
helpful even during the deprecation period.

-- Devin
___
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] Multiline with statement line continuation

[Devin Jeanpierre]

On Sat, Aug 16, 2014 at 12:25 AM, Ben Finney ben+pyt...@benfinney.id.au wrote:
 Steven D'Aprano st...@pearwood.info writes:

 If people were going to be prone to mistake

 with (a, b, c): ...

 as including a tuple

 … because the parens are a strong signal “this is an expression to be
 evaluated, resulting in a single value to use in the statement”.

 they would have already mistaken:

 with a, b, c: ...

 the same way. But they haven't.

 Right. The presence or absence of parens make a big semantic difference.

At least historically so, since except a, b: and except (a, b):
used to be different things (only the latter constructs a tuple in
2.x). OTOH, consider from .. import (..., ..., ...).

Pretty sure at this point parens can be used for non-expressions quite
reasonably -- although I'd still prefer just allowing newlines without
requiring extra syntax.

-- Devin
___
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] Multiline with statement line continuation

[Devin Jeanpierre]

I think this thread is probably Python-Ideas territory...

On Mon, Aug 11, 2014 at 4:08 PM, Allen Li cyberdup...@gmail.com wrote:
 Currently, this works with explicit line continuation, but as all style
 guides favor implicit line continuation over explicit, it would be nice
 if you could do the following:

 with (open('foo') as foo,
   open('bar') as bar,
   open('baz') as baz,
   open('spam') as spam,
   open('eggs') as eggs):
 pass

The parentheses seem unnecessary/redundant/weird. Why not allow
newlines in-between with and the terminating :?

with open('foo') as foo,
   open('bar') as bar,
   open('baz') as baz:
pass

-- Devin
___
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] Multiline with statement line continuation

[Devin Jeanpierre]

On Tue, Aug 12, 2014 at 8:12 AM, Guido van Rossum gu...@python.org wrote:
 On Tue, Aug 12, 2014 at 3:43 AM, Devin Jeanpierre jeanpierr...@gmail.com
 wrote:
 The parentheses seem unnecessary/redundant/weird. Why not allow
 newlines in-between with and the terminating :?

 with open('foo') as foo,
open('bar') as bar,
open('baz') as baz:
 pass


 That way lies Coffeescript. Too much guessing.

There's no syntactic ambiguity, so what guessing are you talking about?

What *really* requires guessing, is figuring out where in Python's
syntax parentheses are allowed vs not allowed ;). For example, from
foo import (bar, baz) is legal, but import (bar, baz) is not.
Sometimes it feels like Python is slowly and organically evolving into
a parenthesis-delimited language.

-- Devin
___
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] sum(...) limitation

[Devin Jeanpierre]

On Sat, Aug 9, 2014 at 12:20 PM, Alexander Belopolsky
alexander.belopol...@gmail.com wrote:

 On Sat, Aug 9, 2014 at 1:08 AM, Steven D'Aprano st...@pearwood.info wrote:

 We wouldn't be having
 these interminable arguments about using sum() to concatenate strings
 (and lists, and tuples) if the  operator was used for concatenation and
 + was only used for numeric addition.


 But we would probably have a similar discussion about all(). :-)

 Use of + is consistent with the use of * for repetition.  What would you use
 use for repetition if you use  instead?

If the only goal is to not be tempted to use sum() for string
concatenation, how about using *? This is more consistent with
mathematics terminology, where a * b is not necessarily the same as b
* a (unlike +, which is commutative). As an example, consider matrix
multiplication. Then, to answer your question, repetition would have
been s ** n.

(In fact, this is the notation for concatenation and repetition used
in formal language theory.)

(If we really super wanted to add this to Python, obviously we'd use
the @ and @@ operators. But it's a bit late for that.)

-- Devin
___
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] Another case for frozendict

[Devin Jeanpierre]

On Wed, Jul 16, 2014 at 6:37 AM, R. David Murray rdmur...@bitdance.com wrote:
 IMO, preventing someone from shooting themselves in the foot by modifying
 something they shouldn't modify according to the API is not a Python
 use case (consenting adults).

Then why have immutable objects at all? Why do you have to put tuples
and frozensets inside sets, instead of lists and sets? Compare with
Java, which really is consenting adults here -- you can add a
mutable object to a set, just don't mutate it, or you might not be
able to find it in the set again.

Several people seem to act as if the Pythonic way is to not allow for
any sort of immutable types at all. ISTM people are trying to
retroactively claim some standard of Pythonicity that never existed.
Python can and does protect you from shooting yourself in the foot by
making objects immutable. Or do you have another explanation for the
proliferation of immutable types, and the inability to add mutable
types to sets and dicts?

Using a frozendict to protect and enforce an invariant in the re
module is entirely reasonable. So is creating a new dict each time.
The intermediate -- reusing a mutable dict and failing in
incomprehensible ways if you mutate it, and potentially even crashing
due to memory safety issues -- is not Pythonic at all.

-- Devin
___
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] PEP 471 -- os.scandir() function -- a better and faster directory iterator

[Devin Jeanpierre]

On Mon, Jun 30, 2014 at 3:07 PM, Tim Delaney
timothy.c.dela...@gmail.com wrote:
 On 1 July 2014 03:05, Ben Hoyt benh...@gmail.com wrote:

  So, here's my alternative proposal: add an ensure_lstat flag to
  scandir() itself, and don't have *any* methods on DirEntry, only
  attributes.
 ...

  Most importantly, *regardless of platform*, the cached stat result (if
  not None) would reflect the state of the entry at the time the
  directory was scanned, rather than at some arbitrary later point in
  time when lstat() was first called on the DirEntry object.


 I'm torn between whether I'd prefer the stat fields to be populated on
 Windows if ensure_lstat=False or not. There are good arguments each way, but
 overall I'm inclining towards having it consistent with POSIX - don't
 populate them unless ensure_lstat=True.

 +0 for stat fields to be None on all platforms unless ensure_lstat=True.

This won't work well if lstat info is only needed for some entries. Is
that a common use-case? It was mentioned earlier in the thread.

-- Devin
___
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] PEP 469: Restoring the iterkeys/values/items() methods

[Devin Jeanpierre]

On Sun, Apr 20, 2014 at 12:27 PM, Kristján Valur Jónsson
krist...@ccpgames.com wrote:
 Well, for i in x and other iteration constructs already call iter () on
 their iterable. That's the point. Unless you want to manually iterate using
 next () then the distinction between an iterable and an iterator is
 academic.

Or unless you iterate over the same thing multiple times, which can happen.

P.S.: If Python had intended to support 2.x/3.x polyglots in the first
place, would iteritems etc. have been removed? My feeling is no, in
which case they should be re-added, since this is the main supported
porting mechanism going forward.

-- Devin


  Original message 
 From: Steven D'Aprano
 Date:20/04/2014 17:05 (GMT+00:00)
 To: python-dev@python.org
 Subject: Re: [Python-Dev] PEP 469: Restoring the iterkeys/values/items()
 methods

 On Sun, Apr 20, 2014 at 03:07:39PM +, Kristján Valur Jónsson wrote:

 Does one ever use iteritems() et al without first invoking iter() on
 it?

 I can't speak for others, but I never invoke iteritems *with* iter().
 What would be the point? iteritems is documented as returning an
 interator.

 # never this
 for key, value in iter(mydict.iteritems()): ...

 # but this
 for key, value in mydict.iteritems(): ...


 I.e. is it important that it is an iterator, rather than an
 iterable? I think we could easily relax that requirement in the pep
 and solve 99% of the use cases.

 And the other 1% of cases would be a land-mine waiting to blow the
 user's code up.

 Would it actually solve 99% of the use cases? Or only 90%? Or 50%? How
 do you know?

 In Python 2.7 iteritems() etc is documented as returning an iterator.
 That's a promise of the language, and people will rely on it. But they
 won't be able to rely on that promise in polygot 2+3 code -- exactly the
 use-case this PEP is trying to satisfy -- because the promise to return
 an iterator will be broken in 3.

 It would be actively misleading, since Python 3's iteritems() would
 return a view, not an iter, and it would fail at solving the backwards
 compatibility issue since views and iterators are not interchangeable
 except for the most basic use of iteration.

 ___
 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/kristjan%40ccpgames.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/jeanpierreda%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] PEP 469: Restoring the iterkeys/values/items() methods

[Devin Jeanpierre]

On Sun, Apr 20, 2014 at 8:01 PM, Cameron Simpson c...@zip.com.au wrote:
 On 20Apr2014 14:32, Mark Lawrence breamore...@yahoo.co.uk wrote:

 On 20/04/2014 06:31, Ethan Furman wrote:

 Thank you for taking the time to write this up, Nick.

 However, I am -1 on it.  One of the allures of Python 3 is the increase
 in simplicity and elegance.  Restoring cruft does not help with that.
 Python 2 idioms that get restored to Python 3 must have real value:
 unicode literals, wire-protocol interpolations -- I don't feel that this
 comes any where close to meeting that bar.
 ~Ethan~


 +1 for this summary which echoes my sentiments entirely.


 Me too. I'm against iteritems and friends coming back.

 I've been burned in the past with the burden of writing a mapping class with
 the many methods such a thing must support; both items() and iteritems() and
 so forth. For the example I have in mind I eventually abandoned the
 objective of being a full mapping and am going back to just a few methods to
 support easy element access such as __getitem__ and __contains__.

As far as I know, all you have to implement yourself, to support the
dict-like interface, are:

 - __getitem__
 - __setitem__
 - __delitem__
 - __iter__
 - __len__

MutableMapping can implement the rest. This wouldn't change with the
re-addition of the iter* methods.

You really have to use MutableMapping now that keys/items/values are
complicated objects: it's much harder to implement dict-like objects
from scratch in 3.x than 2.x.

-- Devin
___
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] News from asyncio

[Devin Jeanpierre]

On Mon, Jan 27, 2014 at 5:21 AM, Victor Stinner
victor.stin...@gmail.com wrote:
 - asyncio.IncompleReadError.expected is the total expected size, not
 the remaining size

Why not be consistent with the meaning of
http.client.IncompleteRead.expected? The current meaning can be
recovered via len(e.partial) + e.expected.

-- Devin
___
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] PEP 443 - Single-dispatch generic functions

[Devin Jeanpierre]

On Thu, May 23, 2013 at 6:40 PM, Steven D'Aprano st...@pearwood.info wrote:
 I don't think that they will. Being able to register multiple types with a
 single call reads very naturally to me, while multiple decorators still
 looks weird. Even after many years of seeing them, I still get a momentary
 What the hell...? moment when I see two decorators on one function. That's
 only going to be increased when both decorators are the same (apart from the
 argument). The double decorator form above looks to me as weird as:

 x = func(a)
 x = func(b)


 would. I have to stop and think about what is going on, and whether or not
 it is a mistake.

That's absurd. The above is not comparable to double decorators, the
following is:

x = func(a)
x = func(x)

And this is clearly not something anyone has to stop and think about.
(more literally, obviously it's actually def x(...): ... ; x =
func(a)(x); x = func(b)(x))

There is nothing remotely wrong or distasteful about using multiple
decorators. It's a natural thing to want to compose multiple functions
together; for example, @functools.lru_cache with @fun.register or
@staticmethod or [...]. And it's even natural to want to apply the
same decorator with different arguments multiple times to the same
thing, if it happens to do something different when given different arguments.

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

Re: [Python-Dev] PEP 443 - Single-dispatch generic functions

[Devin Jeanpierre]

On Thu, May 23, 2013 at 2:04 AM, Antoine Pitrou solip...@pitrou.net wrote:
 On Thu, 23 May 2013 12:12:26 +1000
 Nick Coghlan ncogh...@gmail.com wrote:
 The binary operators can be more accurately said to use a complicated
 single-dispatch dance rather than supporting native dual-dispatch.

 Not one based on the type of a single argument, though.

Why not?

I'd expect it to look something like this:

@singledispatch
def ladd(left, right):
return NotImplemented

@singledispatch
def radd(right, left):
return NotImplemented

def add(left, right):
x = ladd(left, right)
if x is not NotImplemented:
return x
x = radd(right, left)
if x is not NotImplemented:
return x
raise TypeError

Then instead of defining __add__ you define an overloaded
implementation of ladd, and instead of defining __radd__ you define an
overloaded implementation of radd.

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

Re: [Python-Dev] NoneType(None) raises exception

[Devin Jeanpierre]

On Thu, Apr 25, 2013 at 9:12 PM, MRAB pyt...@mrabarnett.plus.com wrote:
 Only when you write it out like that as constants. It's no more,
 or less, strange than str('spam') or int(1) or list([]). Why
 would you do that?

 None is a singleton, but instances of str, int, list, etc aren't. Why
 can it take an argument when there's only ever one of them?

 That's why it seems strange to me.

How about bool? False and True are singletons much like None is, and
bool(False) == False; bool(True) == True.

Sure the distinction is that all of those are useful as conversion
functions, whereas NoneType would never be used that way.

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

Re: [Python-Dev] Why can't I encode/decode base64 without importing a module?

[Devin Jeanpierre]

On Mon, Apr 22, 2013 at 7:39 AM, Calvin Spealman ironfro...@gmail.com wrote:
 if two lines is cumbersome, you're in for a cumbersome life a programmer.

Other encodings are either missing completely from the stdlib, or have
corrupted behavior. For example, string_escape is gone, and
unicode_escape doesn't make any sense anymore -- python code is text,
not bytes, so why does 'abc'.encode('unicode_escape') return bytes? I
don't think this change was thought through completely before it was
implemented.

I agree base64 is a bad place to pick at the encode/decode changes, though. :(

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

Re: [Python-Dev] casefolding in pathlib (PEP 428)

[Devin Jeanpierre]

On Fri, Apr 12, 2013 at 4:39 AM, Antoine Pitrou solip...@pitrou.net wrote:
 Ok, I've taken a look at the code. Right now lower() is used for two
 purposes:

 1. comparisons (__eq__ and __ne__)
 2. globbing and matching

 While (1) could be dropped, for (2) I think we want glob(*.py) to find
 SETUP.PY under Windows. Anything else will probably be surprising to
 users of that platform.

OT, but, why is .lower() used for case folding in these use-cases
instead of .casefold()?

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

Re: [Python-Dev] Are undocumented exceptions considered bugs?

[Devin Jeanpierre]

On Sat, Mar 23, 2013 at 11:21 AM, Nick Coghlan ncogh...@gmail.com wrote:
 In this specific case, the error message is
 confusing-but-not-really-wrong, due to the two-types-in-one nature
 of Python 2.x strings - 8-bit strings are used as both text sequences
 (generally not containing NUL characters) and also as arbitrary binary
 data, including encoded text (quite likely to contain NUL bytes).

With your terminology, three types: char, non-NUL-text, encoded-text
(e.g. what happens with ord('ab'))

That's pretty silly, considering that these are all one Python type,
and TypeError is raised into Python code. Obviously it can't change,
because of historical reasons, but documenting it would be
straightforward and helpful. These are not errors you can just infer
will happen, you need to see it via documentation, reading the source,
or experimentation (and re experimentation, then you have to establish
whether or not this was an accident or deliberate).

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

Re: [Python-Dev] IDLE in the stdlib

[Devin Jeanpierre]

On Thu, Mar 21, 2013 at 2:42 AM, Terry Reedy tjre...@udel.edu wrote:
 I think being frozen in the late 1990s is better than being frozen in the
 early 1980s, like Command Prompt is. In fact, I think we should 'deprecate'
 the Command Prompt interpreter as the standard interactive interpreter and
 finish polishing and de-glitching IDLE's Python Shell, which runs on top of
 the windowless version of CP with a true GUI. Then we can promote and
 present the latter as the preferred interface, which for many people, it
 already is.

Please don't cease supporting the command line interface. I use the
command line interactive interpreter plenty. That way I can use git,
grep, the unit test suite, etc. ... and the interactive interpreter,
all from one place: the console.

That can't happen with IDLE, by design.

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

Re: [Python-Dev] Downloads page: Which version of Python should be listed first?

[Devin Jeanpierre]

On Thu, Dec 13, 2012 at 9:38 PM, Eric Snow ericsnowcurren...@gmail.com wrote:
 If you don't know which version to use, start with Python 2.7; more
 existing third party software is compatible with Python 2 than Python
 3 right now.

 Firstly, is this still true? (I wouldn't have a clue.)

 Nope:

 http://py3ksupport.appspot.com/
 http://python3wos.appspot.com/ (plone and zope skew the results)

Until those numbers hit 100%, or until projects start dropping support
for Python 2.x, the statement would still be true.

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

Re: [Python-Dev] chained assignment weirdity

[Devin Jeanpierre]

On Tue, Nov 6, 2012 at 1:18 AM, Chris Withers ch...@simplistix.co.uk wrote:
 Hi All,

 I bumped into this using Michael Foord's Mock library.
 It feels like a bug to me, but thought I'd ask here before logging one in
 the tracker in case people know that we won't be able to fix it:

 On 05/11/2012 13:43, Michael Foord wrote:


 class Foo(object):

 ...  def __setattr__(s, k, v):
 ...   print k
 ...

 f = Foo()

 f.g = f.x = 3

 g
 x


It's terrible and counter-intuitive, but it is documented. See:
http://docs.python.org/2/reference/simple_stmts.html#assignment-statements

Notice that it proclaims that target lists are assigned to from left
to right. That's the behavior you've noticed.

On the other hand, one might easily misread this piece of
documentation, which implies right to left assignment:
http://docs.python.org/2/reference/expressions.html#evaluation-order

But the last note doesn't look normative to me.

(I'm not a dev, just trying to be helpful.)

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

Re: [Python-Dev] chained assignment weirdity

[Devin Jeanpierre]

On Nov 6, 2012 1:05 PM, Ned Batchelder n...@nedbatchelder.com wrote:

 On 11/6/2012 11:26 AM, R. David Murray wrote:

 On Tue, 06 Nov 2012 18:14:38 +0200, Serhiy Storchaka storch...@gmail.com
wrote:

 Another counterintuitive (and possible wrong) example:

  {print('foo'): print('bar')}
 bar
 foo
 {None: None}

 http://bugs.python.org/issue11205


 This seems to me better left undefined, since there's hardly ever a need
to know the precise evaluation sequence between keys and values, and
retaining some amount of unspecified to allow for implementation
flexibility is a good thing.

Left undefined? The behavior was defined, but CPython didn't follow the
defined behaviour.

--Devin (phone)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] return type of __complex__

[Devin Jeanpierre]

On Mon, Oct 22, 2012 at 7:34 AM, Larry Hastings la...@hastings.org wrote:
 -1 ** 0.5
 -1.0

Be careful about order of operations!

 (-1)**.5
(6.123233995736766e-17+1j)

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

Re: [Python-Dev] return type of __complex__

[Devin Jeanpierre]

I guess I was asking for this. (Sorry for OT conversation.)

On Sun, Oct 21, 2012 at 6:31 AM, Nick Coghlan ncogh...@gmail.com wrote:
 (Also, floats aren't reals and no computer can store any number that
 is not rational and we should stop pretending they can. (Complex
 numbers get a free pass because complex numbers with rational real
 and imaginary parts is not a memorable name for a type.))

 Floats are not rational either, since they allow infinities and NaN as
 values. Both float and Decimal are approximations to the Real number
 set, as int and Fraction are approximations to the Integer and
 Rational sets.

You're missing a step here. Are you claiming that the real numbers
have infinities or NaN?

Why do floats approximate the reals, while Fraction approximates the
rationals? After all, for any real number, a Fraction instance can
become arbitrarily close to it (given sufficient memory). The same is
not true of a float, which can only get to a relative distance of
machine epsilon, and then only when the real number is close to zero.
It would seem as if Fractions approximate the reals and rationals, and
floats do not approximate anything at all (at least, not arbitrarily
closely*).

* I think can be made arbitrarily close to the value in question is
the usual meaning of approximates in mathematics, but I'm not sure
about numerical computing (maybe it just means with sufficiently
small difference for values we care about?)

 In all cases, they cannot express the full scope of the
 associated numeric concept, because they're limited by their physical
 representations as bit patterns inside the computer (while that limit
 is technically available memory for the unbounded representations, the
 practical limit is lower than that if you want vaguely reasonable
 running times for arbitrary arithmetic operations).

There is a deeper difference in how badly we can represent the
rationals versus the reals. For an arbitrary rational number, we can
represent it precisely on a computer with sufficiently many bytes of
memory. That is not true for real numbers: the vast majority of real
numbers cannot be represented precisely in any form on a computer, no
matter how large it is. And while there are irrational numbers we can
represent precisely on a computer, floats don't represent any of them;
they only represent a selection of rational numbers, and nan/inf/-inf.

 As far as the conversion operators go, I don't recall there being any
 discussion one way or the other - the question simply never came up,
 presumably because all code tested already returned complex objects
 from __complex__.

That's a fair objection to what I said. I guess the discussion is here/now.

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

Re: [Python-Dev] return type of __complex__

[Devin Jeanpierre]

On Sat, Oct 20, 2012 at 10:57 PM, Nick Coghlan ncogh...@gmail.com wrote:
 PEP 3141 is indeed the driver for these changes, and it's based on the
 Python 3.x numeric tower consisting of strict supersets: Complex 
 Real  Rational  Integral

Pedant mode: That numeric tower is wrong as it applies to Python -- we
have some rational types that can represent some numbers that can't be
represented by our complex and real types.

 int(float(10**100)) == 10**100
False

(Also, floats aren't reals and no computer can store any number that
is not rational and we should stop pretending they can. (Complex
numbers get a free pass because complex numbers with rational real
and imaginary parts is not a memorable name for a type.))

*Pedant mode deactivated*

 If an operation at one level of the tower produces a result in one of
 the larger supersets, then *that's what it will do* rather than
 throwing TypeError. int / int promoting to float is one example, as is
 raising a negative number to a fractional power promoting to complex.

 The general philosophy is described in
 http://www.python.org/dev/peps/pep-3141/#implementing-the-arithmetic-operations

 It sounds like cmath (or, more specifically, the D conversion code)
 missed out on the associated updates).

No, no no. The return type of conversion methods has nothing to do
with the interoperability of types in arithmetic. If it did there
would've been a systematic purging of old behaviors in these
conversion functions, and there evidently hasn't been because float(),
cmath, and math all behave wrong, and those are collectively fairly
hard to miss.

Since float(), cmath, and math all behave the same, I'd assert that
it's complex() (and int()) that is weird and unusual.

 class A:
... def __complex__(self):
... return 1
... def __float__(self):
... return 1
...
 complex(A())
(1+0j)
 float(A())
Traceback (most recent call last):
  File stdin, line 1, in module
TypeError: __float__ returned non-float (type int)
 cmath.sqrt(A())
Traceback (most recent call last):
  File stdin, line 1, in module
TypeError: __complex__ should return a complex object
 math.sqrt(A())
Traceback (most recent call last):
  File stdin, line 1, in module
TypeError: nb_float should return float object


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

Re: [Python-Dev] return type of __complex__

[Devin Jeanpierre]

On Fri, Oct 19, 2012 at 10:13 AM, Nick Coghlan ncogh...@gmail.com wrote:
 On Fri, Oct 19, 2012 at 11:08 PM, Antonio Cuni anto.c...@gmail.com wrote:
 Is that the real intended behavior?

 Given the way complex numbers interact with floats generally,
 returning a complex number with no imaginary component as a floating
 point value seems legitimate and the checks in cmath overly strict.
 Otherwise you would get redundancy like:

 def __complex__(self):
 return complex(value)

 or

 def __complex__(self):
 return value + 0j

No you wouldn't:

def __float__(self):
return value

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

Re: [Python-Dev] Should vars() return modifiable dict?

[Devin Jeanpierre]

On Wed, Oct 3, 2012 at 11:34 AM, Steven D'Aprano st...@pearwood.info wrote:
 I find myself unable to choose between 2) and 4), which suggests that
 the status quo wins and we keep the current behaviour.

What is the benefit of having a dict that represents a namespace, but
whose mutations don't mutate said namespace? Compare with option 2,
where the dict is mutable, and whose mutations mutate the namespace it
represents. That behavior is altogether significantly less surprising.

I've never understood why locals() returned a mutable dictionary
either, except that Python has no immutable dictionary type.

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

Re: [Python-Dev] 2to3 porting HOWTO: setup.py question

[Devin Jeanpierre]

On Tue, Jul 24, 2012 at 6:07 AM, Michael Foord
fuzzy...@voidspace.org.uk wrote:
 This is not an ideal world and 2to3 is not good enough to convert files 
 without further intervention and testing.

 It is if you design your code *to be converted* by 2to3 and do regular 
 testing of the result.

That's hardly without testing!

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

Re: [Python-Dev] A new JIT compiler for a faster CPython?

[Devin Jeanpierre]

On Tue, Jul 17, 2012 at 6:20 PM, Victor Stinner
victor.stin...@gmail.com wrote:
 What is the status of LLVM nowadays? Is it not a good solution to
 write a portable JIT?

 I don't want to write my own library to generate machine code.

You don't have to, even if you don't want to use LLVM. There are
plenty of ligher-weight approaches to that. For example, GNU
Lightning [1] or sljit [2].

[1] http://www.gnu.org/software/lightning/
[2] http://sljit.sourceforge.net/

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

[Python-Dev] Poking about issue 1677

[Devin Jeanpierre]

Hi guys,

I just wanted to bring some more attention to issue #1677 , because I
feel it's important and misunderstood. See:
http://bugs.python.org/issue1677

The issue is that sometimes, if you press ctrl-c on Windows, instead
of raising a KeyboardInterrupt, Python will exit completely. Because
of this, any program that relies on ctrl-c/KeyboardInterrupt is not
guaranteed to work on windows. Also, working with the interactive
interpreter becomes really annoying for those with the habit of
deleting the whole input line via ctrl-c.

Some people that read the bug report think that this only happens if
you hold down ctrl-c long enough or fast enough or some such thing.
That's not so; it can happen just from pressing ctrl-c once. Whatever
race condition here is not related to the timing gaps between presses
of ctrl-c. The test cases of hold down ctrl-c for a bit are to
conveniently reproduce, not a description of the problem.

Hope this was the right place. #python-dev encouraged me to post here,
so, yeah. And thanks for all your hard work making Python a pleasant
place to be. :)

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