>
> A regex that's vulnerable to pathological behavior is a DoS attack waiting
> to happen. Especially when used for parsing log data (which might contain
> untrusted data). If possible, we should make it harder for people to shoot
> themselves in the feet.
>
While definitely not as bad and not as
On Mon, Jul 30, 2018 at 8:43 AM, Petr Viktorin wrote:
> On Mon, Jul 23, 2018 at 2:16 PM, Miro Hrončok wrote:
>
> > It might be:
> >
> > $ python3 -m gettext
>
> +1
>
> > And:
> >
> > $ python3 -m gettext.msgfmt
>
> +1
> Note that this means gettext will need to become a package.
>
> > And (p
On Tue, Aug 28, 2018 at 12:57 PM Guido van Rossum wrote:
> However, a user who doesn't typically think about the actual semantics of
> iterable unpacking and tuple packing might think this would instead mean
> the following:
>
> a += x
> b += x
> c += x
>
> IOW they might think that this is
"more-itertools" seems to be a modestly popular library (top 100-500?) that
includes the stdlib itertools recipes and more.
https://more-itertools.readthedocs.io/en/stable/api.html#more_itertools.powerset
On Tue, Oct 16, 2018 at 3:42 AM Hasan Diwan wrote:
> Pal,
> On Tue, 16 Oct 2018 at 01:36, P
Does it make sense to draw some sort of parallel between next(myiterator,
default="whatever") and mylist.pop(default="whatever")? They exhaust the
iterator/list then start emitting the default argument (if provided).
On Thu, Nov 1, 2018 at 2:46 PM Serhiy Storchaka wrote:
> 31.10.18 13:08, Antoin
Not to derail the conversation, but I've always been curious why the
itertools recipes are recipes and not ready-made goods (pre-baked?) that I
can just consume. They're great examples to draw from, but that shouldn't
preclude them from also being in the stdlib.
On Mon, Nov 12, 2018 at 7:41 PM Mic
Devils advocate: it might complicate things for someone that needs to use
FIPS, where MD5 can be a pain to deal with.
On Fri, Dec 7, 2018 at 8:50 AM Devin Jeanpierre
wrote:
> On Fri, Dec 7, 2018 at 1:40 AM Antoine Pitrou wrote:
>
>> md5 is only used for a quick integrity check here (think of it
In general, there is lots of code out in the wild that can't be updated for
whatever reason, e.g. the person that knows Python left and it needs to
continue to work. Weak argument, but cost-benefit I think it comes out
ahead. In your example there isn't a reason I can tell why swapping the
operands
What does it mean to be a universal parser? In my mind, to be universal you
should be able to parse anything, so you'd need something as versatile as
any Turing language, so one could stick with the one we already have
(Python). I'm vaguely aware of levels of grammar (regular, context-free?,
etc.),
On Tue, Jul 9, 2019 at 4:15 PM Andrew Barnert via Python-ideas <
[email protected]> wrote:
> On Jul 9, 2019, at 13:09, Shay Cohen wrote:
> >
> > >>> a: 3
>
> The reason this isn’t a syntax error is that Python allows any valid
> expression as an annotation. And “3” is just as valid an expre
I actually gave a talk along these lines at the Chicago Python (ChiPy)
meetup last week: slides
https://docs.google.com/presentation/d/1v5z4f-FQkS-bQYE-Xv5SvA6cyaTiqlxs2w2CI1yZcAU/edit?usp=sharing
Part of the argument was about using pure standard library so a
self-contained script/repo could run
On Tue, Aug 20, 2019, at 5:05 AM Matthew Brett
wrote:
> ... Unless you meant wheels for non-Intel platforms, in which case,
> please do say more about you need.
Minor tangent: I've seen some people use https://www.piwheels.org/ for
Raspberry Pi (ARM 6/7), but could the ARM binaries be uploaded
Currently the datetime docs say:
> An object of type time or datetime may be naive or aware. A datetime
object d is aware if d.tzinfo is not None and d.tzinfo.utcoffset(d) does
not return None. If d.tzinfo is None, or if d.tzinfo is not None but
d.tzinfo.utcoffset(d) returns None, d is naive. A ti
On Fri, Feb 7, 2020 at 10:11 AM Soni L. wrote:
> I'd like to see traits some day, with a syntax similar to this one:
> ...
> if the trait isn't used in the function definition you get the raw
> object, where name conflicts between traits (but not between traits and
> inherent methods) result in a
On Mon, Feb 24, 2020 at 11:51 AM Brianvanderburg2 via Python-ideas <
[email protected]> wrote:
> When running a python script directly, the directory of that script gets
> added to sys.path. When running as a module "python -m", it looks like an
> empty string gets added to sys.path, which
thon -I myscript.py`, but `-m mypkg` is I think
indistinguishable from trying to `import mypkg`, so it needs to be
discoverable on `sys.path`...this feels like an A/B problem: what are you
trying to do?
On Mon, Feb 24, 2020 at 3:35 PM wrote:
> Nick Timkovich wrote:
>
> > > Are you fa
Can you provide short, but non-trivial, clear examples of "before" (current
Python) and "after" (what you propose it looks like) to demonstrate the
advantage?
Will it be ambiguous with existing syntax?
On Tue, Feb 25, 2020 at 6:10 PM Nathan Edwards
wrote:
> I love regular expressions. I would l
>
> I understand it locks in that particular implementation detail, but it
> also seems unlikely that that particular optimization (int 0 and int 1 as
> specific memory objects) would ever make sense to NOT be including in a
> shipping implementation (future proof by practicality).
>
Do you explic
I once again had a use for heaps, and after rewrapping the heapq.heap*
methods for the umpteenth time, figured I'd try my hand at freezing
off that wart.
Some research turned up an older thread by Facundo Batista
(https://mail.python.org/pipermail/python-ideas/2009-April/004173.html),
but it seems
n?
On Sat, Oct 15, 2016 at 3:26 PM, Sven R. Kunze wrote:
> On 15.10.2016 20:15, Nick Timkovich wrote:
>>
>> I once again had a use for heaps, and after rewrapping the heapq.heap*
>> methods for the umpteenth time, figured I'd try my hand at freezing
>> off that wa
ze wrote:
> On 15.10.2016 23:19, Nick Timkovich wrote:
>>
>> Features and speed are good, but I'm interested in getting something
>> with the basic features into the Standard Library so it's just there.
>> Not having done that before and bit clueless, I'm wanting
>From that page:
> User-defined literals are basically normal function calls with a fancy
> syntax. [...] While user defined literals look very neat, they are not much
> more than syntactic sugar. There is not much difference between defining
> and calling a literal operator with "foo"_bar and doi
wrote:
> On Sat, Oct 29, 2016 at 12:43 PM, Nick Timkovich
> wrote:
>
>> From that page:
>>
>>> User-defined literals are basically normal function calls with a fancy
>>> syntax. [...] While user defined literals look very neat, they are not much
>>>
Also you can support future changes to the syntax (e.g. __matmul__ and
friends from 3.5, __aiter__ from 3.5.2) with a single codebase rather than
having to push that grammar back to previous versions (impossible?) or have
the grammar for magic methods be extraordinarily general (messy?)
On Tue, No
Currently, Numpy takes advantage of __iadd__ and friends by performing the
operation in-place; there is no copying or other object created. Numpy is
very thinly C, for better and worse (which is also likely where the +=
syntax came from). If you're doing vast amounts of numeric computation, it
quic
I think the best way to remove compound operators would be to go back in
time and hit Dennis Ritchie with a bat at the exact moment when the notion
of them crosses his mind.
In all seriousness, compound operators are in practically every modern
language and aren't going away. While you don't need
I think you could implement this yourself with metaclasses and it wouldn't
have much (if any) performance hit per-call or per-instantiation (just a
bit slower when creating the class definition).
It's a bit heavy-handed-hand-holding–if you ask me–but if you want to do
it, the language gives you th
You can do it at run-time, if you so desire, without a measurable
performance hit with a metaclass. Here's a hacky demo:
https://gist.github.com/nicktimko/5f08d6adfa1dbe1319c3bfc715ec0aa4#file-override_guard-ipynb
(Pedants: Any performance hit will be constant-time and probably less than
a stray i
Here's hopefully a working link; GitHub's rendering seems to be iffy:
https://nbviewer.jupyter.org/urls/gist.githubusercontent.com/nicktimko/5f08d6adfa1dbe1319c3bfc715ec0aa4/raw/37dd95cd92be7b7e5af01b98ce9e8e00a705b3f7/override_guard.ipynb
Knowing how to do some introspection with dunder magic att
I would consider the speed of the "ultimate error handler" (i.e. whatever
prints the traceback and kills the program) in the interpreter to be moot,
so long as it takes a small fraction of a second. Optimizing Python's speed
it crashes super-fast due to an *unhandled* NameError in your program seem
Is the goal to allow them to consume a finite generator of *unknown* length
(requires reservoir sampling
https://en.wikipedia.org/wiki/Reservoir_sampling with N random calls,
which seemed to be the rub before?) or just consume a generator with known
length that's not indexable (a rare beast?). Con
Out of curiosity, why do you prefer decimal values to refer to Unicode code
points? Most references, http://unicode.org/charts/PDF/U0400.pdf (official)
or https://en.wikibooks.org/wiki/Unicode/Character_reference/-0FFF ,
prefer to refer to them by hexadecimal as the planes and ranges are broken
>
> hex notation not so readable and anyway decimal is kind of standard way to
> represent numbers
Can you cite some examples of Unicode reference tables I can look up a
decimal number in? They seem rare; perhaps in a list as a secondary column,
but they're not organized/grouped decimally. Readab
Are you saying that hasattr returning False was hiding a bug or is a bug?
The former could be annoying to track down, though hasattr(X, 'y') == True.
For the latter, having hasattr return False if an AttributeError is raised
would allow the property decorator to retain identical functionality if it
If you're proposing throwing half of Python's current syntax in the bin,
this isn't the right list either.
If not marginally malicious, I think it's delusional to think a post to
Language X's lists by someone who recommends multiple breaking changes
would ever be accepted. The correct response (if
Why mention sys.ps1 == '>>> ', is that some inside joke I'm unaware of?
That is one of the easier things to modify (with a sitecustomize.py or
whatever).
On Thu, Jan 12, 2017 at 12:03 AM, INADA Naoki
wrote:
> > Built-in functions
> >
> > --
> >
> >
> >
> > Python is an object-ori
ctypes.Structure is *literally* the interface to the C struct that as Chris
mentions has fixed offsets for all members. I don't think that should
(can?) be altered.
In file formats (beyond net protocols) the string size + variable length
string motif comes up often and I am frequently re-implement
; construct doesn't automatically mean that we should stop improving the
> stdlib, but OTOH not every useful thing can or should be in the stdlib.
>
> Personally, I find myself parsing uleb128-prefixed strings more often than
> u4-prefixed strings.
>
> On Jan 19, 2017 1
Related and probably more common is the need for the line-continuation
operator for long/multiple context managers with "with". I assume that's
come up before, but was it also just a low priority rather than any
technical reason?
On Mon, Jan 23, 2017 at 1:53 PM, Brett Cannon wrote:
> Actually mu
After Django 1.11 (alpha 1 out now, final in few months, LTS EOL 2020) was
branched out from master on GH, it was pretty impressive & heartening to
see massive commits against master that removed Python 2 compatibility from
such a popular library.
On Thu, Jan 26, 2017 at 10:11 AM, Victor Stinner
If everything was contained right in the same file, this is sanctioning
another way to do it (when there should only be one obvious way). If you
have multiple modules/packages, horrors can evolve where a class method
could be patched in an unknown location by any loaded module (or you could
even in
for i in range(...) is *sometimes* indicative of code smell, especially
when then doing x[i], though it has its uses. I've never had a need to
shorten a for...range line though.
Other than it being "cute", do you have an example where it's definitively
better?
On Tue, Feb 14, 2017 at 4:03 PM, Tod
Make some shim object that you can index into to get that functionality,
could even call it Z (for the set of all integers). Short, and requires no
new syntax.
class IndexableRange:
def __getitem__(self, item):
if isinstance(item, slice):
start = item.start if item.start is
I think fundamentally by special-casing a for-loop variant, you have a
construct with limited/no generality that's simply an additional burden to
learn. You're kind of doing the opposite of converting print from a
statement into a function. I far prefer the print function because it's a
function li
I wouldn't see myself using it for an arbitrary value in the middle of the
list, but perhaps for the 0th or -1st (first/last) element of a list that
might be empty. Maybe also second-to-first/last if I'm initializing some
comparison between sequential items?
Some of the examples don't work with ne
>From my experience teaching Python to non-programmers, it's a huge
hurdle/nightmare to teach functions/methods that modify objects in-place
vs. return a value that must be reassigned. Behold Pandas's DataFrame's
sort method, which has an optional `in_place` argument that defaults to
*False*, which
I see the benchmarks, and while I assume the asymptotic complexity is the
same, is there a longer "start-up" time your optimizations need? Do you
have benchmarks where you sort 10, 100...10**6 items to show that beyond
the types you're sorting, you're not amortizing any increased overhead out
to ob
>
> I attended a talk at PYCON UK that talked to the point of using object
> composition
> rather then rich interfaces. I cannot recall the term that was used to
> cover this idea.
>
>
Separating things by concern/abstraction (the storage vs. the
serialization) results in easier-to-learn code, *e
GitHub shows that that note hasn't changed in 10 years:
https://github.com/python/cpython/blame/master/Doc/reference/datamodel.rst#L2210
On Mon, Apr 24, 2017 at 3:15 PM, Terry Reedy wrote:
> On 4/24/2017 12:14 PM, Stephan Hoyer wrote:
>
> Based on the change in the documentation between 2.x and
I was wondering that if there are so many arguments to a function that it
*looks* ugly, that it might just *be* ugly.
For one, too many required arguments to a function (constructor, whatever)
is already strange. Binding them as attributes of the object, unmodified in
a constructor also seems to b
On Sat, Jul 1, 2017 at 1:17 PM, Oleg Broytman wrote:
>
>I think the sentence "Python should have implement feature>" should be ;-) forbidden if it is not followed with
> "I'm in the middle of development. Expect the 1st PR in timeframe>."
>
>Python can only have features that You, the ,
On Fri, Jul 21, 2017 at 12:59 PM, David Mertz wrote:
>
> But you've left out quite a few binding operations. I might forget some,
> but here are several:
>
Ned Batchelder had a good presentation at PyCon 2015 about
names/values/assignments/binding: https://youtu.be/_AEJHKGk9ns?t=12m52s His
summa
On Tue, Aug 22, 2017 at 12:34 AM, Nick Coghlan wrote:
> Folks, this has come up before, but: please don't post through Google
> Groups, as it breaks everyone else's ability to easily reply to the
> entire mailing list.
>
Mentioning this is probably going to do nothing, especially for new, future
Knowing nothing about the JavaScript ecosystem (other than that leftpad is
apparently not a joke and everything needs more jQuery), what are the
leagues-above testing libraries?
On Tue, Aug 22, 2017 at 5:20 PM, [email protected] wrote:
> TBH you're completely right. Every time I see someone using
On Wed, Sep 13, 2017 at 10:54 AM, Jason H wrote:
>
> Thanks for the insights.
> I don't think it would be that breaking:
>
> def remap_map(a1, a2):
> if hasattr(a1, '__call__'):
> return map(a1, a2)
> elif hasattr(a2, '__call__'):
> return map(a2,a1)
> else:
> raise NotCallable #
On Sat, Nov 4, 2017 at 10:44 AM, M.-A. Lemburg wrote:
> Just to clarify: Python 2.0 was called 2.0 because the BeOpen marketing
> department thought it was good idea, not because there were major
> incompatible changes going into that release.
>
Alternative history question: if it was just 1.6,
Python does not use U+2010 HYPHEN for the minus operator, it uses the
U+002D (-) HYPHEN-MINUS.
In some monospace fonts, there is a subtle difference between U+002D,
U+2013 EN DASH, and U+2014 EM DASH, but it's usually hard to tell them
*all* apart.
If you want to make a proposal, I'd suggest that
I guess for reference:
exec('a\N{MIDDLE DOT} = 0')
exec('\N{BUHID LETTER RA} = 1')
exec('\N{HANGUL LETTER EU} = 2')
exec('\N{TIFINAGH LETTER YO} = 3')
exec('\N{BOPOMOFO LETTER I} = 4')
exec('\N{HANGUL LETTER ARAEA} = 5')
On Sun, Nov 19, 2017 at 1:38 AM, Serhiy Storchaka
wrote:
> 19.11.17 04:01,
On Tue, Nov 21, 2017 at 11:22 AM, Chris Barker
wrote:
> supposedly __repr__ is supposed to give an eval-able version -- which your
> proposal is. But the way you did your example indicates that:
>
> bytes((42, 43, 44, 45, 46))
>
> would be an even better __repr__, if the goal is to make it clear
On Tue, Nov 21, 2017 at 4:16 PM, Sven R. Kunze wrote:
> Maybe, that suffices: https://pypi.python.org/pypi/xheap
>
I still think the heapq.heap* functions are atrocious and they should
immediately be packaged with *no additional features* into a stdlib object
for reasons along the line of
https:/
On Tue, Nov 21, 2017 at 6:45 PM, Steven D'Aprano
wrote:
> On Tue, Nov 21, 2017 at 04:56:27PM -0600, Nick Timkovich wrote:
> > On Tue, Nov 21, 2017 at 4:16 PM, Sven R. Kunze wrote:
> >
> > > Maybe, that suffices: https://pypi.python.org/pypi/xheap
> >
On Mon, Nov 27, 2017 at 8:17 PM, Brett Cannon wrote:
> But calling it "atrocious" and so bad that it needs to be fixed
> "immediately" as if it's a blight upon the stdlib is unnecessarily
> insulting to those that have worked on the module. To convey the feeling
> that you think an OO wrapper wou
On Wed, Nov 29, 2017 at 7:21 AM, Daniel Moisset
wrote:
> As reference of prior art, there is https://pypi.python.org/pypi/munch in
> PyPI
>
Box is also popular as it permits deeper nesting:
https://pypi.python.org/pypi/python-box/ https://github.com/cdgriffith/Box
Addict is similar: https://pypi
On Thu, Nov 30, 2017 at 12:24 PM, Brett Cannon wrote:
> On Wed, 29 Nov 2017 at 13:28 Greg Ewing
> wrote:
>
>> Nick Coghlan wrote:
>>
>> >>What about more English-like syntax:
>> >>
>> >>X or else Y
>> >
>> > The problem with constructs like this is that they look like they
>> > should mean the s
If I'm understanding correctly, the interpreter already does this with
threads. About every 15 milliseconds the interpreter will stop a thread and
see if there are any others to work on, see "Grok the GIL," blog:
https://emptysqua.re/blog/grok-the-gil-fast-thread-safe-python/ or the
PyCon talk: htt
I think part of the reason that logging appears complicated is because
logging actually is complicated. In the myriad different contexts a Python
program runs (daemon, command line tool, interactively), the logging output
should be going to all sorts of different places. Thus was born handlers.
If
On Fri, Jun 29, 2018 at 8:58 PM, Matt Arcidy wrote:
> It seems like the very small percentage of academic users whose careers
> depend on this cannot resolve the political issue of forming a standards
> body.
>
> I don't see how externalizing the standard development will help. Kudos
> for short
>
> > This might be a silly idea but, would it be a good idea to have
> > ...[a:b:c] return a range(a, b, c)?
>
If a 'thunderscore' is acceptable:
import itertools
class _ranger:
@classmethod
def __getitem__(self, key: slice):
if isinstance(key, slice):
if key.stop is
I myself have proposed heap objects and seen that and other features come
up from time to time. I think the general mood is to use a PyPI library, or
even just vendor a single file from a package like xheap
https://github.com/srkunze/xheap/blob/master/xheap.py
If you wanted to stick with what's in
69 matches
Mail list logo
