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.
> >
>
> 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 htt
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 f
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
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?
> > >
> > >
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 no
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
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
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
> [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
on/cpython/pull/2878
-- Devin
On Tue, Jul 25, 2017 at 9:59 PM, Devin Jeanpierre
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
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
_
> 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
> 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 probab
On Thu, Jun 23, 2016 at 8:19 AM, Guido van Rossum wrote:
>
> It was a long time when I wrote this, but IIRC the breakage could express
> itself as a segfault or other C-level crash due to some internal state
> invariant of the type object being violated, not just an exception. The
> existence of c
On Thu, Apr 30, 2015 at 6:13 PM, Greg 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 whet
On Sun, Oct 26, 2014 at 3:41 PM, Paul Moore 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
On Thu, Sep 25, 2014 at 4:53 PM, Antoine Pitrou 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 pa
On Sun, Aug 17, 2014 at 7:14 PM, Alex Gaynor 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 ou
On Sat, Aug 16, 2014 at 12:25 AM, Ben Finney wrote:
> Steven D'Aprano 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 valu
On Tue, Aug 12, 2014 at 8:12 AM, Guido van Rossum wrote:
> On Tue, Aug 12, 2014 at 3:43 AM, Devin Jeanpierre
> wrote:
>> The parentheses seem unnecessary/redundant/weird. Why not allow
>> newlines in-between "with" and the terminating ":"?
>>
>>
I think this thread is probably Python-Ideas territory...
On Mon, Aug 11, 2014 at 4:08 PM, Allen Li 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:
>
> w
On Sat, Aug 9, 2014 at 12:20 PM, Alexander Belopolsky
wrote:
>
> On Sat, Aug 9, 2014 at 1:08 AM, Steven D'Aprano 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
On Wed, Jul 16, 2014 at 6:37 AM, R. David Murray 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 p
ch on windows, or too much on
linux), if you want only a subset of the files' lstat info.
-- Devin
P.S. your mail client's quoting breaks my mail client (gmail)'s quoting.
On Mon, Jun 30, 2014 at 7:04 PM, Glenn Linderman wrote:
> On 6/30/2014 4:25 PM, Devin Jeanpierre wrote:
&
On Mon, Jun 30, 2014 at 3:07 PM, Tim Delaney
wrote:
> On 1 July 2014 03:05, Ben Hoyt 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
On Sun, Apr 20, 2014 at 8:01 PM, Cameron Simpson wrote:
> On 20Apr2014 14:32, Mark Lawrence 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 si
On Sun, Apr 20, 2014 at 12:27 PM, Kristján Valur Jónsson
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
> acad
On Mon, Jan 27, 2014 at 5:21 AM, Victor Stinner
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.
On Thu, May 23, 2013 at 6:40 PM, Steven D'Aprano 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 he
On Thu, May 23, 2013 at 2:04 AM, Antoine Pitrou wrote:
> On Thu, 23 May 2013 12:12:26 +1000
> Nick Coghlan 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 singl
On Thu, Apr 25, 2013 at 9:12 PM, MRAB 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 argumen
On Mon, Apr 22, 2013 at 7:39 AM, Calvin Spealman 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 se
On Fri, Apr 12, 2013 at 4:39 AM, Antoine Pitrou 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" unde
On Sat, Mar 23, 2013 at 11:21 AM, Nick Coghlan 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
On Thu, Mar 21, 2013 at 2:42 AM, Terry Reedy 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 polish
On Thu, Dec 13, 2012 at 9:38 PM, Eric Snow 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://
On Nov 6, 2012 1:05 PM, "Ned Batchelder" wrote:
>
> On 11/6/2012 11:26 AM, R. David Murray wrote:
>>
>> On Tue, 06 Nov 2012 18:14:38 +0200, Serhiy Storchaka
wrote:
>>>
>>> Another counterintuitive (and possible wrong) example:
>>>
>>> >>> {print('foo'): print('bar')}
>>> bar
>>> foo
>
On Tue, Nov 6, 2012 at 1:18 AM, Chris Withers 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
On Mon, Oct 22, 2012 at 7:34 AM, Larry Hastings 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/mailma
I guess I was asking for this. (Sorry for OT conversation.)
On Sun, Oct 21, 2012 at 6:31 AM, Nick Coghlan 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
On Sat, Oct 20, 2012 at 10:57 PM, Nick Coghlan 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
h
On Fri, Oct 19, 2012 at 10:13 AM, Nick Coghlan wrote:
> On Fri, Oct 19, 2012 at 11:08 PM, Antonio Cuni 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 val
On Wed, Oct 3, 2012 at 11:34 AM, Steven D'Aprano 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 namespac
On Tue, Jul 24, 2012 at 6:07 AM, Michael Foord
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
On Tue, Jul 17, 2012 at 6:20 PM, Victor Stinner
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-
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
47 matches
Mail list logo
