[Python-ideas] Re: Comparison operator support (>= and <=) for type

2019-06-17 Thread Andrew Barnert via Python-ideas
On Jun 17, 2019, at 07:47, Guido van Rossum wrote: > >> On Mon, Jun 17, 2019 at 7:23 AM Rhodri James wrote: >> On 16/06/2019 03:34, Guido van Rossum wrote: >> > I don't actually know how viable this proposal is, but given that it's >> > being debated at some length, I'd like to put in my

[Python-ideas] Re: Comparison operator support (>= and <=) for type

2019-06-17 Thread Andrew Barnert via Python-ideas
On Jun 17, 2019, at 13:09, Guido van Rossum wrote: > >> On Mon, Jun 17, 2019 at 12:54 PM Andrew Barnert wrote: >>> On Jun 17, 2019, at 07:47, Guido van Rossum wrote: >>> On Mon, Jun 17, 2019 at 7:23 AM Rhodri James wrote: On 16/06/2019 03:34, Guido van Rossum wrote: > I don't

[Python-ideas] Re: `if-unless` expressions in Python

2019-06-24 Thread Andrew Barnert via Python-ideas
On Jun 24, 2019, at 10:27, Dan Sommers <2qdxy4rzwzuui...@potatochowder.com> wrote: > > On 6/24/19 12:32 PM, James Lu wrote: > > > I think > > > > print("Remember to wear sunscreen!") if hot_outside unless > > Weather.is_raining() > > > > Is more readable than > > > > if hot_outside and not

