On Mon, Dec 18, 2017 at 07:37:03PM -0800, Nathaniel Smith wrote:
> On Mon, Dec 18, 2017 at 7:02 PM, Barry Warsaw wrote:
> > On Dec 18, 2017, at 21:11, Chris Barker wrote:
> >
> >> Will changing pprint be considered a breaking change?
> >
> > Yes, definitely.
>
> Wait, what? Why would changing pp
On Mon, Dec 18, 2017 at 08:28:52PM -0800, Chris Barker wrote:
> On Mon, Dec 18, 2017 at 7:41 PM, Steven D'Aprano
> wrote:
>
> > > With arbitrary order, it made sense to sort, so as to always give the
> > same
> > > "pretty" representation.
What is the best practice for revisiting old enhancement requests on the
tracker, if I believe that the time is right to revisit a rejected issue
from many years ago? (Nearly a decade.)
Should I raise a new enhancement request and link back to the old one,
or re-open the original?
Thanks,
On Tue, Dec 19, 2017 at 04:56:16PM -0800, Steve Dower wrote:
> On 19Dec2017 1004, Chris Barker wrote:
> >(though I assume order is still ignored when comparing dicts, so:
> >eval(pprint(a_dict)) == a_dict will still hold.
>
> Order had better be ignored when comparing dicts, or plenty of code wi
On Mon, Dec 18, 2017 at 08:49:54PM -0800, Nathaniel Smith wrote:
> On Mon, Dec 18, 2017 at 7:58 PM, Steven D'Aprano wrote:
> > I have a script which today prints data like so:
[...]
> To make sure I understand, do you actually have a script like this, or
> is this hypothetic
On Wed, Dec 20, 2017 at 03:23:16PM -0800, Chris Barker wrote:
> On Wed, Dec 20, 2017 at 2:31 AM, Steven D'Aprano
> wrote:
> > Even when it works, the guarantee is quite weak. For instance, even
> > the object type is not preserved:
> >
> > py> class MyDict(
On Sun, Dec 31, 2017 at 09:07:01AM -0800, Nathaniel Smith wrote:
> This is another reason why we ought to let users do their own IDNA handling
> if they want...
I expect that letting users do their own IDNA handling will correspond
to not doing any IDNA handling at all.
--
Steve
On Sun, Dec 31, 2017 at 05:51:47PM -0800, Nathaniel Smith wrote:
> On Sun, Dec 31, 2017 at 5:39 PM, Steven D'Aprano wrote:
> > On Sun, Dec 31, 2017 at 09:07:01AM -0800, Nathaniel Smith wrote:
> >
> >> This is another reason why we ought to let users do their own ID
On Sat, Jan 13, 2018 at 09:00:07PM +0100, Christian Heimes wrote:
> You'd be surprised how many tools and programs are using Python these
> days. You can easily break important user programs by installing a
> package with --user.
Or by writing a Python script and innocently giving it the same nam
On Sat, Jan 13, 2018 at 02:23:19PM +0100, Antoine Pitrou wrote:
> On Sat, 13 Jan 2018 13:54:33 +0100
> Christian Heimes wrote:
> >
> > If we agree to drop support for OpenSSL 0.9.8 and 1.0.1, then I can land
> > bunch of useful goodies like proper hostname verification [2], proper
> > fix for IP
On Sun, Jan 14, 2018 at 11:10:33AM +0300, joannah nanjekye wrote:
[...]
> Is this sort of method name duplication important in any cases?
Yes. For example, inside a class:
class MyClass(object):
@property
def something(self):
pass
@something.setter
def something(self):
On Tue, Jan 30, 2018 at 06:00:36PM +, Paul Moore wrote:
> On 30 January 2018 at 17:10, Antoine Pitrou wrote:
> >
> > This is missing a bit of context. Is this about python-dev? Some
> > other ML?
>
> While I'll admit to being curious about what prompted this, honestly,
> it's none of my bus
On Wed, Jan 31, 2018 at 03:04:04PM +, Oleg Sivokon wrote:
> Now, since Go won't compile with MSVC
[...]
Perhaps you should be asking Google why Go doesn't support the most
popular C compiler on Windows.
--
Steve
___
Python-Dev mailing list
Pytho
On Fri, Feb 02, 2018 at 01:53:00AM -0500, Terry Reedy wrote:
> >>> object.__doc__
> 'The most base type'
[...]
> I have suggested
> "The superclass for all Python classes."
> "The starting base class of all types and classes other than itself."
>
> I intended to pick the second, but Serhiy Storcha
On Sat, Feb 03, 2018 at 12:50:11AM -0500, Terry Reedy wrote:
> On 2/2/2018 7:01 PM, asrp asrp wrote:
> >I don't know if this is the right place to post this. Please redirect as
> >needed.
>
> This list is for development *of* cpython. Development *with* python in
> general belongs on python-lis
On Sat, Feb 03, 2018 at 01:01:30AM +0100, asrp asrp wrote:
> I've made a small Python interpreter in Python with runtime AST node
> semantics and edit-and-continue. I thought it could make prototyping
> language changes more easily and visualize usage before writing them
> in C.
That sounds in
On Sun, Feb 04, 2018 at 09:18:25PM -0800, Guido van Rossum wrote:
> The way I think of it generally is that immutability is a property of
> types, while hashability is a property of values.
That's a great way to look at it, thanks.
--
Steve
___
Pytho
On Mon, Feb 05, 2018 at 12:09:52AM -0600, Chris Barker wrote:
> But a bit more detail -- I'm commenting on the API, not the capability -
> that is, since users often equate hashable and immutability, they will
> expect that if they say hash=True, then will get an immutable, and if they
> say froze
On Sat, Feb 03, 2018 at 11:45:15AM +0100, asrp wrote:
> > Can you give an example of how you would do that? I don't mean the
> > mechanism used, I mean how would a developer implement a new syntactic
> > feature. Suppose I wanted to add a new clause to for...else, let's say:
> >
> > for ...
On Mon, Feb 05, 2018 at 10:50:21AM -0800, David Mertz wrote:
> Absolutely I agree. 'unsafe_hash' as a name is clear warning to users.
(I don't mean to pick on David specifically, I had to reply to some
message in this thread and I just picked his.)
I'm rather gobsmacked at the attitudes of many
On Mon, Feb 19, 2018 at 07:02:42PM -0800, Guido van Rossum wrote:
> On Mon, Feb 19, 2018 at 5:06 PM, Chris Barker - NOAA Federal <
> chris.bar...@noaa.gov> wrote:
[...]
> > This seems another use case — maybe it would be helpful to be able to
> > freeze an instance after creation for multiple use-
On Fri, Feb 23, 2018 at 11:23:04AM -0800, Chris Barker wrote:
> But I still think the original:
>
> [g(y) for x in range(5) for y in [f(x)]]
>
> Is always going to be confusing to read. Though I do agree that it's not
> too bad when you unpack it into for loops:
>
> In [89]: for x in range(5):
On Mon, Mar 12, 2018 at 09:49:27AM -0700, Raymond Hettinger wrote:
> * We already have a simple, traditional, portable, and readable way to
> make the test: int(x) == x
Alas, the simple way is not always the correct way:
py> x = float('inf')
py> x == int(x)
Traceback (most recent call last):
On Wed, Mar 21, 2018 at 12:32:11AM +, Chris Barker wrote:
> Could float et al. add an __index__ method that would return a ValueError
> if the value was not an integer?
That would allow us to write things like:
"abcdefgh"[5.0]
which is one of the things __index__ was invented to prevent.
On Wed, Mar 21, 2018 at 10:31:19AM +, Chris Barker wrote:
> On Wed, Mar 21, 2018 at 4:42 AM Steven D'Aprano wrote:
> > > Could float et al. add an __index__ method that would return a ValueError
> > > if the value was not an integer?
> >
> > Th
On Wed, Mar 21, 2018 at 09:46:06AM -0700, Nathaniel Smith wrote:
[...]
> For me this is an argument against is_integer() rather than for it :-).
> is_prime(float) should *obviously*[1] be a TypeError. Primality is only
> meaningfully defined over the domain of integers
And 3.0 is an integer. Just
On Sat, Mar 24, 2018 at 02:18:14PM +, Tin Tvrtković wrote:
> self.__dict__ = {'a': a, 'b': b, 'c': c}
>
> i.e. to replace the instance dictionary altogether. On PyPy, their core
> devs inform me this is a bad idea because the instance dictionary is
> special there, so we won't be doing t
Hi Julia, and welcome!
On Wed, Mar 28, 2018 at 09:14:53PM -0700, Julia Kim wrote:
> My suggestion is to change the syntax for creating an empty set and an
> empty dictionary as following.
>
> an_empty_set = {}
> an_empty_dictionary = {:}
>
> It would seem to make more sense.
Indeed it would,
On Wed, Mar 28, 2018 at 06:27:19PM +0300, Serhiy Storchaka wrote:
> The optimizer already changes
> semantic. Non-optimized "if a and True:" would call bool(a) twice, but
> optimized code calls it only once.
I don't understand this. Why would bool(a) be called twice, and when did
this change?
On Wed, Mar 28, 2018 at 06:27:19PM +0300, Serhiy Storchaka wrote:
> 2. Change the semantic of f-strings. Make it closer to the semantic of
> str.format(): evaluate all subexpressions first than format them. This
> can be implemented in two ways:
>
> 2a) Add additional instructions for stack man
On Fri, Mar 30, 2018 at 01:29:53PM +0300, Serhiy Storchaka wrote:
> 29.03.18 18:06, Terry Reedy пише:
> >On 3/28/2018 11:27 AM, Serhiy Storchaka wrote:
> >>The optimizer already changes semantic. Non-optimized "if a and True:"
> >>would call bool(a) twice, but optimized code calls it only once.
>
Hi Amar, and welcome.
You might find that you get a more productive response if you write a
meaningful subject line and actually tell us what the PRs are about.
Nobody has the time or interest to look at every single PR, so if you
want to bring your PRs to the attention of those who will care a
On Fri, Apr 06, 2018 at 06:02:18PM -0400, Ned Deily wrote:
> I suggest we consider at a minimum adding a "See also:" note
> referencing cmd2 to the cmd documentation in the Standard Library
> document, similar to what we do for the third-party "requests" module
> in the "urllib.request" documen
On Sat, Apr 07, 2018 at 09:30:05AM +0100, Paul Moore wrote:
> On 7 April 2018 at 04:13, Steve Dower wrote:
> > Better to deprecate it before it becomes broken, in my opinion.
That argument could be applied to everything in the std lib.
> > Having someone willing and able to review and merge cha
On Sat, Apr 07, 2018 at 02:50:00PM -0400, Chris Barker - NOAA Federal wrote:
> Is bringing cmd2 into the standard library an option to be considered?
That is discussed on the tracker. The short answer is, yes, it is
considered, but no, cmd2 is not ready to come into the std lib. I
recommend you
On Sat, Apr 07, 2018 at 06:53:44PM +, Brett Cannon wrote:
> > Raymond has stated that he is happy to work on it if there are any bugs
> > reported on it, and if he's not available, I'm sure somebody will.
>
> Actually Raymond said he *teaches* the module, not that he wanted to
> maintain it.
On Wed, Apr 11, 2018 at 08:21:01AM -0300, Joao S. O. Bueno wrote:
> I just came across a code snippet that
> would define a method with the "__dict__" name - like in:
>
> class A:
> def __dict__(self):
> return ()
That's a strange thing to do, but I don't think it ought to be illega
On Wed, Apr 18, 2018 at 10:13:58AM +1000, Chris Angelico wrote:
[regarding comprehensions]
> The changes here are only to edge and corner cases, other than as they
> specifically relate to assignment expressions. The current behaviour
> is intended to "do the right thing" according to people's
>
On Sat, Apr 21, 2018 at 12:30:36PM +1000, Chris Angelico wrote:
> There's that word "readability" again. Sometimes I wish the Zen of
> Python didn't use it, because everyone seems to think that "readable"
> means "code I like".
In fairness, if one can't read code, then one can hardly be expected
On Sat, Apr 21, 2018 at 05:46:44PM +1000, Chris Angelico wrote:
> On Sat, Apr 21, 2018 at 5:11 PM, Steven D'Aprano wrote:
> > So can you explain specifically what odd function-scope behaviour you
> > are referring to? Give an example please?
>
> doubled_items = [x fo
On Sat, Apr 21, 2018 at 03:44:48PM +, David Mertz wrote:
> It feels very strange that the PEP tries to do two almost entirely
> unrelated things. Assignment expressions are one thing, with merits and
> demerits discussed at length.
>
> But "fixing" comprehension scoping is pretty much complet
On Sun, Apr 22, 2018 at 12:45:36AM +1000, Chris Angelico wrote:
> > The reason I want items to "leak" into the surrounding scope is mostly
> > so that the initial value for it can be set with a simple assignment
> > outside the comprehension:
> >
> > items = (1, 2, 3)
> > [ ... items := it
On Sat, Apr 21, 2018 at 08:35:51PM +0100, Matthew Woodcraft wrote:
> Well, that's a reason to make the example a bit more realistic, then.
>
> Say:
>
> if match := re.search(pat1, text):
> do_something_with(match.group(0))
> elif match := re.search(pat2, text):
> do_something_else_with(m
On Mon, Apr 23, 2018 at 03:36:10PM -0700, Guido van Rossum wrote:
> Using 'as' was debated extensively on python-ideas. I don't like it for
> several reasons:
[...]
For what it is worth, I was one of the original proponents of the "as"
syntax, but at this point I am no longer going to argue for i
On Tue, Apr 24, 2018 at 09:50:34AM -0400, Yury Selivanov wrote:
> On Tue, Apr 24, 2018 at 9:46 AM, Nick Coghlan wrote:
> > On 24 April 2018 at 23:38, Yury Selivanov wrote:
> >> I propose to use the following syntax for assignment expressions:
> >>
> >> ( NAME = expr )
> >>
> >> I know that it
On Tue, Apr 24, 2018 at 11:03:35AM -0400, Yury Selivanov wrote:
> My point was that when you see lots of '=' and ':=' used at the
> statement level, one might try to write "if x = 1" instead of "if x :=
> 1" -- boom, we have an unexpected SyntaxError for some users.
That's a *good* thing. They wi
On Tue, Apr 24, 2018 at 11:05:57AM -0400, Yury Selivanov wrote:
> Well, `my_func(a=(b:=foo))` or `my_func(b:=foo)` are also barely
> readable to my eye.
There's no advantage to using binding-expressions unless you're going to
re-use the name you just defined, and that re-use will give you a hint
On Tue, Apr 24, 2018 at 10:58:24AM -0400, Yury Selivanov wrote:
> Since 'diff' and 'g' must be new names according to rule (3), those
> who read the code will notice that both were not previously bound.
How am I supposed to notice that they've never been bound without
carefully reading through t
On Tue, Apr 24, 2018 at 11:25:58AM -0400, Yury Selivanov wrote:
> No, it doesn't. The check is performed during compile phase, and
> Python does not unroll loops. Anyways, read below.
What does unrolling loops have to do with anything? And besides, loop
unrolling is an implementation detail -- m
On Tue, Apr 24, 2018 at 11:35:20AM -0400, Yury Selivanov wrote:
> Yes, it would force users to come up with better names *iff* they want
> to use this new sugar:
>
> if (first_target = get_first_candidate()) ...
> elif (second_target = get_second_candidate()) ...
They're not better names. Ad
On Wed, Apr 25, 2018 at 02:42:08AM +1000, Chris Angelico wrote:
> > from math import *
> > process(arg, (pi = 1), pi+1) # allowed
> That's not allowed at local scope (at least, it's not allowed at
> function scope - is there any other "local scope" at which it is
> allowed?).
Of cours
On Tue, Apr 24, 2018 at 10:42:35PM +0200, Sven R. Kunze wrote:
> gcd(diff, n) is to me a perfect name, and please don't tell me g is
> better. ;)
Sorry, gcd(diff, n) is not the "perfect name", and I will tell you that
sometimes g is better.
Which would you prefer to see and read?
g = gcd(diff
On Tue, Apr 24, 2018 at 10:29:11PM +0100, Anthony Flury via Python-Dev wrote:
> If Python is going to do assignment expressions we shouldn't overload
> parens in my opinion - we should have a separate operator - doing this
> avoids needing to exclude rebinding, and makes such expressions
> cons
On Tue, Apr 24, 2018 at 08:10:49PM -0500, Tim Peters wrote:
> Binding expressions are debugger-friendly in that they _don't_ just
> vanish without a trace. It's their purpose to _capture_ the values of
> the expressions they name. Indeed, you may want to add them all over
> the place inside expr
On Tue, Apr 24, 2018 at 03:54:30PM -0700, Guido van Rossum wrote:
> We should really take this back to python-ideas at this point.
Please no :-(
Variants of "let" etc were discussed earlier and didn't seem to get much
interest. Although I don't think "var" specifically was suggested
before, "l
On Tue, Apr 24, 2018 at 11:55:16PM -0700, Nathaniel Smith wrote:
> These examples all make me very nervous. The order of execution in
> comprehensions is pretty confusing to start with (right to left,
> except when it's left to right!).
I don't think comprehensions are ever right to left. With on
On Wed, Apr 25, 2018 at 01:55:37PM -0700, Łukasz Langa wrote:
>
> > On 25 Apr, 2018, at 1:28 PM, Guido van Rossum wrote:
> >
> > You don't seem to grasp the usability improvements this will give. I hear
> > you but at this point appeals to Python's "Zen" don't help you.
>
> This reads dismissi
On Wed, Apr 25, 2018 at 09:36:31PM -0500, Ryan Gonzalez wrote:
>
>
> I have to say I'm not overly thrilled with PEP 572...it's almost odd,
> because if you asked me back when I first joined this list when I was 13, I
> would've no doubt said *YES*.
I have the opposite experience: I've warmed t
On Thu, Apr 26, 2018 at 05:22:58PM +1200, Greg Ewing wrote:
> Łukasz Langa wrote:
> >What was its own assignment before
> >now is part of the logic test. This saves on vertical whitespace but makes
> >parsing and understanding logic tests harder.
>
> Another way to say this is that expressions are
On Wed, Apr 25, 2018 at 10:14:11PM -0700, Łukasz Langa wrote:
> So only use the Pascal one in expressions. But don't forget
> parentheses, otherwise it will bind the thing you probably didn't want
> anyway.
Binding expressions are no worse than any other expression: sometimes
you need to brack
On Thu, Apr 26, 2018 at 07:16:28PM +1200, Greg Ewing wrote:
> Tim Peters wrote:
> >As a statement in a program (as opposed to typed at a shell),
> >"a := 3" has the unnecessary (in that context) property of returning
> >(and discarding 3), so it's better style to use "a = 3" in that
> >context.
>
On Thu, Apr 26, 2018 at 03:31:13AM -0400, Terry Reedy wrote:
> On 4/25/2018 8:20 PM, Chris Angelico wrote:
> >On Thu, Apr 26, 2018 at 10:11 AM, Yury Selivanov
> > wrote:
> >>Just yesterday this snippet was used on python-dev to show how great the
> >>new syntax is:
> >>
> >> my_func(arg,
On Thu, Apr 26, 2018 at 10:17:34AM +0200, Antoine Pitrou wrote:
> I also wonder how long it will be before someone writes:
>
> def f(arg):
> global _lazy_value
> if predicate(arg) and (_lazy_value := frobnicate()) > arg:
> ...
>
> (or something similar with "nonlo
On Thu, Apr 26, 2018 at 10:34:29PM +1200, Greg Ewing wrote:
> Antoine Pitrou wrote:
> >Well, how do languages where assignment is an expression returning the
> >assigned value make their REPLs work? I'm sure they don't inflict that
> >on their users, so it's certainly a solvable problem.
>
> I ca
Hi Fatty, and welcome!
On Thu, Apr 26, 2018 at 08:00:55PM +0200, Fatty Morgan wrote:
> The natural interpretation of 'name := expr' is a PEP 526
> type-annotated variable initialization 'name : T = expr' with the
> type annotation T omitted, the tokens ':' and '=' coalesced, and
> the implied typ
On Thu, Apr 26, 2018 at 09:36:48AM -0700, Mike Miller wrote:
> However, there were two good questions in this message which I haven't seen
> addressed yet:
>
> - How are other modern languages solving this issue?
> - How does this new construct intersect with typing functionality?
What
On Thu, Apr 26, 2018 at 08:00:46PM +0100, Zero Piraeus wrote:
> Since it now looks like it really *does* have a decent chance, and
> maybe another -1 has a small chance of tipping the balance: my
> reaction to the proposal is also emotional. Visceral, in fact, to the
> extent that I'd aim to read
On Thu, Apr 26, 2018 at 08:48:12AM -0700, Łukasz Langa wrote:
>
> > On Apr 25, 2018, at 11:10 PM, Steven D'Aprano wrote:
> > Criticising binding-
> > expressions for that reason, especially implying that we must always use
> > parens, is simply FUD.
>
On Fri, Apr 27, 2018 at 08:13:20AM +0200, Andrea Griffini wrote:
> >> We're focused on Python 3.8 and 3.9, not Python 5 or Python 6.
>
> Hmmm... When I was hearing the repeated belated saying that Python
> will never ever jump on the statically typed ship on each and every
> static type annotat
On Fri, Apr 27, 2018 at 04:24:35PM -0400, Wes Turner wrote:
> if ((1) or (x := 3)):
> if ((y := func(x)) if x else (x := 3))
Wes, there is *absolutely nothing new* here. This sort of error is
already possible in Python.
Do you see a lot of code like:
if (1 or sequence.append(3) or sequence
On Fri, Apr 27, 2018 at 10:56:06PM +1000, Nick Coghlan wrote:
> On 27 April 2018 at 22:28, Steven D'Aprano wrote:
>
> > On Fri, Apr 27, 2018 at 08:13:20AM +0200, Andrea Griffini wrote:
> > > Now we got standard library features requiring type annotation
> >
>
On Mon, Apr 30, 2018 at 08:09:35AM +0100, Paddy McCarthy wrote:
[...]
> A PEP that can detract from readability; *readability*, a central
> tenet of Python, should
> be rejected, (on principle!), when such objections are treated so
> dismissively.
Unless you have an objective measurement of reada
On Mon, Apr 30, 2018 at 05:27:08PM -0700, Larry Hastings wrote:
>
> On 04/30/2018 07:30 AM, Mark Shannon wrote:
> >Would Python be better with two subtly different assignment operators?
> >The answer of "no" seems self evident to me.
>
> Maybe this has been covered in the thread earlier--if so, I
On Tue, May 01, 2018 at 11:04:55AM +1000, Chris Angelico wrote:
> To be fair, I don't see many people replacing "x = 1" with "for x in
> [1]: pass". Even though it IS going to have the same effect. :-)
Aside from the pass, that is precisely one of the current work-arounds
for lack of binding-exp
On Thu, May 03, 2018 at 12:01:53AM +0200, Antoine Pitrou wrote:
> On Wed, 2 May 2018 22:54:04 +0100
> Paul Moore wrote:
> > Nor do I think the tone of his message here is acceptable - regardless
> > of how annoyed he is, posting insults ("no-one gives a damn") about
> > volunteer contributors in
On Thu, May 03, 2018 at 07:39:05AM +0200, Matěj Cepl wrote:
> I have my doubts about IDLE though. I know, the same
> argument applies, but really, does anybody use IDLE for
> development for long time
Yes, tons of beginners use it. On the tutor and python-list mailing
lists, there are plenty o
On Fri, May 04, 2018 at 12:56:57PM +0200, Victor Stinner wrote:
> Sorry, when I wrote "Python 4" I mean "the new Python release which
> introduces a lot of backward incompatible changes and will annoy
> everyone". It can be Python 3.9 or 3.10, or whatever version
> (including 4.3 if you want) :-)
On Thu, May 03, 2018 at 06:31:03PM +, Brett Cannon wrote:
> No one is saying people can't be upset and if you are ever upset there's
> something wrong; we're human beings after all. But those of us speaking up
> about the tone are saying that you can also wait until you're not so upset
> to wr
On Fri, May 04, 2018 at 09:04:20AM -0700, Guido van Rossum wrote:
> Thank you Steven! I assume that Brian hadn't seen my response (such crossed
> messages due to delivery delays are very common in this mailing list).
>
> I'd like to use your email (nearly) verbatim to st
On Fri, May 04, 2018 at 03:21:28PM -0400, Terry Reedy wrote:
> On 5/4/2018 11:43 AM, Steven D'Aprano wrote:
>
> >I'm not defending Ivan's initial email. His tantrum *was* annoying,
> >unreasonable, and unfair to those who do care about tkinter.
>
>
On Sun, May 06, 2018 at 11:09:21AM +1000, Chris Angelico wrote:
> What exactly didn't work? I don't understand.
https://bugs.python.org/issue33412
--
Steve
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/py
On Tue, May 08, 2018 at 03:20:50PM +0200, Stéphane Blondon wrote:
> I wonder if it would be interesting to have a package available by
> pypi.org which would provide the removed features.
[...]
> Cons:
> - it pushes the question to how many times the previous behavior should
> be maintained from
On Mon, May 07, 2018 at 10:21:13AM -0700, Glenn Linderman wrote:
> Dan's original comment about language versus library is interesting,
> though. It is probably true that one should resist adding language where
> library suffices, but sometimes a lack of certain expressiveness in the
> language
On Mon, May 07, 2018 at 10:23:32PM +0200, Antoine Pitrou wrote:
> On Mon, 07 May 2018 19:19:28 +
> Ryan Gonzalez wrote:
> > 10 years feels like a simultaneously long and arbitrary limit. IMO a policy
> > of "try to avoid major language features for a while" would work better.
>
> I would remo
On Wed, May 09, 2018 at 01:35:53PM +0200, Antoine Pitrou wrote:
> > > I would remove "for a while". "Try to avoid major language features"
> > > sounds good.
> >
> > It sounds good, until you ask about "What if we had that policy from
> > the beginning?"
[...]
> "Try to avoid" would make it m
On Fri, May 11, 2018 at 11:15:11AM -0700, Chris Barker - NOAA Federal via
Python-Dev wrote:
> > while the changes introduced by Python 3
> > affect pretty much everyone, even people who only write small simple
> > scripts.
>
> Sure they do, but the *hard stuff* not so much.
>
> I have found 2to3
On Tue, May 15, 2018 at 10:55:07PM -0700, Chris Jerdonek wrote:
> What does “no release at all” mean? If it’s not released, how would people
> use it?
I've been using Python 1.7 for years now. It is the perfect Python, with
exactly all the features I want, and none that I don't want, and so much
Stephan Houben noticed that Python apparently allows identifiers to be
keywords, if you use Unicode "mathematical bold" letters. His
explanation is that the identifier is normalised, but not until after
keywords are checked for. So this works:
class Spam:
locals()['if'] = 1
Spam.𝐢𝐟# U
On Mon, Jun 04, 2018 at 07:25:49PM +0200, Matěj Cepl wrote:
> On 2018-06-04, 16:06 GMT, Guido van Rossum wrote:
> > I don't see how this *increases* the uncertainty. Surely if
> > GitHub had remained independent there would have been be
> > similar concerns about how it would make enough money to
On Wed, Jun 06, 2018 at 05:59:17PM -0700, Chris Jerdonek wrote:
> Is the “service” they provide (and what it needs) allowed to change over
> time, so that the rights granted can expand?
Of course it can change. And they might not even need to give us notice.
But that's no different from any othe
On Thu, Jun 07, 2018 at 06:02:40PM +0100, MRAB wrote:
> The Python community _is_ meant to be inclusive, and we should support
> the addition of ginger emoijs. :-)
https://www.youtube.com/watch?v=KVN_0qvuhhw
--
Steve
___
Python-Dev mailing list
Pyth
On Thu, Jun 21, 2018 at 02:33:27PM +0300, Ivan Pozdeev via Python-Dev wrote:
> First, tell us what problem you're solving.
You might not be aware of the context of Jereon's question. He is the
author of PEP 579 and 580, so I expect he's looking into implementation
details of the CPython builtin
On Fri, Jun 22, 2018 at 08:13:44AM -0700, Guido van Rossum wrote:
> Honestly it looks to me like the status quo is perfect.
Does this example work for you?
py> (17.1).hex == (17.1).hex
True
But:
py> a = 17.1
py> b = 17.1
py> a.hex == b.hex
False
I know why it happens -- at the REPL, the inter
On Fri, Jun 22, 2018 at 11:44:07AM -0700, Guido van Rossum wrote:
[...]
> > I know why it happens -- at the REPL, the interpreter uses the same
> > object for both 17.1 instances when they're part of the same statement,
> > but not when they're on separate lines. I just don't know whether this
> >
On Fri, Jun 22, 2018 at 11:28:45AM -0700, Chris Barker via Python-Dev wrote:
> On Fri, Jun 22, 2018 at 10:09 AM, Michael Selik wrote:
>
> > I forgot to add that I don't anticipate changing my lesson plans if this
> > proposal is accepted. There's already not enough time to teach everything
> > I'
On Fri, Jun 22, 2018 at 10:59:43AM -0700, Michael Selik wrote:
> > > I've started testing the proposed syntax when I teach. I don't have a
> > > large
> > > sample yet, but most students either dislike it or don't appreciate the
> > > benefits. They state a clear preference for shorter, simpler li
On Sat, Jun 23, 2018 at 12:22:33AM +1000, Nick Coghlan wrote:
[...]
> * for the reactions to my description of the currently proposed parent
> local scoping behaviour in comprehensions, I'd use the word
> "horrified", and feel I wasn't overstating the response :)
Without knowing how you worded th
On Fri, Jun 22, 2018 at 09:08:37PM -0700, Chris Barker wrote:
> > So if you absolutely need to teach it to a beginner, it
> > shouldn't be difficult once they understand the difference between an
> > expression and a statement.
> >
>
> probably not, though that's a distinction that's mostly acade
On Sun, Jun 24, 2018 at 02:33:59PM +1000, Nick Coghlan wrote:
> Given that PEP 572 *is* proposing implicit comprehension state export,
"Implicit" and "explicit" are two terms which often get misused to mean
"I don't like it" and "I do like it".
Making the intentional choice to use an assignment
On Sun, Jun 24, 2018 at 03:56:47PM +1000, Steven D'Aprano wrote:
> There is no consensus that the change to comprehensions was a good thing
> or justified.
On re-reading that, I think its wrong -- it wasn't really what I
intended to say. What I intended to say was, in hind
101 - 200 of 1900 matches
Mail list logo
