On 8 September 2016 at 16:59, Arek Bulski wrote:
>> You've probably spent way more time debating shuffled here than you would
>> have needed to add a shuffled function to your test file.
>
> Another presupposition. I did add it to my utility. I am proposing to add
> this to the std library so that
On 10 September 2016 at 18:26, Guido van Rossum wrote:
> IMO the key syntax is
> simply one for accessing attributes returning None instead of raising
> AttributeError, so that e.g. `foo?.bar?.baz` is roughly equivalent to
> `foo.bar.baz if (foo is not None and foo.bar is not None) else None`,
> e
On 11 September 2016 at 10:36, Dominik Gresch wrote:
> I've recently found myself writing code similar to this:
>
> for i in range(10):
> if i == 5:
> continue
> "body"
>
> which I find a bit ugly.
I write code like this quite frequently. However, unlike you I don't
find it partic
On 12 September 2016 at 21:47, Eric Snow wrote:
> Note that there's a subtle difference here when multiple lookups are
> involved. Given:
>
> def f(spam):
> return spam().eggs().ham
>
> With null-coalescing:
>
> def f(spam):
> return spam()?.eggs()?.ham
>
> This is roughly
On 13 September 2016 at 17:29, Chris Angelico wrote:
> On Wed, Sep 14, 2016 at 2:16 AM, Pim Schellart
> wrote:
>> Semantics
>> =
>>
>> The following two snippets are semantically identical::
>>
>> continue class A:
>> x = 5
>> def foo(self):
>> pass
>> def ba
On 14 September 2016 at 12:51, Chris Angelico wrote:
> Perhaps the advice needs to be along the lines of: Decide what the
> purpose of the enum is, and follow a naming convention accordingly.
> Uppercase if you're basically making constants; lowercase if you're
> not; etcetera.
Agreed - it's not
On 16 September 2016 at 14:22, אלעזר wrote:
> P.S. how do I change the name in my quotes? I believe אלעזר is not very easy
> to address...
As you're posting from a gmail account, it's likely your name from
personal info in your Google Accounts settings. Your mail client (if
it's not the gmail web
On 17 September 2016 at 11:55, João Matos wrote:
> If Py3.5 is installed in user mode instead of admin (all users) and we
> follow your advice that we shouldn't add it to the PATH env var, we can
> execute Python using the py launcher, but we can't use pip.
> Please consider adding a pip symlink i
On 19 September 2016 at 03:40, Chris Angelico wrote:
> On Mon, Sep 19, 2016 at 12:32 PM, Steven D'Aprano wrote:
>> (The fallback if all else fails is easy: get the height of the terminal,
>> in lines, and print that many blank lines.)
>
> Assuming you can get the height in lines. Have you tried t
On 19 September 2016 at 12:56, Steven D'Aprano wrote:
>
> For relatively small pieces of functionality, if it is useful enough, we
> should just add it to the std lib, and if it isn't, we should just say
> it isn't useful enough. We shouldn't condemn supporters of the idea to
> this false hope tha
On 19 September 2016 at 13:10, Paul Moore wrote:
>
> For this particular suggestion, though, I don't think that's the case.
> I think it's going to either be something that's accepted into the
> stdlib, or something that's rejected as too platform-specific
On 19 September 2016 at 18:20, אלעזר wrote:
> Obviously
>
> from __pip__ import "run-lambda>=0.1.0"
If we were going to go down this route (which I'm not at all convinced
we should) it should be "from __pypi__ import" not "from __pip__
import" (as PyPI is where the code is coming from, not pi
On 19 September 2016 at 17:59, Joonas Liik wrote:
> using pip from within python is not that difficult already.
> as can be seen with a glance to:
> http://stackoverflow.com/questions/12332975/installing-python-module-within-code
Note that pip does not officially support any use of its internal A
On 19 September 2016 at 19:52, אלעזר wrote:
> Of course it doesn't address the issues - for example, running a python
> script from the file manager will result in a failed execution, unexplained.
What you're talking about here is deployment of Python "applications"
(where in your case, you're f
On 19 September 2016 at 21:34, אלעזר wrote:
> Paul, I understand what you say, except the part of compatibility with
> Python3.5. Of course such a change is targeting future version more than the
> current and previous versions. If we have this syntax for Python3.6, users
> of Python3.9 will find
On 19 September 2016 at 21:35, João Matos wrote:
> Hello,
>
> I don't see why creating a clear command would interfere with dict.clear()
> which is a function/method.
>
> Although my first idea was a clear command, I have no problem if it is a
> clear() function from site.py.
>
> I didn't suggest
On 19 September 2016 at 23:13, אלעזר wrote:
> Alternative syntax might be that of import decorators
>
> @from_pip("attrs")
> import attr
At which point you may as well just (insert disclaimer about "using
pip's internal API isn't supported" here, and glossing over the fact
that pip doesn't yet ha
On 20 September 2016 at 08:57, אלעזר wrote:
> This is since in Python there are no contextual keywords (like "override"
> and "final" in C++). I remember encountering error in a Django project where
> accessing u.pass was a syntax error, but there *was* a field "pass" in u and
> they had to resort
On 19 September 2016 at 23:46, אלעזר wrote:
>> import pip
>> pip.install('attrs')
>> import attr
>
> Please forgive me for my ignorance, but it doesn't work as written - what's
> the actual method?
As David Mertz said, pip.main(['install', 'attrs']) works right now,
but it is NOT a supported use
On 20 September 2016 at 00:28, אלעזר wrote:
> On Tue, Sep 20, 2016 at 2:20 AM Stephen J. Turnbull
> wrote:
>>
>> אלעזר writes:
>>
>> > Another use case, though I admit not the top priority of anyone here,
>> is
>> > that of assignment checkers. In most courses I took at the university,
>> the
>
On 20 September 2016 at 11:40, אלעזר wrote:
> I believe that at least some of these problems can be addressed given that
> pip *knows* that this import is an in-script import.
Not with pip as it is now. There's talk of detecting problem cases and
reporting back "you need to restart your Python se
On 20 September 2016 at 11:46, אלעזר wrote:
> So it should be something like
>
> from unsafe.__pip__ import benchmark
>
> Where unsafe is the hypothetical namespace in which exec(), eval() and
> subprocess.run() would have reside given your concerns.
In my opinion, it should be
# Please install
On 20 September 2016 at 12:12, אלעזר wrote:
> Moreover, being able to do it programmatically is a security risk, since it
> requires elevated privileges that I don't know how to drop, and most people
> will not think about doing, but a library implementation will.
>
> So if someone uses subprocess
On 20 September 2016 at 13:58, Random832 wrote:
> On Tue, Sep 20, 2016, at 07:12, אלעזר wrote:
>> Moreover, being able to do it programmatically is a security risk,
>> since it requires elevated privileges that I don't know how to drop,
>> and most people will not think about doing, but a library
On 27 September 2016 at 13:46, Neil Girdhar wrote:
> Yes, I understand that, but I don't see how that would help at all with
> annotations. Aren't annotations also evaluated at "compile time"?
Yes, but a string whose value is a class name is treated as being the
same annotation (i.e., meaning th
On 27 September 2016 at 16:54, Erik Bray wrote:
> Then following my own logic it
> would be desirable to also allow the nested for loop syntax of list
> comprehensions outside them as well.
I'd say that it's a case where we should either allow arbitrary
concatenation outside of comprehensions, or
On 29 September 2016 at 08:08, Stephan Houben wrote:
> I just tried with this official Python binary:
> Python 3.5.2 (v3.5.2:4def2a2901a5, Jun 25 2016, 22:01:18) [MSC v.1900 32 bit
> (Intel)] on win32
>
> and CTRL-L for sure does clear the window. It just doesn't then move the
> prompt to the top,
Resending, because Google Groups messes up replying to the list :-(
On 1 October 2016 at 21:09, Paul Moore wrote:
> On 1 October 2016 at 19:07, Neil Girdhar wrote:
>> Sometimes, I want to conditionally enter a context manager. This simplest
>> (afaik) way of doing that is:
On 3 October 2016 at 15:52, Giampaolo Rodola' wrote:
> Independently from what the proposed solution is, I think you raised a very
> valid concern: the DRY principle.
> Right now the stdlib has tons of client network libraries which do not
> support the new async model.
> As such, library vendors
On 4 October 2016 at 08:56, Stephen J. Turnbull
wrote:
> These are my opinions; I don't claim any authority for them. I just
> don't find the proposed syntax as obvious and unambiguous as you do,
> and would like to explain why that is so.
>
> Ken Kundert writes:
>
> > In my experience it is exc
On 5 October 2016 at 05:09, Ken Kundert wrote:
> On Wed, Oct 05, 2016 at 03:07:42AM +1100, Steven D'Aprano wrote:
>>
>> Extra newlines are cheap. Writing
>>
>
> The cost is paid in newlines *and* extra levels of indentation.
No extra indentation if you ise "if not condition: continue" or
refactor
On 5 October 2016 at 14:27, Sven R. Kunze wrote:
> For small scripts this is still useful. Not everybody writes huge programs,
> which needs to adhere to style guides and QA.
Sure. But convenience in small scripts and the REPL typically isn't a
good enough argument to justify a language change. I
On 5 October 2016 at 17:26, Nick Coghlan wrote:
> Compared to those, locally modifying the token stream to inject ":
> INDENT" pairs when the if and for keywords are encountered between an
> opening "for" keyword and a closing ":" keyword would be a relatively
> straightforward change that only im
On 5 October 2016 at 18:17, Lisa Roach wrote:
> +1
>
> I've definitely seen a lot of new users make this error, an improved message
> could go a long way.
I'm not a new user by any means, and I still regularly make this
mistake. Because I've got the experience, I recognise the error when I
see it
On 5 October 2016 at 21:28, Rene Nejsum wrote:
> But, are the runtimes for Python and Erlang that fundamentally different? Is
> it Python’s tight integration with C that is the big difference?
I don't know *that* much about Erlang, but Python's model is that of a
single shared address space with
On 6 October 2016 at 14:45, Filipp Bakanov wrote:
> For now there are many usefull builtin functions like "any", "all", etc. I'd
> like to propose a new builtin function "equal". It should accept iterable,
> and return True if all items in iterable are the same or iterable is emty.
> That's quite
On 6 October 2016 at 18:09, Filipp Bakanov wrote:
> Seems like itertools recipes already have "all_equal" function. What do you
> think about moving it from recipes to itertools? I suggest a C
> implementation with optimisations for builtin collections.
Interestingly, the recipe given there was n
On 9 October 2016 at 01:25, Steven D'Aprano wrote:
> On Sat, Oct 08, 2016 at 09:26:13PM +0200, Jelte Fennema wrote:
>> I have an idea to improve indenting guidelines for dictionaries for better
>> readability: If a value in a dictionary literal is placed on a new line, it
>> should have (or at lea
On 11 October 2016 at 13:41, Sven R. Kunze wrote:
> maybe they could benefit
> from a patch where `if`-statements give a warning/error when the expression
> is a callable (with the default `FunctionType.__bool__`?
[...]
> What do you think about that Python emitting an warning/error as described
>
On 11 October 2016 at 14:38, Eric Snow wrote:
> On Tue, Oct 11, 2016 at 7:02 AM, Paul Moore wrote:
>> Interesting idea. There may be some issues - consider an object that
>> may optionally have a handler method handle_event, and you want to
>> call that method if it exis
On 11 October 2016 at 17:21, David Navarro wrote:
> Something like this
>
> In [1]: def a(): pass
> In [2]: def r(): raise RuntimeError('Do not forget to call this')
> In [3]: a.__bool__ = r
> In [4]: if a: pass
>
> I don't have an environment to test if this is possible. This would allow
> markin
On 11 October 2016 at 17:49, Nick Coghlan wrote:
> On 12 October 2016 at 02:16, Elliot Gorokhovsky
> wrote:
>> So I thought, wow, this will give some nice numbers! But I underestimated
>> the power of this optimization. You have no idea. It's crazy.
>> This is just insane. This is crazy.
>
> Not
On 12 October 2016 at 11:16, Steven D'Aprano wrote:
> On Wed, Oct 12, 2016 at 12:25:16AM +, Elliot Gorokhovsky wrote:
>
>> Regarding generalization: the general technique for special-casing is you
>> just substitute all type checks with 1 or 0 by applying the type assumption
>> you're making.
On 12 October 2016 at 20:22, David Mertz wrote:
> I've followed this discussion some, and every example given so far
> completely mystifies me and I have no intuition about what they should mean.
Same here.
On 12 October 2016 at 20:38, אלעזר wrote:
> What is the intuition behind [1, *x, 5]? The
On 12 October 2016 at 22:57, Elliot Gorokhovsky
wrote:
> On Wed, Oct 12, 2016 at 3:51 PM Nathaniel Smith wrote:
>>
>> But this isn't relevant to Python's str, because Python's str never uses
>> UTF-8.
>
>
> Really? I thought in python 3, strings are all unicode... so what encoding
> do they use,
On 13 October 2016 at 15:32, Sven R. Kunze wrote:
> Steven, please. You seemed to struggle to understand the notion of the
> [*] construct and many people (not just me) here tried their best to
> explain their intuition to you.
And yet, the fact that it's hard to explain your intuition to oth
On 13 October 2016 at 20:51, Random832 wrote:
> On Thu, Oct 13, 2016, at 15:46, Random832 wrote:
>> so, under a similar 'transformation', "*foo for foo in bar" likewise
>> becomes "def f(): for foo in bar: yield from foo"
>>
>> bar = [(1, 2), (3, 4)]
>> (*(1, 2), *(3, 4)) == == tuple(f())
>> [*(1
On 13 October 2016 at 21:40, Sjoerd Job Postmus wrote:
> However, consider the following spelling:
>
> l = [from f(t) for t in iterable]
>
> To me, it does not seem far-fetched that this would mean:
>
> def gen():
> for t in iterable:
> yield from f(t)
> l = list(ge
On 13 October 2016 at 21:47, אלעזר wrote:
> if you allow result.append(1, 2, 3) to mean result.extend([1,2,3]) # which
> was discussed before
I don't (for the reasons raised before). But thank you for your
explanation, it clarifies what you were proposing. And it does so
within the *current* use
On 14 October 2016 at 07:54, Greg Ewing wrote:
>> I think it's probably time for someone to
>> describe the precise syntax (as BNF, like the syntax in the Python
>> docs at
>> https://docs.python.org/3.6/reference/expressions.html#displays-for-lists-sets-and-dictionaries
>
>
> Replace
>
>compr
On 14 October 2016 at 10:48, Paul Moore wrote:
> On 14 October 2016 at 07:54, Greg Ewing wrote:
>>> I think it's probably time for someone to
>>> describe the precise syntax (as BNF, like the syntax in the Python
>>> docs at
>>> https://docs.python.org
On 16 October 2016 at 08:35, Alireza Rafiei wrote:
> Awesome! Thanks for the thorough explanation.
Thank you for the interesting suggestion that prompted the
explanation. I don't know about others, but I know that I often forget
ways to use the tools already at our disposal, so threads like this
On 17 October 2016 at 18:32, Steven D'Aprano wrote:
> On Mon, Oct 17, 2016 at 12:11:46PM -0400, Random832 wrote:
>
>> Honestly, it goes beyond just being "wrong". The repeated refusal to
>> even acknowledge any equivalence between [...x... for x in [a, b, c]]
>> and [...a..., ...b..., ...c...] tru
On 17 October 2016 at 20:35, Sven R. Kunze wrote:
> P.S. It's very artificial to assume user are unable to use 'from itertools
> import chain' to try to make chain() seem more cumbersome than it is.
>
> I am sorry but it is cumbersome.
Imports are a fundamental part of Python. How are they "cumb
On 17 October 2016 at 21:22, Random832 wrote:
> For a more concrete example:
>
> [*range(x) for x in range(4)]
> [*(),*(0,),*(0,1),*(0,1,2)]
> [0, 0, 1, 0, 1, 2]
>
> There is simply no way to get there by using flatten(range(4)). The only
> way flatten *without* a generator expression can serve th
On 17 October 2016 at 21:06, Sven R. Kunze wrote:
> Do you think that simple solution could have a chance to be added to stdlib
> somehow (with the possibility of speeding it up in the future)?
You could submit a doc patch to add an explanation of this technique
to the list.sort function. I doubt
On 17 October 2016 at 21:30, Random832 wrote:
> On Mon, Oct 17, 2016, at 16:12, Paul Moore wrote:
>> And finally, no-one has even *tried* to explain why we need a third
>> way of expressing this construction. Nick made this point, and
>> basically got told that his conditio
On 17 October 2016 at 21:33, Sven R. Kunze wrote:
> On 17.10.2016 22:12, Paul Moore wrote:
>>
>> 4. Whether you choose to believe me or not, I've sincerely tried to
>> understand the proposal [...]
>
> I think you did and I would like others to follow your example
On 17 October 2016 at 21:43, Sven R. Kunze wrote:
> The statement about "cumbersomeness" was specific to this whole issue. Of
> course, importing feature-rich pieces from the stdlib is really cool. It was
> more the missed ability to do the same with list comprehensions of what is
> possible with
On 17 October 2016 at 22:28, Mark Lawrence via Python-ideas
wrote:
> How about changing https://wiki.python.org/moin/HowTo/Sorting ?
Good point. Better still, https://docs.python.org/3.6/howto/sorting.html
Paul
___
Python-ideas mailing list
Python-idea
On 18 October 2016 at 07:31, Nick Coghlan wrote:
>
> Forcing ourselves to come up with a name for the series of values
> produced by the outer iteration then makes that name available as
> documentation of our intent for future readers of the code.
This is a key point, that is frequently missed w
On 19 October 2016 at 12:29, Michel Desmoulin wrote:
> I feel like people are really getting hyper sensitive about communications.
> While I do prefer talking to calm rational people with a friendly tone, I
> acknowledge this is not always the case and it's ok if somebody go overboard
> from time
On 19 October 2016 at 19:13, Chris Angelico wrote:
> Now it *won't* correctly call the end-of-iteration function, because
> there's no 'for' loop. This is going to either (a) require that EVERY
> consumer of an iterator follow this new protocol, or (b) introduce a
> ton of edge cases.
Also, unles
On 19 October 2016 at 20:21, Nathaniel Smith wrote:
> On Wed, Oct 19, 2016 at 11:38 AM, Paul Moore wrote:
>> On 19 October 2016 at 19:13, Chris Angelico wrote:
>>> Now it *won't* correctly call the end-of-iteration function, because
>>> there's no 'for&
On 21 October 2016 at 07:03, Nathaniel Smith wrote:
> Oh, goodness, no -- like Yury said, the use cases here are not
> specific to async at all. I mean, none of the examples are async even
> :-).
[...]
Ah I follow now. Sorry for the misunderstanding, I'd skimmed a bit
more than I realised I had.
On 21 October 2016 at 10:53, Steven D'Aprano wrote:
> On Wed, Oct 19, 2016 at 12:33:57PM -0700, Nathaniel Smith wrote:
>
>> I should also say, regarding your specific example, I guess it's an
>> open question whether we would want list_iterator.__iterclose__ to
>> actually do anything. It could fl
On 21 October 2016 at 12:23, Steven D'Aprano wrote:
> On Fri, Oct 21, 2016 at 11:03:51AM +0100, Paul Moore wrote:
>
>> At the moment, the take home message for such users feels like it's
>> "you might need to scatter preserve() around your code, to avoid the
&g
On 21 October 2016 at 15:26, Nick Coghlan wrote:
> - Remember that even if something we vehemently consider "wrong" makes
> it into the reference implementation, the language does have a design
> policy that allows us to correct design mistakes after a suitable
> deprecation period, and we also ea
On 21 October 2016 at 21:59, Chris Barker wrote:
>> So (it seems to
>> me) that you're talking about changing the behaviour of for-loops to
>> suit only a small proportion of cases: maybe 10% of 10%.
>
>
> I don't see what the big overhead is here. for loops would get a new
> feature, but it would
On 22 October 2016 at 08:17, Chris Angelico wrote:
> On Sat, Oct 22, 2016 at 5:49 PM, Ryan Birmingham
> wrote:
>> this proposed change aims to solve the problem caused when editors, mail
>> clients, web browsers, and operating systems over-zealously replacing
>> straight quotes with these typogr
On 23 October 2016 at 17:10, Danilo J. S. Bellini
wrote:
>> Ah, that makes SIX existing solutions. Do we need a seventh?
>
> It might have dozens of solutions, perhaps an infinity of solutions.
> Brainfuck and assembly can be used, or even turing machine instructions...
>
> But there should be one
On 24 October 2016 at 18:39, Mikhail V wrote:
> I would be happy to see a somewhat more general and user friendly
> version of string.translate function.
> It could work this way:
> string.newtranslate(file_with_table, Drop=True, Dec=True)
Using a text file seems very odd. But regardless, this co
On 24 October 2016 at 21:54, Chris Barker wrote:
> I don't know a way to do "remove every character except these", but someone
> I expect there is a way to do that efficiently with Python strings.
It's easy enough with the re module:
>>> re.sub('[^0-9]', '', 'ab0c2m3g5')
'0235'
Possibly because
On 25 October 2016 at 15:02, Stephen J. Turnbull
wrote:
> I did. They are very persuasive ... up to the point where you ask for
> syntax for something that appears (now that you've done it, kudos!) to
> be perfectly do-able with a function.
This is an important point by the way. Ideas on this li
On 25 October 2016 at 20:11, Michel Desmoulin wrote:
> Similarly, I'd like to suggest a similar feature for building dictionaries:
>
foo = 1
bar = 2
{:bar, :foo}
> {'bar': 1, 'foo', 2}
I don't see a huge advantage over
>>> dict(foo=foo, bar=bar)
Avoiding having to repeat the vari
I've seen a lot of syntax proposals recently that are based around
providing better ways of writing "one liner" styles of code.
Typically, the proposals seem to get into trouble because:
1. They duplicate things that can already be done, just not in a
single expression/statement.
2. They are seen
On 25 October 2016 at 20:17, Nathaniel Smith wrote:
> I get that this list's default is to push
> back on proposed changes, and it's a good principle in general, but
> "improved error messages" are *really* cheap. The bar should be pretty
> low, IMO. If someone's willing to do the work to make the
On 26 October 2016 at 18:25, Nick Coghlan wrote:
> The built-in REPL serves two quite divergent use cases, and I think
> we're well past the point where we can't readily support both use
> cases with a single implementation:
>
> - a minimalist interactive environment, that is *always* present, eve
On 26 October 2016 at 21:43, Nikolaus Rath wrote:
>> So I think that it would be really useful to be able to plug in a new
>> REPL, when it's available. This has a number of benefits:
>>
>> 1. We don't need to worry about incorporating any complex REPL code
>> into Python. The default REPL can rem
On 26 October 2016 at 22:11, Todd wrote:
> Isn't this what aliases are for? Just set "python" to be an alias for
> "ipython" for your interactive shell.
I hadn't thought of that option. I might give it a try. Although I'm
not sure how I'd set up a Powershell function (I'm on Windows) that
would
On 26 October 2016 at 22:40, Nikolaus Rath wrote:
> It also imposes a significant burden on scripting. I often have elements
> like this in shell scripts:
>
> output=$(python < import h5py
> with h5py.File('foo', 'r') as fh:
> print((fh['bla'] * fh['com']).sum())
> EOF
> )
>
> If this now sta
On 27 October 2016 at 01:49, Steven D'Aprano wrote:
>> (a bit like readline,
>> but I dislike the way you can't switch off readline integration if
>> it's installed)?
>
> This comment surprises me. To me, that's like saying "I dislike the way
> you can't switch off breathing" -- readline is almost
On 28 October 2016 at 15:40, Nick Coghlan wrote:
> I also don't think the idea is sufficiently general to be worthy of
> dedicated syntax if it's limited specifically to "is not None" checks
> - None's definitely special, but it's not *that* special. Unifying
> None, NaN, NotImplemented and Ellips
On 28 October 2016 at 22:25, Sven R. Kunze wrote:
> So, instead providing this kind of syntax for dicts only, why not also
> providing them for kwargs? Basically marking arguments as keyword arguments:
>
>
> my_func(:param1, :param2)
>
>
> ":param" equals "param=param" again but as already said th
On 29 October 2016 at 07:21, Nick Coghlan wrote:
> A short-circuiting if-else protocol for arbitrary "THEN if COND else
> ELSE" expressions could then look like this:
>
> _condition = COND
> if _condition:
> _then = THEN
> if hasattr(_condition, "__then__"):
> r
On 29 October 2016 at 07:30, Steven D'Aprano wrote:
> So even though I *want* to use non-ASCI operators, I have to admit that
> I *can't* realistically use non-ASCII operators. Not yet.
Personally, I'm not even sure I want non-ASCII operators until
non-ASCII characters are common, and used withou
On 29 October 2016 at 18:19, Stephen J. Turnbull
wrote:
>> For better or worse, it may be emoji that drive that change ;-)
>
> I suspect that the 100 million or so Chinese, Japanese, Korean, and
> Indian programmers who have had systems that have no trouble
> whatsoever handling non-ASCII for as l
On 30 October 2016 at 07:00, Stephen J. Turnbull
wrote:
>> as I imagine Unicode characters would be for me. I really hope it
> > isn't...
>
> I think your imagination is running away with you. While I understand
> how costly it is for those over the age of 12 to develop new habits
> (I'm 58, and
On 30 October 2016 at 12:31, Chris Angelico wrote:
> On Sun, Oct 30, 2016 at 11:22 PM, Paul Moore wrote:
>> In mentioning emoji, my main point was that "average computer users"
>> are more and more likely to want to use emoji in general applications
>> (emails, w
On 30 October 2016 at 14:43, wrote:
> Just picking a nit, here, windows will happily let you do silly things like
> hook 14 keyboards up and let you map all of emoji to them. Sadly, this
> requires lua.
Off topic, I know, but how? I have a laptop with an external and an
internal keyboard. Can
On 30 October 2016 at 14:51, Stephen J. Turnbull
wrote:
> Paul Moore writes:
>
> > My point wasn't so much about dealing with the character set of
> > Unicode, as it was about physical entry of non-native text. For
> > example, on my (UK) keyboard, all of the
On 31 October 2016 at 15:51, Mark E. Haase wrote:
> Therefore, I have updated the PEP with the punctuation mentioned above, and
> at this point the PEP can't go any farther. If the best spelling for this
> new operator is unacceptable, then there's no getting around that. This PEP
> should be reje
On 31 October 2016 at 17:16, Guido van Rossum wrote:
> I think we should try to improve our intutition about these operators. Many
> things that are intuitively clear still require long turgid paragraphs in
> reference documentation to state the behavior unambiguously -- but that
> doesn't stop us
On 31 October 2016 at 18:11, MRAB wrote:
> With this feature it could be:
>
> if x in stop_on or end_if?(x):
I don't think "null-aware function call" is in the current version of the PEP.
Paul
___
Python-ideas mailing list
Python-ideas@python.org
ht
On 1 November 2016 at 08:33, Pavel Velikhov wrote:
> We have released PythonQL, a query language extension to Python (we have
> extended Python’s comprehensions with a full-fledged query language,
> drawing from the useful features of SQL, XQuery and JSONiq). Take a look at
> the project here:
On 1 November 2016 at 10:11, Nick Coghlan wrote:
>
> I do think it would be worth covering the symbol+keyword option
> discussed in PEP 531 (i.e. "?else" instead of "??", but keeping "?.",
> and "?[")
FWIW, I'm not keen on it.
As a technical question, would it be treated in the syntax as a
keywo
On 3 November 2016 at 11:38, Steven D'Aprano wrote:
> Looking at those examples of code, I don't think it is likely that the
> majority (or even a large minority) are the result of getattr.
>
> But even if they are, what difference does it make?
It may have mattered, if a getattr(obj, attr, coale
On 10 November 2016 at 21:18, Ethan Furman wrote:
> On 11/10/2016 01:07 PM, Franklin? Lee wrote:
>>
>> On Fri, Oct 21, 2016 at 11:07 AM, Paul Moore wrote:
>>>
>>>
>>> I wonder. Would there be value in adding a sign-up email to the list
>>> (s
On 14 November 2016 at 22:13, Mikhail V wrote:
>> we don't want A = A + 1 to be the same as A += 1 "
>
> This sounds quite frustrating for me, what else could this be but A += 1?
> Would I want a copy with same name? How that will make sense?
>>> A = [1,2,3]
>>> B = A
>>> A = A + [1]
>>> A
[1, 2,
On 15 November 2016 at 02:59, Matthias welp wrote:
> Mikhail, what Paul probably means here is that python 'operators' are actually
> 'syntactic sugar' for functions (it is not recommended to call
> these functions directly, but it is possible):
More specifically, the meaning of the syntax a = a
401 - 500 of 896 matches
Mail list logo