[Python-ideas] Re: A proposal (and implementation) to add assignment and LOAD overloading (was: (Re: Re: Overloading assignment concrete proposal (Re: Re: Operator as first class citizens -- like in s

2019-06-25 Thread Andrew Barnert via Python-ideas
On Jun 25, 2019, at 14:00, nate lust wrote: > > This message is related to two previous threads, but was a sufficiently > evolved to warrant a new topic. > > I am proposing that two new magic methods be added to python that will > control assignment and loading of class > instances. This

[Python-ideas] Re: Operator as first class citizens -- like in scala -- or yet another new operator?

2019-06-19 Thread Andrew Barnert via Python-ideas
On Jun 18, 2019, at 12:43, nate lust wrote: > > I have been following this discussion for a long time, and coincidentally I > recently started working on a project that could make use of assignment > overloading. (As an aside it is a configuration system for a astronomical > data analysis

[Python-ideas] Overloading assignment concrete proposal (Re: Re: Operator as first class citizens -- like in scala -- or yet another new operator?)

2019-06-19 Thread Andrew Barnert via Python-ideas
ing it to students, etc., that doesn't matter. Being precise here wouldn't be hugely difficult, but it is a little more difficult than with __iadd__, where there's no similar potential confusion even possible.On Wednesday, June 19, 2019, 10:54:04 AM PDT, Andrew Barnert via Python-ideas wrote

[Python-ideas] Re: Why not accept lists or arbitrary iterables in str.endswith?

2019-06-19 Thread Andrew Barnert via Python-ideas
On Jun 19, 2019, at 15:28, Soni L. wrote: > > I'm parsing configs for domain filtering rules, and they come as a list. > However, str.endswith requires a tuple. So I need to use > str.endswith(tuple(list)). I don't know the reasoning for this, but why not > just accept a list as well?

[Python-ideas] Re: Overloading assignment concrete proposal (Re: Re: Operator as first class citizens -- like in scala -- or yet another new operator?)

2019-06-19 Thread Andrew Barnert via Python-ideas
On Jun 19, 2019, at 16:57, Chris Angelico wrote: > > On Thu, Jun 20, 2019 at 8:14 AM Andrew Barnert via Python-ideas > wrote: >> … x = y would mean this: >> >>try: >>xval = globals()['x'] >>result = xval.__iassign__(y) >

[Python-ideas] Re: Canceling thread in python

2019-06-20 Thread Andrew Barnert via Python-ideas
On Jun 19, 2019, at 22:14, Matúš Valo wrote: > > Hi All, > > Currently it is not possible to "kill" thread which is blocked. The rationale > for this is handling situations when thread is blocked - e.g. when thread is > quering DB when lock occurred on Database. > pthread library and Windows

[Python-ideas] Re: Overloading assignment concrete proposal (Re: Re: Operator as first class citizens -- like in scala -- or yet another new operator?)

2019-06-21 Thread Andrew Barnert via Python-ideas
On Jun 21, 2019, at 14:36, nate lust wrote: > > I think it is only surprising because it is not something that is familiar. Part of the problem may be that in your toy example, there really is no reason to overload assignment, so it’s surprising even after you get what it’s doing. If you

[Python-ideas] Re: Overloading assignment concrete proposal (Re: Re: Operator as first class citizens -- like in scala -- or yet another new operator?)

2019-06-21 Thread Andrew Barnert via Python-ideas
On Jun 20, 2019, at 13:25, nate lust wrote: > > There is nothing more humbling than sending nonsense out to an entire mailing > list. You’re something like the 300th person to suggest overloading assignment, but the only one of that 300 willing to think it through, much less create a patch.

[Python-ideas] Re: Make $ a valid identifier and a singleton

2019-06-23 Thread Andrew Barnert via Python-ideas
On Jun 23, 2019, at 17:01, Steven D'Aprano wrote: > >> On Sun, Jun 23, 2019 at 03:22:37PM -0400, James Lu wrote: >> Make $ a valid identifier and a singleton. >> >> $ is a useful placeholder in []. >> >> Possible function partial syntax: >> >> def foo(x, y): >>print(x, y) >> >>

[Python-ideas] Re: `if-unless` expressions in Python

2019-06-23 Thread Andrew Barnert via Python-ideas
On Jun 23, 2019, at 19:57, MRAB wrote: > >> On 2019-06-24 02:43, Andrew Barnert wrote: >> On Jun 23, 2019, at 13:33, MRAB wrote: >> >> > Finally, under "For consideration: alternative syntaxes", my offering >> > would be: >> > > expr if condition1 and not condition2 else pass >> >> This

[Python-ideas] Re: `if-unless` expressions in Python

2019-06-24 Thread Andrew Barnert via Python-ideas
On Sunday, June 23, 2019, 10:13:07 PM PDT, Chris Angelico wrote: > The biggest problem with this proposal is the way that, being a > syntactic construct, it's going to be non-composable. > # Oops, syntax error > with (some_expr as q, >         some_other_expr as w):>     pass I don't

[Python-ideas] Re: A proposal (and implementation) to add assignment and LOAD overloading

2019-06-27 Thread Andrew Barnert via Python-ideas
On Jun 27, 2019, at 08:59, nate lust wrote: > > There are two (three) important cases when I have exempt __getself__ from > being called. First is when an > object is used in methods defined within itself. This means that self can be > used when defining methods > without triggering recursive

[Python-ideas] Re: Canceling thread in python

2019-06-27 Thread Andrew Barnert via Python-ideas
On Thursday, June 27, 2019, 03:40:56 PM PDT, Yonatan Zunger wrote: > One possible approach (at a very schematic level, not thinking about impl > details yet) would be to have a function like Thread.raise(e: BaseException) > which stuffs the exception into thread-local storage, which then

[Python-ideas] Re: A proposal (and implementation) to add assignment and LOAD overloading

2019-06-27 Thread Andrew Barnert via Python-ideas
On Jun 27, 2019, at 16:18, Greg Ewing wrote: > > Andrew Barnert wrote: >> in Lisp, if you replace the setf macro, > > Okay, maybe Lisp wasn't a good example. In the presence of macros, > all bets are off. :-( But at least if you haven't redefined the > universe, local bindings in Lisp behave

[Python-ideas] Re: Canceling thread in python

2019-06-27 Thread Andrew Barnert via Python-ideas
On Jun 27, 2019, at 13:36, Michael Foord wrote: > >> On Thu, 27 Jun 2019 at 20:53, Yonatan Zunger wrote: >> Generally, threads don't have a notion of non-cooperative thread >> termination. > That's precisely why thread cancellation in managed languages (like Python > is) raise an exception

[Python-ideas] Re: A proposal (and implementation) to add assignment and LOAD overloading

2019-06-26 Thread Andrew Barnert via Python-ideas
On Jun 26, 2019, at 07:34, Anders Hovmöller wrote: > > I 100% agree that this proposal is a bad idea. But I do have to play Devils > advocate here. > > The the-code-is-understandable-at-face-value ship has already sailed. + > doesn't mean add, it means calling a dunder function that can do

[Python-ideas] Re: A proposal (and implementation) to add assignment and LOAD overloading

2019-06-26 Thread Andrew Barnert via Python-ideas
On Wednesday, June 26, 2019, 11:53:30 AM PDT, Chris Angelico wrote: > I don't think you can define what "f->spam" means Well, you can, but only the first half of what it means, so I don't think this changes your point. If f is a pointer, then f->spam means to dereference the pointer f, then

[Python-ideas] Re: Make tuple a context manager

2019-07-12 Thread Andrew Barnert via Python-ideas
On Friday, July 12, 2019, 07:48:52 AM PDT, Joao S. O. Bueno wrote: > Modifying the fundamental tuples for doing that is certainly overkill -  > but maybe a context-helper function in contextlib that would proper handle > all the > corner cases of some code as I've pasted now at: > Python

[Python-ideas] Re: Make tuple a context manager

2019-07-12 Thread Andrew Barnert via Python-ideas
On Jul 12, 2019, at 06:27, haael wrote: > > Tuple as context manager would invoke __enter__ for each of its elements and > return a tuple of the results. > > On exit, the __exit__ method would be invoked for every element. > > We could even generalize it to every kind of iterable. So instead

[Python-ideas] Re: Non-standard evaluation for Python

2019-07-13 Thread Andrew Barnert via Python-ideas
On Jul 13, 2019, at 12:16, Nima Hamidi wrote: > > > In the following, I sketch how I think this can be implemented: > Let BoundExpression be a class containing an ast.Expression as well as locals > and globals dictionaries. BoundExpression can also have an eval method that > evaluates its

[Python-ideas] Re: Non-standard evaluation for Python

2019-07-13 Thread Andrew Barnert via Python-ideas
(Re-sending, because this was originally a reply to an off-list message by Nima Hamidi) On Jul 13, 2019, at 14:12, Nima Hamidi wrote: > > Sometimes it's necessary not to evaluate the expression. Two such > applications of NSE in R are as follows: > > 1. Data-tables have cleaner syntax. For

[Python-ideas] Re: Proposal: `python-config` should be available in venv virtual environment.

2019-07-03 Thread Andrew Barnert via Python-ideas
On Jul 3, 2019, at 03:54, Stefan Droege wrote: > > Currently, when creating a virtualenv with the PEP-405 `venv` module, the > python-config executable will not be copied/symlinked to the virtualenv. > > That means for projects that link against the python interpreter, *and* which > are built

[Python-ideas] Re: something like sscanf for Python

2019-06-28 Thread Andrew Barnert via Python-ideas
On Jun 28, 2019, at 12:09, Chris Angelico wrote: > > 1) For all the different types of object that can be read (integer, > string, JSON blob, etc), have a function that will read one, stop when > it's done, and report both the parsed object and the point where it > stopped parsing. For a

[Python-ideas] Re: A proposal (and implementation) to add assignment and LOAD overloading

2019-06-26 Thread Andrew Barnert via Python-ideas
On Jun 26, 2019, at 13:53, Chris Angelico wrote: > Then in what circumstances will getself NOT be called? What is the > point of having an object, if literally every reference to it will > result in something else being used? I think Yanghao has misunderstood the proposal. What Nate actually

[Python-ideas] Re: Proposal: Using % sign for percentage

2019-06-26 Thread Andrew Barnert via Python-ideas
On Jun 25, 2019, at 08:44, James Lu wrote: > > What if we had reverse format strings, i.e. reading formatted input? > > x = readf("{:.0%}", "50%") > # => x == 0.50 > x = readf("{:.0}", "50") > # => x == 0.50 > > Readf takes the repr() of its second argument and “un-formats” the string. What’s

[Python-ideas] Re: A proposal (and implementation) to add assignment and LOAD overloading

2019-06-26 Thread Andrew Barnert via Python-ideas
On Jun 26, 2019, at 15:46, Greg Ewing wrote: > > Yes, but it's pretty universal across languages with name-binding > semantics for assignment (Lisp, Ruby, Javascript etc.) that assigning > to a local name doesn't invoke any magic. I don’t think that’s quite true. Many languages with

[Python-ideas] Re: Non-standard evaluation for Python

2019-07-14 Thread Andrew Barnert via Python-ideas
On Jul 14, 2019, at 00:33, Anders Hovmöller wrote: > > This use case is nicely covered by short form for keyword arguments. So in > this case instead of plot(x, z), we'd have plot(=x, =z) which would be > transformed into plot(**{'x': x, 'z': z}) at compile time. This does avoid the problem

[Python-ideas] Re: Make tuple a context manager

2019-07-14 Thread Andrew Barnert via Python-ideas
On Jul 12, 2019, at 06:27, haael wrote: > > with tuple(open(str(_n) + '.tmp', 'w') for _n in range(1000)) as f: >for n, fn in enumerate(f): >f.write(str(n)) Another thought here: There may be good examples for what you want—although I suspect every such example will be much better

[Python-ideas] Re: Non-standard evaluation for Python

2019-07-14 Thread Andrew Barnert via Python-ideas
On Jul 14, 2019, at 13:46, Nima Hamidi wrote: > > Andrew Barnert wrote: >> But in your proposal, wouldn’t this have to be written as dt[price < >> 1]? I think the cost of putting the expression in ticks is at least as bad >> as the >> cost of naming the dt. >> Also: dt.price < 1 is a perfectly

[Python-ideas] Re: Non-standard evaluation for Python

2019-07-14 Thread Andrew Barnert via Python-ideas
On Jul 14, 2019, at 11:53, Anders Hovmöller wrote: > > >>> On 14 Jul 2019, at 20:21, Andrew Barnert wrote: >>> >> This does avoid the problem of needing new syntax, but it seems to have >> other problems. > > Well it does introduce new syntax, just one that is generally useful. Right,

[Python-ideas] Re: Non-standard evaluation for Python

2019-07-14 Thread Andrew Barnert via Python-ideas
On Jul 14, 2019, at 13:13, Serhiy Storchaka wrote: > > > The more interesting problem is that in general case you have not simple > `price < 1`, but `price < x` where x is a variable or more complex expression. I don’t think this one is a problem. (I mean, it does demonstrate the problem I

[Python-ideas] Re: Non-standard evaluation for Python

2019-07-15 Thread Andrew Barnert via Python-ideas
On Jul 15, 2019, at 01:27, Serhiy Storchaka wrote: > > 14.07.19 23:20, Nima Hamidi пише: >> Thank you for your question! It would depend on the implementation of >> DataFrame.__getitem__. Note that BoundExpression is endowed with locals and >> globals of the callee. So, it does have access to

[Python-ideas] Re: Non-standard evaluation for Python

2019-07-15 Thread Andrew Barnert via Python-ideas
On Jul 15, 2019, at 00:27, Anders Hovmöller wrote: > > >> On 14 Jul 2019, at 22:46, Andrew Barnert wrote: >> >> But this doesn’t in any way help with late eval. > > Ah. Now I'm with you. Yes this is different but it also seems strange that we > wouldn't just use a lambda or a function for

[Python-ideas] Re: Coding using Unicode

2019-07-15 Thread Andrew Barnert via Python-ideas
On Jul 15, 2019, at 04:43, Adrien Ricocotam wrote: > > Oh ok ! > I tried with some unicodes () but it didn't work. So it's only a subset as > described in PEPs ? > What about extending it ? I’m pretty sure that the docs explain that the subset of characters that Python allows in identifiers

[Python-ideas] Re: something like sscanf for Python

2019-06-28 Thread Andrew Barnert via Python-ideas
On Jun 28, 2019, at 16:10, Chris Angelico wrote: > > The %s marker would accept everything up to the next literal text. So > if you say "%s@%s", it would read up to the at sign. The second part > of the proposal would be doing that, though; the "%s" handler would > simply accept everything and

[Python-ideas] Re: hybrid implementation for PyLongObject (performance)

2019-08-12 Thread Andrew Barnert via Python-ideas
On Aug 11, 2019, at 19:01, malin...@163.com wrote: > > The idea is mixing `PyLongObject` with `Python 2's PyIntObject` > implementation. > > For example, on a 64-bit platform, if (an integer >=-9223372036854775808 and > <=9223372036854775807), PyLongObject uses a native C type `signed long` to

[Python-ideas] Re: adding support for a "raw output" in JSON serializer

2019-08-13 Thread Andrew Barnert via Python-ideas
On Aug 13, 2019, at 11:21, Chris Angelico wrote: > > On Wed, Aug 14, 2019 at 3:12 AM Andrew Barnert via Python-ideas > wrote: >> >>> On Aug 13, 2019, at 01:04, Richard Musil wrote: >>> >>> Concerning the custom separators, and why the im

[Python-ideas] Re: adding support for a "raw output" in JSON serializer

2019-08-13 Thread Andrew Barnert via Python-ideas
On Aug 13, 2019, at 15:01, Eric V. Smith wrote: > >> On 8/13/2019 5:49 PM, Andrew Barnert via Python-ideas wrote: >> But I think the lazy-import-decimal-on-first-dump-with-use_decimal solves >> that, and solves it even better than __json__, even besides the fact that >

[Python-ideas] Re: hybrid implementation for PyLongObject (performance)

2019-08-13 Thread Andrew Barnert via Python-ideas
On Aug 13, 2019, at 06:45, malincns wrote: > > Thanks for your guidance. > To be honest, it's a challenge for me. > It would be nice if an experienced person is willing to make this attempt. It would be a significant amount of work just to implement it far enough to benchmark. So again, I

[Python-ideas] Re: adding support for a "raw output" in JSON serializer

2019-08-13 Thread Andrew Barnert via Python-ideas
On Aug 13, 2019, at 01:04, Richard Musil wrote: > > Concerning the custom separators, and why the implementation supports them, I > believe it is not actually about the separators themselves, but the > whitespaces around them. When you generate JSON with an indentation, you > probably also

[Python-ideas] Re: for ... except, with ... except

2019-07-29 Thread Andrew Barnert via Python-ideas
On Jul 29, 2019, at 14:49, Guido van Rossum wrote: > > Still I wouldn't call this "a lot worse". What makes you say that? Not “worse” as in more common, or more dangerous (I don’t know if that’s true or not), but as in harder to work around. for…else being confusing and effectively “experts

[Python-ideas] Re: For-expression/throwaway comprehension

2019-08-02 Thread Andrew Barnert via Python-ideas
On Aug 1, 2019, at 22:26, Brendan Barnwell wrote: > >> On 2019-08-01 12:31, Andrew Barnert via Python-ideas wrote: >>> On Aug 1, 2019, at 10:48, Eli Berkowitz wrote: >>> > >>> >In terms of an argument for why it should be included, for most Python >

[Python-ideas] Re: For-expression/throwaway comprehension

2019-08-02 Thread Andrew Barnert via Python-ideas
On Aug 2, 2019, at 11:34, Christopher Barker wrote: > > The other issue here, in the context of the OP's proposal, is that it's less > than obvious that that's what a user would want when they want to operate on > all the items in a iterable without creating a new iterable. To Guido's >

[Python-ideas] Re: For-expression/throwaway comprehension

2019-08-02 Thread Andrew Barnert via Python-ideas
On Aug 2, 2019, at 19:22, Brendan Barnwell wrote: > >> On 2019-08-02 19:16, Andrew Barnert wrote: >> >> So, that’s the way forward. You could port the recipes to C and >> change the docs recipes to be “roughly equivalent” Python code in the >> help for each function. Or you could port itertools

[Python-ideas] Re: For-expression/throwaway comprehension

2019-08-02 Thread Andrew Barnert via Python-ideas
On Aug 2, 2019, at 15:45, Steven D'Aprano wrote: > > Are infinite for-loops that common that people get excited by cycle? > That sounds like the "here's a hammer, now every problem is a nail" > issue. "itertools.cycle is cool, I must use it as often as possible!" Well, they’re probably

[Python-ideas] Re: JSON encoder protocol (was Re: adding support for a "raw output" in JSON serializer)

2019-08-14 Thread Andrew Barnert via Python-ideas
On Aug 14, 2019, at 11:38, Chris Angelico wrote: > > Side point: Does anyone else think it was an egotistical idea to > create JSON as a non-versioned specification? "I can't possibly get > this wrong". And now look what's happened. Well, it was supposed to be an antidote to complicated

[Python-ideas] Re: JSON encoder protocol (was Re: adding support for a "raw output" in JSON serializer)

2019-08-14 Thread Andrew Barnert via Python-ideas
On Aug 14, 2019, at 19:48, Wes Turner wrote: > > Native serialization and deserialization support for either or both JSON5, > JSON lines, and JSON-LD would be great to have. PyPI has packages for all of these things (plus the two not-quite-identical variations on JSONlines, and probably other

[Python-ideas] Re: Extend ast with types for * instead of using raw lists

2019-08-16 Thread Andrew Barnert via Python-ideas
On Aug 15, 2019, at 13:02, Caleb Donovick wrote: > > When walking an ast it impossible to know the type of an empty list without > writing down some giant lookup from node types and field names to field types. This part could be solved without making the lists AST nodes at all. Just use new

[Python-ideas] Re: JSON encoder protocol

2019-08-17 Thread Andrew Barnert via Python-ideas
On Aug 16, 2019, at 20:35, Kyle Stanley wrote: > > Speaking of examples, I think it would be helpful to provide a brief example > of ``object.__json__()`` being used for some added clarity. Would it be a > direct alias of ``json.dumps()`` with the same exact parameters and usage, or > would

[Python-ideas] Re: Fwd: Optional kwarg for sequence methods in random module

2019-08-18 Thread Andrew Barnert via Python-ideas
On Aug 18, 2019, at 06:20, Senhaji Rhazi hamza wrote: > > Hey Steven, > > I think there is a way to map x <- [1; + inf] to y <- [0;1] by putting y = 1/x Well, that gives you a distribution from (0, 1] instead of [0. 1), which is technically not legal as a substitute for random, even though

[Python-ideas] Re: JSON encoder protocol (was Re: adding support for a "raw output" in JSON serializer)

2019-08-15 Thread Andrew Barnert via Python-ideas
On Aug 14, 2019, at 20:35, Wes Turner wrote: > A few questions then are: > > Should __json__() be versioned? Why? While there are sort of multiple versions of JSON (pre-spec, ECMA404, and the successive RFCs), even when you know which one you’re dealing with, there’s not really anything

[Python-ideas] Re: JSON encoder protocol (was Re: adding support for a "raw output" in JSON serializer)

2019-08-15 Thread Andrew Barnert via Python-ideas
On Aug 15, 2019, at 10:23, Christopher Barker wrote: > > This is all making me think it's time for a broader discussion / PEP: > > The future of the JSON module. I think this is overreacting. There’s really only two issues here, and neither one is that major. But nobody has shown any need

[Python-ideas] Re: adding support for a "raw output" in JSON serializer

2019-08-10 Thread Andrew Barnert via Python-ideas
On Aug 10, 2019, at 01:01, Richard Musil wrote: > > Andrew Barnert wrote: > >> Except that it doesn’t allow that. Using Decimal doesn’t preserve the >> difference >> between 1.E+3 and 1000.0, or between +12 and 12. Not to mention > > but it preserves the exact precision and value, i.e.

[Python-ideas] Re: adding support for a "raw output" in JSON serializer

2019-08-10 Thread Andrew Barnert via Python-ideas
On Aug 9, 2019, at 19:09, Greg Ewing wrote: > > Andrew Barnert wrote: >> No you can’t. Decimal accepts strings that aren’t valid as JSON numbers, like >> `.3`, > > That's not a problem as long as it doesn't serialise them that > way, which it wouldn't: Your suggestion was that we could allow

[Python-ideas] Re: adding support for a "raw output" in JSON serializer

2019-08-10 Thread Andrew Barnert via Python-ideas
On Aug 9, 2019, at 19:09, Greg Ewing wrote: > > Andrew Barnert wrote: >> Except that it doesn’t allow that. Using Decimal doesn’t preserve the >> difference between 1.E+3 and 1000.0, or between +12 and 12. > > That's true. But it does preserve everything that's important for > interpreting

[Python-ideas] Re: adding support for a "raw output" in JSON serializer

2019-08-12 Thread Andrew Barnert via Python-ideas
On Aug 12, 2019, at 15:18, Christopher Barker wrote: > > If that is the goal, then strings would need a hook, too, as Unicode allows > different normalized forms for some "characters" (see previous discussion for > this, I, frankly, don't quite "get" it. Although normalization can be a

[Python-ideas] Re: adding support for a "raw output" in JSON serializer

2019-08-12 Thread Andrew Barnert via Python-ideas
On Aug 12, 2019, at 15:34, Christopher Barker wrote: > > In fact, I'm pretty sure that setting custom separators the only way to get > it to generate invalid JSON now, There’s also allow_nan. But that one is clearly intentional, because so many other implementations (including the original JS

[Python-ideas] Re: JSON encoder protocol (was Re: adding support for a "raw output" in JSON serializer)

2019-08-14 Thread Andrew Barnert via Python-ideas
On Aug 14, 2019, at 09:22, Random832 wrote: > >> On Sun, Aug 11, 2019, at 20:42, Chris Angelico wrote: >> class float: >>def __json__(self): >>if math.isfinite(self): return str(self) >>return "null" > > Er, to be clear, the current JSON decoder returns 'Infinity',

[Python-ideas] Re: adding support for a "raw output" in JSON serializer

2019-08-14 Thread Andrew Barnert via Python-ideas
On Aug 14, 2019, at 09:57, Christopher Barker wrote: > > The other issue on the table is whether it's a goal of the json module to > make it hard to create invalid JSON -- I think that would be nice, but others > don't seem to think so. > > A NOTE on that: > > Maybe it would be good to have

[Python-ideas] Re: Exception handling in objects

2019-08-14 Thread Andrew Barnert via Python-ideas
On Aug 14, 2019, at 06:19, Marat Sharafutdinov wrote: > > > The essence of my idea is simple and does not affects compatibility with > existing code: to automatically define a magic attribute of module under the > working name "__exception__" while importing any module. It can be used in >

[Python-ideas] Re: Fwd: Optional kwarg for sequence methods in random module

2019-08-17 Thread Andrew Barnert via Python-ideas
On Aug 17, 2019, at 00:02, Patryk Gałczyński wrote: > > One thing I'm concern about is how it would all relate to _randommodule.c (I > have little knowledge about C part) You probably don’t need to change the C code at all. I’m pretty sure none of these functions are implemented in C, they

[Python-ideas] Re: [new idea] dynamic return with using function argument

2019-08-26 Thread Andrew Barnert via Python-ideas
On Aug 26, 2019, at 10:51, Guido van Rossum wrote: > > I'd love to squash this conversation (because I don't think it'll lead > anywhere) but you've nerd-sniped me a little bit. Well, you started it by saying it was impossible. :) > > In 3.8, foo(a := 42) is in fact valid syntax, meaning the

[Python-ideas] Re: Idea/PEP draft: Add support of __main__.py to argparse.ArgumentParser.prog

2019-08-24 Thread Andrew Barnert via Python-ideas
On Aug 24, 2019, at 13:16, Michael Hooreman wrote: > > I'll consider what you say, and try to understand what entrypoint is. I have > understood entrypoint as a wording for an entry point (main) script. Sorry. Well, it _is_ that, but the point is that setuptools can auto-generate those main

[Python-ideas] Re: Idea/PEP draft: Add support of __main__.py to argparse.ArgumentParser.prog

2019-08-24 Thread Andrew Barnert via Python-ideas
On Aug 24, 2019, at 08:48, Michael Hooreman wrote: > > Let me clarify a bit. Setuptools and standalone scripts is indeed the > best classical approach, but that does not adapts to my use case. I'm > working with a contunuously, fast evolving system, and there is no > "identified release"

[Python-ideas] Re: Idea/PEP draft: Add support of __main__.py to argparse.ArgumentParser.prog

2019-08-24 Thread Andrew Barnert via Python-ideas
On Aug 24, 2019, at 00:25, Michael Hooreman wrote: > > In fact, I should add more than the python executable in prog: it must > contain -m and the package « classpath » But that’s not a valid prog. If you try to execute the program “python -m spam” with arguments “eggs” and “cheese” (whether

[Python-ideas] Re: Custom string prefixes

2019-08-26 Thread Andrew Barnert via Python-ideas
> On Aug 26, 2019, at 18:41, stpa...@gmail.com wrote: > > Thanks, Andrew, for your feedback. I didn't even think about string > **suffixes**, but > clearly they can be implemented together with the prefixes for additional > flexibility. What about _instead of_ rather than _together with_? Half

[Python-ideas] Re: Custom string prefixes

2019-08-26 Thread Andrew Barnert via Python-ideas
On Aug 26, 2019, at 16:03, stpa...@gmail.com wrote: > > In Python strings are allowed to have a number of special prefixes: > >b'', r'', u'', f'' >+ their combinations. > > The proposal is to allow arbitrary (or letter-only) user-defined prefixes as > well. > Essentially, a string

[Python-ideas] Re: Custom string prefixes

2019-08-27 Thread Andrew Barnert via Python-ideas
On Aug 27, 2019, at 01:42, Chris Angelico wrote: > > Will these "custom > prefixes" be able to define anything syntactically? If not, why not > just use a function call? And if they can, then you have created an > absolute monster, where a v-string in one context can have completely > different

[Python-ideas] Re: Custom string prefixes

2019-08-27 Thread Andrew Barnert via Python-ideas
On Aug 26, 2019, at 23:43, Serhiy Storchaka wrote: > > 27.08.19 06:38, Andrew Barnert via Python-ideas пише: >> * JSON (register the stdlib or simplejson or ujson), > > What if the JSON suffix for? I think you’d mainly want it in combination with percent-, html-, or uu-equa

[Python-ideas] Re: [new idea] dynamic return with using function argument

2019-08-26 Thread Andrew Barnert via Python-ideas
On Aug 26, 2019, at 08:38, Guido van Rossum wrote: > > Sorry, there is no way to leverage the implementation or syntax of := for > this purpose. You must be misunderstanding how they it works. > > You are right that the initial value of the variable at the call site is > irrelevant (but there

[Python-ideas] Re: Custom string prefixes

2019-08-27 Thread Andrew Barnert via Python-ideas
On Tuesday, August 27, 2019, 11:12:51 AM PDT, Chris Angelico wrote: >On Wed, Aug 28, 2019 at 3:10 AM Andrew Barnert via Python-ideas > wrote: >> Before I get into this, let me ask you a question. What does the j suffix >> give us? You can write complex numbers wi

[Python-ideas] Re: Custom string prefixes

2019-08-27 Thread Andrew Barnert via Python-ideas
On Aug 27, 2019, at 14:41, Chris Angelico wrote: > >> On Wed, Aug 28, 2019 at 6:03 AM Andrew Barnert wrote: >> >>> On Tuesday, August 27, 2019, 11:12:51 AM PDT, Chris Angelico >>> wrote: >>> If your conclusion here were "and that's why Python needs a proper >>> syntax for Decimal literals",

[Python-ideas] Re: Custom string prefixes

2019-08-27 Thread Andrew Barnert via Python-ideas
On Aug 27, 2019, at 18:59, Steven D'Aprano wrote: > > On Tue, Aug 27, 2019 at 10:07:41AM -0700, Andrew Barnert wrote: > >>> How is that different from passing a string argument to a function or >>> class constructor that can parse that token however it wants? >>> >>> x'...' >>> >>>

[Python-ideas] Re: Custom string prefixes

2019-08-27 Thread Andrew Barnert via Python-ideas
> On Aug 27, 2019, at 18:19, Chris Angelico wrote: > >>> On Wed, Aug 28, 2019 at 10:52 AM Andrew Barnert wrote: >>> >>> On Aug 27, 2019, at 14:41, Chris Angelico wrote: >>> All the examples about Windows paths fall into one of two problematic boxes: >>> >>> 1) Proposals that allow an

[Python-ideas] Re: Inspired by Scala, a new syntax for Union type

2019-08-30 Thread Andrew Barnert via Python-ideas
On Aug 30, 2019, at 02:09, Philippe Prados wrote: > > Why not extend isInstance to : > > isinstance(object:Any,classinfo: Iterable | Union) ? How would you pass a single type? And once you allow a single type, you shouldn’t have to do anything special to allow a Union, because a Union is

[Python-ideas] Re: Inspired by Scala, a new syntax for Union type

2019-08-30 Thread Andrew Barnert via Python-ideas
On Aug 30, 2019, at 11:26, Philippe Prados wrote: > > May be, with >> isinstance(object:Any,classinfo: Tuple | Union) ? > > it's possible to accept > > isinstance(anUnion, [Union]) # Force tuple for Union > isinstance(aTuple, [Tuple] # Force Tuple > isinstance(aStr, int | str) > > Correct ?

[Python-ideas] Re: Inspired by Scala, a new syntax for Union type

2019-08-30 Thread Andrew Barnert via Python-ideas
On Aug 30, 2019, at 18:40, Pasha Stetsenko wrote: >> I can’t think of any uses other than Optional. > > Also, in IPython and Jupyter Lab `?smth` displays help for symbol `smth`. Yeah, and probably more Python users regularly use IPython than, say, BASIC, so maybe a bit more potential for

[Python-ideas] Re: Inspired by Scala, a new syntax for Union type

2019-09-03 Thread Andrew Barnert via Python-ideas
On Sep 2, 2019, at 23:50, Philippe Prados wrote: > > Add a new operator for `Union[type1|type2]` ? Hold on. Are you proposing `Union[t1 | t2]` as a new spelling for `Union[t1, t2]`? That seems pointless. I thought you were proposing just `t1 | t2`, which seems a whole lot more useful (and no

[Python-ideas] Re: Inspired by Scala, a new syntax for Union type

2019-09-03 Thread Andrew Barnert via Python-ideas
On Sep 2, 2019, at 23:50, Philippe Prados wrote: > > Like Kotlin, add a new `?` operator to use syntax like `int?` ou `?int` ? > CONS: It’s not compatible with IPython and Jupyter Lab `?smth` displays help > for symbol `smth` > CONS: With default arguments, `?=` looks... not great > def

[Python-ideas] Re: Custom string prefixes

2019-09-03 Thread Andrew Barnert via Python-ideas
On Sep 3, 2019, at 06:17, Rhodri James wrote: > >> On 03/09/2019 13:31, Chris Angelico wrote: >>> On Tue, Sep 3, 2019 at 10:27 PM Rhodri James wrote: >>> On 31/08/2019 12:31, Chris Angelico wrote: We call it a string, but a bytes object has as much in common with bytearray and

[Python-ideas] Re: Inspired by Scala, a new syntax for Union type

2019-09-03 Thread Andrew Barnert via Python-ideas
On Sep 3, 2019, at 19:45, Steven D'Aprano wrote: > > On Thu, Aug 29, 2019 at 06:20:55PM +0100, Rob Cliffe via Python-ideas wrote: > >>> isinstance(x, str | int) ==> "is x an instance of str or int" >> >> Er, is that necessary when you can already write >> isinstance(x, (str, int)) > > It's

[Python-ideas] Re: Custom string prefixes

2019-08-29 Thread Andrew Barnert via Python-ideas
On Aug 29, 2019, at 04:58, Steven D'Aprano wrote: > > - quote marks are also used for function calls, but only a limited > subset of function calls (those which take a single string literal > argument). This is a disingenuous argument. When you read spam.eggs, of course you know that that

[Python-ideas] Re: Custom string prefixes

2019-08-29 Thread Andrew Barnert via Python-ideas
On Aug 29, 2019, at 00:58, Paul Moore wrote: > > If you > assume everything should be handled by general mechanisms, you end up > at the Lisp/Haskell end of the spectrum. If you decide that the > language defines the limits, you are at the C end. And if you don’t make either assumption, but

[Python-ideas] Re: Custom string prefixes

2019-08-28 Thread Andrew Barnert via Python-ideas
On Aug 28, 2019, at 00:40, Chris Angelico wrote: > > On Wed, Aug 28, 2019 at 2:40 PM Andrew Barnert wrote: >>> People can be trusted with powerful features that can introduce >>> complexity. There's just not a lot of point introducing a low-value >>> feature that adds a lot of complexity. >>

[Python-ideas] Re: Inspired by Scala, a new syntax for Union type

2019-08-29 Thread Andrew Barnert via Python-ideas
On Aug 29, 2019, at 05:25, Philippe Prados wrote: > > Hello everybody, > Scala 3 propose the a new syntax for Union type. See here. I propose to add a > similar syntax in Python. > # Operator for Union > assert( int | str == Union[int,str]) > assert( int | str | float == Union[int,str,float]) >

[Python-ideas] Re: Custom string prefixes

2019-08-29 Thread Andrew Barnert via Python-ideas
On Aug 29, 2019, at 07:52, Steven D'Aprano wrote: > >> On Thu, Aug 29, 2019 at 05:30:39AM -0700, Andrew Barnert wrote: >>> On Aug 29, 2019, at 04:58, Steven D'Aprano wrote: >>> >>> - quote marks are also used for function calls, but only a limited >>> subset of function calls (those which

[Python-ideas] Re: Inspired by Scala, a new syntax for Union type

2019-08-29 Thread Andrew Barnert via Python-ideas
On Aug 29, 2019, at 12:54, Chris Angelico wrote: >> Either one seems a lot better than breaking backward compatibility by adding >> new operator methods to the type type. >> > > How does that break backward compat? It doesn’t make Python backward incompatible; it does mean that if typing or

[Python-ideas] Re: Custom string prefixes

2019-08-29 Thread Andrew Barnert via Python-ideas
> On Aug 29, 2019, at 06:40, Rhodri James wrote: > > However, it sounds like what you really want is something I've often really > wanted to -- a way to get the compiler to pre-create "constant" objects for > me. People often say they want this, but does anyone actually ever have a good

[Python-ideas] Re: Inspired by Scala, a new syntax for Union type

2019-08-29 Thread Andrew Barnert via Python-ideas
On Aug 29, 2019, at 15:28, Guido van Rossum wrote: > > A wart will be that we can make `int | None` work but we shouldn't make `None > | int` work (I don't want to add any new operator overloads to `None`, it > should always be an error). Is there a reason that type.__ror__ wouldn’t handle

[Python-ideas] Re: Inspired by Scala, a new syntax for Union type

2019-08-29 Thread Andrew Barnert via Python-ideas
On Aug 29, 2019, at 16:03, Dominik Vilsmeier wrote: > > I never really understood the importance of `Optional`. Often it can be left > out altogether and in other cases I find `Union[T, None]` more expressive > (explicit) than `Optional[T]` (+ the latter saves only 3 chars). > Especially for

[Python-ideas] Re: Inspired by Scala, a new syntax for Union type

2019-08-29 Thread Andrew Barnert via Python-ideas
On Aug 29, 2019, at 16:32, Guido van Rossum wrote: > > Surely the meaning of `?` in a programming language also has to be learned. > And not every language uses it to mean "optional" (IIRC there's a language > where it means "boolean" -- maybe Scheme?) Sure, ? does mean lots of different

[Python-ideas] Re: Inspired by Scala, a new syntax for Union type

2019-08-29 Thread Andrew Barnert via Python-ideas
On Aug 29, 2019, at 18:10, Guido van Rossum wrote: > >> On Thu, Aug 29, 2019 at 5:56 PM Andrew Barnert via Python-ideas >> wrote: >> I think {int, str}, which someone proposed in one of the earlier >> discussions, is nice. What else would a set of types me

[Python-ideas] Re: Custom string prefixes

2019-08-29 Thread Andrew Barnert via Python-ideas
On Aug 29, 2019, at 16:58, Greg Ewing wrote: > > Steven D'Aprano wrote: >> I don't think that stpa...@gmail.com means that the user literally assigns >> to locals() themselves. I read his proposal as having the compiler >> automatical mangle the names in some way, similar to name mangling

[Python-ideas] Re: adding support for a "raw output" in JSON serializer

2019-08-23 Thread Andrew Barnert via Python-ideas
On Aug 23, 2019, at 00:33, Richard Musil wrote: > > Why simplejson remained separated from the main CPython is also a question (I > guess there was/is a reason), because it seems like including the code > completely and maintain it inside CPython could be better use of the > resources. The

[Python-ideas] Re: Idea/PEP draft: Add support of __main__.py to argparse.ArgumentParser.prog

2019-08-23 Thread Andrew Barnert via Python-ideas
There’s no need for this to be a PEP at this point. You only write those after discussion on -ideas, once you have the ideas nailed down, answers to all of the objections, all of the bikeshedding issues out in the open, and consensus that the idea is ready for a final decision. I’m not even

[Python-ideas] Re: Idea/PEP draft: Add support of __main__.py to argparse.ArgumentParser.prog

2019-08-23 Thread Andrew Barnert via Python-ideas
One more thing: from reading your proposal, it sounds like your actual issue may be that you’ve got something you want to distribute to end-users who aren’t Python experts to run as `python -m spam`, and the usage messages they get back are confusing them? If so, why not just use a setuptools

[Python-ideas] Re: adding support for a "raw output" in JSON serializer

2019-08-23 Thread Andrew Barnert via Python-ideas
On Aug 23, 2019, at 09:45, Christopher Barker wrote: > > Andrew, thanks for the background. > >> On Fri, Aug 23, 2019 at 8:25 AM Andrew Barnert via Python-ideas >> wrote: > >> Also, IIRC, it doesn’t do any post-check; it assumes calling str on any >> De

  1   2   3   4   5   6   7   8   >