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
>
> > 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
>
> 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
>
> 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
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
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 familiar with the -I option for "isolated mode&
On Mon, Feb 24, 2020 at 11:51 AM Brianvanderburg2 via Python-ideas <
python-ideas@python.org> 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
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
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
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
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, Jul 9, 2019 at 4:15 PM Andrew Barnert via Python-ideas <
python-ideas@python.org> 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
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?,
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
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
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
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,
"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,
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
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
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
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
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:
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
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
On Tue, Nov 21, 2017 at 6:45 PM, Steven D'Aprano <st...@pearwood.info>
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 <srku...@mail.de> wrote:
> >
> > > Maybe, that suffices
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
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
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
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
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
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:
>
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:
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
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
>
> 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,
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
>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*,
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
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,
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
ke
> 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 10:
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
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
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
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?).
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
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 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
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,
ail.com> wrote:
> On Sat, Oct 29, 2016 at 12:43 PM, Nick Timkovich <prometheus...@gmail.com>
> wrote:
>
>> From that page:
>>
>>> User-defined literals are basically normal function calls with a fancy
>>> syntax. [...] While user defined literals look
>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
ku...@mail.de> 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,
53 matches
Mail list logo