On Jul 17, 2019, at 20:23, Andrew Barnert via Python-ideas
wrote:
>
>> On Jul 17, 2019, at 18:41, Yonatan Zunger wrote:
>>
>> I'm in the middle of developing a fancy heap profiler for Python (for those
>> times when tracemalloc isn't enough), and in the p
using it for scope painting
interferes with using it for anything else, which could be a problem for some
of the kinds of uses you’re talking about. So, it’s not a production solution.
But considering how trivial it should be slap together something that works in
Python 3.7, it may be good enough
Op 18 jul. 2019 om 03:41 heeft Yonatan Zunger het volgende
geschreven:
> Hi everyone,
>
> I'm in the middle of developing a fancy heap profiler for Python (for those
> times when tracemalloc isn't enough), and in the process, thought of a small
> change in the int
whatever, they could just as easily
be characters that are legal elsewhere in the URL as characters that happen to
not be legal anywhere.
(If you’re just talking about mitigating one particular attack after it’s been
discovered, that’s a different story. If checking for \n patches things without
w
problems but otherwise provide the same behavior.
___
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
ut meaning type(lhs)(chain(…)) on some types, so
why do the equivalent with @?)
___
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archiv
, (a, b, c) is <, c>, etc. So,
you don’t have to gloss over anything; s1 * s2 * s3 gives you elements ((a, b),
c), but those are identical to elements (a, b, c).
The reason it’s important in Python is that Python tuples aren’t mathematical
tuples (except maybe for len==2). But then Py
a specific) version in site-packages so they aren’t burdened by the release
cycle. Would that not be appropriate for the way packaging needs TOML?
___
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to python-ideas-le...@python.
ide effects, you want a statement. That’s why #3 is better than #2, beyond the
watered memory.
Sometimes you want to violate guidelines like that, but in that case it’s
usually worth explicitly marking that you're doing so. Which you can do easily
and concisely in today’s Python:
#4
cons
implement—and for everyone to
understand future Python code—if it is.
I don’t think anyone cares about fast locals here, and I hope nobody cares
about things like super magic. But the differences in how variables in the
namespace interact with functions and classes (and
new-kind-of-namespa
ust scrap the nice context managers and
use finally, or add two more layers of indentation, or, most commonly, just
punt on the problem and don’t handle errors correctly.
So, I think adding with to the idea makes it a lot more compelling.
___
Python
> there is no modification required?
The maxlen of 0 means after determining that 0+1 > 0, the (C) function returns
without even getting to the array manipulation stuff. Consuming the iterator in
a for loop does even less work inside the loop, but it means the loop is in
Python rather than C,
hod was even
one of the core examples. And, as PEP 570 points out, METH_FASTCALL makes that
potentially true for pure Python functions as well, to the extent that some
other stdlib functions might actually want to lose their keyword args.
All that being said, this proposal seems like something th
th keyword arguments imo.
Look at the signatures for range and isinstance: range takes an optional
argument on the left (or, if you prefer, it’s an overload of two different
signatures), which can’t even be expressed in Python syntax; isinstance takes a
class or a tuple of classes in the same pa
in builtins
named debug_context(), it seems like any feasible version of this could already
be written and used in Python today. (The first one, using static frame info,
should be about 3 lines of inspect calls.)
> ?identifier
>
> would print "identifier: value." Repr as bef
se, not something like for…else that some experts use but
most people live without.
(But I don’t have a better syntax to offer. I actually like with…except, if it
were just for my use, but on reflection I can see why others find it confusing.
Just like for…else.)
____
worthwhile goal, and at present the only way to achieve
it is with somewhat verbose and clunky code.
___
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-ideas.py
d of code really is a serious problem, then the proposal doesn’t
solve it; we need a proposal everyone will be able to learn and use. (And if
it’s not a serious problem, then the proposal isn’t needed in the first place.)
_______
Python-ideas mailing list -- py
ment parsing
> in it, for example:
>
> # main.py
> def __run__(first_num, second_num, print_operation=False):
Couldn’t you get nearly the same effect in Python today just by adding one line:
__run__(*sys.argv[1:])
That doesn’t do any fancy parsing of the arguments, but, except fo
On Jul 30, 2019, at 20:49, Andrew Barnert via Python-ideas
wrote:
>
> There are lots of great third-party libraries that make turning a function
> into a command-line utility a lot easier than using argparse. I think
> whenever you want anything more than argv and don’t want a
dirty scripts, but would be
disastrous for many other programs.)
So… never mind.
_______
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-ideas.p
sure than coding) it helps to have as much information as
possible at your fingertips. Oh, I know you can always work through a
trace (if one is available) to see exactly where an error occurred, but
that takes time.
___
Python-ideas mailing
should
be implemented. I just don't want its merits to be overlooked.)
___
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Mess
the magic code know that print_operation is a flag that takes
no arguments?
Especially if I type this:
python run.py —print_operation 1 2
With argparse, getopt, click, etc., this works because I’ve specified that it’s
a zero-argument flag; if I hadn’t, it would be equivalent to
—print_operati
e them (unless you want to from itertools import * they need
minor edits).
I think the original reason not to do so was that the module was pure C code,
and the recipes don’t need to be in C, and are as useful as sample code as they
are for direct use, so they should remain in Python. Given that
On Aug 1, 2019, at 09:27, Christopher Barker wrote:
>
>
>
>> On Thu, Aug 1, 2019 at 9:19 AM Andrew Barnert via Python-ideas
>> wrote:
>
>> > Given that in 3.x every stdlib module is supposed to be in Python with an
>> > optional C accelerator,
>
On Aug 1, 2019, at 10:48, Eli Berkowitz wrote:
>
> In terms of an argument for why it should be included, for most Python users
> the itertools recipes remain unseen.
Sure. But do you also know all of the functions in the module? Would you notice
or a new one got added? In practi
to "bother".
___
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-idea
h that a lot faster than 3 years in. If not, the packaging team will
probably be disappointed to hear it…
(I have occasionally had other people insist that I shouldn’t tell users to pip
install things… but those are the same people insisting I should always start
by explaining how to do it i
dation, where a list of packages can be given that
> aren't category killers, but have been given the blessing of the
> Python devs as "this is a good-quality, well-maintained package, and
> can be depended on"?
I agree.
I don’t think more-itertools meets the category-killer
n_votes(votes))
if no >= total//2:
# etc.
I even found an actual example of the equivalent in some C++ code I had on my
hard drive:
if (no == ask(…)) {
// …
}
In Python, that would be:
if no == ask(…):
Also, even if that weren’t a problem, this would be
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
>
rlier
> in the thread someone said PEP 399 says all modules have to have a pure
> Python implementation. But now you say everything in itertools MUST be
> implemented in C? Why is that? Why can't we just put the Python
> implementations of the recipes as-is directly into itertools?
of the pitch for yield from that I
can’t remember.)
___________
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
ht
e plus grouper plus some of
the less trivial recipes (or, more simply, just all of them, to avoid
bikeshedding arguments on each one) is.
_______
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
h
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 func
d to live without once you get used to
them. Also, most of them are curses or otherwise full-screen.
_______
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailm
ys I just rely on IPython’s, which
completes filenames. But it doesn’t have quite the same features. On the one
hand, it has Jedi awesomeness, which is hard to live without once you get used
to it. (And it’s especially fun when the local C++ or Go fanatic tells you that
Python sucks because there’
> On 8 Aug 2019, at 12:22, Richard Musil wrote:
>
> I have found myself in an awkward situation with current (Python 3.7) JSON
> module. Basically it boils down to how it handles floats. I had been hit on
> this particular case:
>
> In [31]: float(0.64417
for when they switch to exponential
numbers, and how they represent that. And a C++ library may well represent
64-bit integers above 1<<56 imprecisely, while Python won’t. And, beyond
numbers, different libraries produce different white space, different ordering
within dicts, and differ
when the values
are unchanged.
_______
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python
Would this work for you?
import struct
floatval = 0.6441726684570312
s = struct.pack("d", floatval) # converts floatval into a string (Python
2) or bytes (Python 3), of 8 raw bytes
# then serialise s
To be portable between different platforms, you would also need to store
whether
our
example, since that’s what you did in version 1 and 2) now requires keyword
boilerplate on every line where you construct one. And, since you generally
construct and use a class many times, but only define it once, that’s adding a
lot more boilerplate than it’s saving.
Also, even in the defin
u really do need support for raw output, you’d need a new hook besides
default, say, rawdefault. This wouldn’t be hard. Other than passing it up and
down the chain of APIs, the only trick should be the C and Python code down in
_iterencode that that do this:
o = _default(o)
s you
add in encode only affect the top-level value, not values inside arrays or
objects.
_______
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-
On Aug 8, 2019, at 15:01, Ryan Fox wrote:
>
> I don't see why you would want to access arguments by their position.
Because that’s the way it’s worked since Python 1.x, and there’s tons of
existing code that expects it, including the default __str__ and __repr__ for
exceptions a
ing problem at all, so if your argument is that we
should include it to solve that problem, you need a new argument.
—-
* Python, and I believe simplejson, still conforms to RFC 7159, which was the
standard until December 2017, so if you wanted to make an argument from 7159,
that _might_
complexity for the reader to deal with, so I think you’re still
better off not doing it.
(As a side note, you probably want a numerical stable average like the ones in
statistics or numpy, rather than one that accumulates float rounding errors
indiscriminately, but that’s another issue.)
___
On Aug 9, 2019, at 12:00, Ryan Fox wrote:
>
> > If you’re wondering why this works, it’s because Error and InputError don’t
> > override __new__. Which should make it obvious why a tutorial aimed at
> > novices doesn’t get into the details, but that’s why Python has r
he only JSON docs you ever receive
are just individual numbers, and they’re all between -0.1 and -0.2, so the only
possible error that can arise is this one. And so on. But I doubt any of those
is common.
___
Python-ideas mailing list -- python-ideas@p
thing to parse in the world, but why duplicate the parser (and potentially
create new bugs) if you already have one?
_______
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.pyth
Decimal can’t solve for anyone; there’s no additional problem that Decimal
can’t solve here that’s only faced by your weird app.
> But an application
> that cared about that would be pretty weird. So I think a
> "use decimal" option would cover the vast majority of use
> c
explained in the docs.) JS implementations before ES5 serialized and parsed
NaN, Infinity, and -Infinity, even though the informal spec said they
shouldn’t. Lots of other libraries followed suit. (Some also accept or even
produce nan, int, -inf, because that’s what most C libraries output—as do
Pytho
ple. The
two strings that he’s complaining about are different string representations of
the same float value. It’s not the value he’s complaining about, but the fact
that Python won’t give him the same string representation for that float that
his C++ library does, and therefore dumps(loads(…)) isn’
g that
you asked what you asked, and then pretending to have a different problem in
hopes that different problem might be solved by the feature you asked for, so
maybe the feature will be added so you can misuse it for what you really wanted.
_______
Python-id
On Aug 11, 2019, at 19:01, [email protected] 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 n
e do it. So, you load a JSON document with the string “abc\/def”,
you get the Python string “abc/def”, you dump it and get a JSON document with
“abc/def”. JSON says the two documents are identical, but they obviously aren’t
the same bytes.
Similar issues include case for hex letters in \u escap
he original JS reference implementation)
break the spec in that way that it’s useful to have an option to do the same.
(Even without that option, Python raises a ValueError instead of emitting null,
but that’s not a way to get invalid JSON, it’s just a way to not get any JSON
when the libra
mark. So again, I don’t think it’s likely anyone will volunteer if you
don’t provide some reason to expect it to pan out.
Even if you can’t edit hairy C code like longobject.c, you can write simple
Python code and benchmark it, search the list archives, etc., just as well as
anyone else. If that’s no
at’s as readable as possible for a single line that meets
the standards of an entry in all of JSONlines, NDJ, and LDJSON. But at the time
nobody could have known about JSONlines, or that 7-bit-clean pretty-printed
JSON would never be useful, etc.
_____
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 implementati
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
>
de local functions? Classes defined within the
function? Exec from within the function (does it depend whose locals are
passed)?
What about a callable that’s not a function or class? Does it just catch
exceptions raised inside the __call__ method itself?
And so on.
______
o generate invalid JSON if they want to" is not
> without precedent.
Sure, and as soon as you discover another special case that millions of
existing programs expect to be handled in a way that violates the RFC, that
somehow nobody has noticed in the last 16 years, file a bug to handle that wit
with you that we
probably don’t want to add that support in the first place. But, as you say, at
least some people disagree, so…)
_______
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-ideas.pytho
e
It seems to me this idea will help library users more correctly handle their
exceptions if this is problematic. This will save time and make code more
reliable.
___
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to
t be looked up anywhere. Avro is intentionally unversioned because it
will never change, according to version 1.8 of the spec. And so on. We’re in
great shape for the future. :)
_______
Python-ideas mailing list -- [email protected]
To unsubscribe send an email
e it, and can go find a
library for it themselves.
Still, if Python had the “loose recommendations from core devs” links thing
discussed in another thread, some of these packages might qualify. If someone
really wants that, they should probably read over what’s been said about it so
far an
expecting that one of the many JSON-based and
JSON-like formats is going to become an official successor to JSON and take
over its ubiquity. But that really isn’t likely (and you aren’t going to make
it any more likely by arguing for it on python-ideas, and even less so by
arguing for four of the
as shown any need for any of the other stuff.
> * support for extensions to the JSON standard (JSON5, etc.)
One guy saw a bunch of shiny new protocols (half of which are actually stagnant
dead protocols) and thought that if the Python stdlib added support for all of
them, they’d all take over t
that accepts ast_list as a subclass. (The
lists_as_nodes flag becomes slightly more complicated, but still pretty
simple—and besides, that’s all under-the-covers code.)
___
Python-ideas mailing list -- [email protected]
To unsubscribe send an emai
n, provide exactly this
functionality (usually under the name for_json, because __json__ has double
underscores and is therefore reserved for Python and its stdlib), and there are
definitely people who like it. If you read the simplejson docs, and search for
code that imports it, you can
et from choice?)_______
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/lis
the only thing anyone wants from it is something that doesn’t make
sense, then maybe we’re better off without it?
_______
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.py
resources.
The README explains that: “simplejson is the externally maintained development
version of the json library included with Python 2.6 and Python 3.0”.
This has multiple advantages:
* It can evolve much more quickly than the 18-month stdlib cycle. Notice that
it’s gone from 1.0 to 3.16.1
23, 2019, at 08:16, Michael Hooreman wrote:
>
> Hello,
>
> I have a proposal to improve support of __main__.py (python -m foobar)
> invocation to argparse.ArgumentParser
>
> You can find attached a PEP draft.
>
> Unfortunately, I'm not very confident on how to a
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
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
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”
But, it this is THE only way correct way to do, why do python allows
> __main__.py?
This is a silly question. Imagine you were asking how to insert a value into
the middle of a tuple, and, after telling you how you can sort of do the
immutable equivalent of what you’re asking, I also pointed out
our scripts to munge the usage output might well
be a better use of your time than days learning a new tool and adapting your
workflow to it.
That doesn’t mean we should necessarily change the stdlib of Python to
encourage more people to build workflows like yours in the future instead of
more
needing it.
This is important. Even if you come up with something better than simplejson,
it’s highly unlikely to actually help you unless you can extract it into a
backport that you can publish and maintain on PyPI, unless you only need the
new feature for code whose release date is so far i
*error with the null check). That
isn’t that hard to add to a C-style language—and it actually fits better into
Python, where there is no explicit dereferencing anywhere. And you can still
“pass” an uninitialized variable or leave it out, because you’re not really
passing anything, you’re just
tvar)') but in the caller it will
> require special syntax because the Python compiler can't know the signature
> of the called function (this is not a limitation of the CPython bytecode
> compiler but a feature of the language).
Right; the caller can’t know any more than that
On Aug 26, 2019, at 16:03, [email protected] 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-on
t’s declared
or inferred to take a regex if that happens to be readable in your use case, so
there’s no need for a suffix syntax.) Which is neat, but obviously not
applicable to Python.
> And your idea that ` ` is conceptually no different
> than
> ` ` is absolutely insightful.
We
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
look more carefully at the C++ rules for that?)
___________
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
htt
On Aug 27, 2019, at 08:52, Steven D'Aprano wrote:
>
>> On Tue, Aug 27, 2019 at 05:24:19AM -0700, Andrew Barnert via Python-ideas
>> wrote:
>>
>> There is a possibility in between the two extremes of “useless” and
>> “complete monster”: the prefix accept
ut I’d still do it at the REPL, and likely in
real code as well. But I don’t think that choice would make my code worse
(because when setup costs matter, I _wouldn’t_ make that choice), so I don’t
see that as a problem.
_______
Python-ideas mailing list -- pyt
a method?
What happens if utcoffset raises NotImplementedError? (Or anything else, I
suppose, but NotImplementedError is the documented behavior for the base class.)
Should date get an attribute that’s always False, or is it sufficiently obvious
to most people that dates are always nai
On Tuesday, August 27, 2019, 11:42:23 AM PDT, Serhiy Storchaka
wrote:
> 27.08.19 20:07, Andrew Barnert via Python-ideas пише:
>> Before I get into this, let me ask you a question. What does the j suffix
>> give us? You can write complex numbers without it just fine:
>>
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
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 P
hung up on the fact that these affixes
don’t really give us “literals” back in either 2013 or 2016, and I don’t want
to rehash that argument. I could point out that nobody cares that -1 isn’t
really a literal, and almost nobody cares that the CPython optimizer
special-cases its way around that
27;t know how many there are. The only ones I can think of are "f"
> for single-precision float, and the long and unsigned suffixes on
> integers.
Of the top of my head, there are also long long integers, and long doubles, and
wide and three Unicode suffixes for char. Those probably
far, even Steven’s facetious quaternion example that he proposed as too
ridiculous for anyone to actually want.
Is it a flaw that there may or may not be some examples that nobody has been
able to think of that might work with a much more complicated feature but won’t
work with this fea
that they’d
all be unfamiliar cryptic one-letter things, is likely to arise.
___________
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-id
On Aug 28, 2019, at 01:05, Paul Moore wrote:
>
> On Wed, 28 Aug 2019 at 05:04, Andrew Barnert via Python-ideas
> wrote:
>> What matters here is not whether things like the OP’s czt'abc' or my 1.23f
>> or 1.23d are literals to the compiler, but whether the
ple,
it’s probably still worth looking at whether it’s feasible.
_______
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message ar
401 - 500 of 1690 matches
Mail list logo
