On Mon, Apr 1, 2019 at 8:54 PM Steven D'Aprano wrote:
> I can think of at least one English suffix pair that clash: -ify, -fy.
> How about other languages? How comfortable are you to say that nobody
> doing text processing in German or Hindi will need to deal with clashing
> affixes?
>
Here
On Mon, Apr 1, 2019 at 10:11 PM Dan Sommers <
2qdxy4rzwzuui...@potatochowder.com> wrote:
> So I've seen someone (likely David Mertz?) ask for something
> like filename.strip_suffix(('.png', '.jpg')). What is the
> context? Is it strictly a filename processing program? Do
> you subsequently
On Mon, Apr 01, 2019 at 09:34:21PM -0400, David Mertz wrote:
> On Mon, Apr 1, 2019, 8:54 PM Steven D'Aprano wrote:
>
> > The point I am making is not that we must not ever support multiple
> > affixes, but that we shouldn't rush that decision. Let's pick the
> > low-hanging fruit, and get some
On 4/1/19 9:34 PM, David Mertz wrote:
On Mon, Apr 1, 2019, 8:54 PM Steven D'Aprano wrote:
The point I am making is not that we must not ever support multiple
affixes, but that we shouldn't rush that decision. Let's pick the
low-hanging fruit, and get some real-world experience with the
I think the point Chris made about statistics.mode is important enough
to start a new subthread about API design, and the lessons learned.
On Mon, Apr 01, 2019 at 02:29:44PM +1100, Chris Angelico wrote:
> We're basically debating collision semantics here. It's on par with
> asking "how should
On Tue, Apr 2, 2019 at 11:53 AM Steven D'Aprano wrote:
> The point I am making is not that we must not ever support multiple
> affixes, but that we shouldn't rush that decision. Let's pick the
> low-hanging fruit, and get some real-world experience with the function
> before deciding how to
On Mon, Apr 01, 2019 at 02:29:44PM +1100, Chris Angelico wrote:
> The multiple affix case has exactly two forms:
>
> 1) Tearing multiple affixes off (eg stripping "asdf.jpg.png" down to
> just "asdf"), which most people are saying "no, don't do that, it
> doesn't make sense and isn't needed"
On Tue, Apr 2, 2019 at 9:34 AM Jonathan Goble wrote:
>
> On Mon, Apr 1, 2019 at 6:12 PM Greg Ewing wrote:
>>
>> Obviously, removing a whole day from the year will create problems
>> keeping the calendar in step with the seasons. To compensate, it
>> will be necessary to add approximately 1.25
On Mon, Apr 1, 2019 at 6:12 PM Greg Ewing
wrote:
> Obviously, removing a whole day from the year will create problems
> keeping the calendar in step with the seasons. To compensate, it
> will be necessary to add approximately 1.25 days worth of leap
> seconds to each year. This works out to
On 02Apr2019 10:43, Greg Ewing wrote:
Paul Moore wrote:
now that Python has type
inference, it should be possible for users to just type {} and have
the interpreter work out which was intended from context.
Or have {} return an ambiguous object that turns into a dict or
set depending on what
On 4/1/2019 1:14 AM, Guido van Rossum wrote:
We do have a parser generator in the standard library:
https://github.com/python/cpython/tree/master/Lib/lib2to3/pgen2
It is effectively undocumented and by inference discouraged from use.
The entry for lib2to3 in the 2to3 doc:
Anders Hovmöller wrote:
Please let's all agree that April 1 is the worst day of the year.
Agreed.
In light of that, I propose that the datetime module in Python 4
be changed so that April 1 does not exist:
>>> m31 = date(2019, 3, 31)
>>> m31 + timedelta(days = 1)
datetime.date(2019, 4, 2)
Paul Moore wrote:
now that Python has type
inference, it should be possible for users to just type {} and have
the interpreter work out which was intended from context.
Or have {} return an ambiguous object that turns into a dict or
set depending on what is done to it.
We could call it a
On 4/1/19 11:35 AM, Anders Hovmöller wrote:
Please let's all agree that April 1 is the worst day of the year.
I can't reproduce your problem. What version of Python are
you running, and on what OS?
Please show us your program, and tell us what you expected it
to do and what it did that
Am I being fooled ? I guess yes
That’s the worst idea I ever heard. Python is supposed to be easy to use,
don’t change it into Rust !
On Mon 1 Apr 2019 at 22:06, Jelle Zijlstra wrote:
>
>
> El lun., 1 abr. 2019 a las 7:28, Antoine Pietri (<
> antoine.piet...@gmail.com>) escribió:
>
>> While
Sure! Same examples mentioned in Victor's
https://vstinner.github.io/tag/security.html could have been fixed by
having a more proper parser. This one that I helped author was also a
parsing issue.
https://python-security.readthedocs.io/vuln/bpo-30500_urllib_connects_to_a_wrong_host.html
Thanks
El lun., 1 abr. 2019 a las 7:28, Antoine Pietri ()
escribió:
> While the switch to Python 3 did an excellent job in removing some of
> the old inconsistencies we had in the language, pretty much everyone
> agrees that some other backwards-incompatible changes could be made to
> remove some old
On Sun, Mar 31, 2019 at 9:17 PM Nam Nguyen wrote:
> Installing a package out of stdlib does not solve the problem that motivated
> this thread. The libraries included in the stdlib can't use those parsers.
Can you be more specific about exactly which code in the stdlib you
think should be
On 2019-04-01 19:33, Paul Moore wrote:
On Mon, 1 Apr 2019 at 16:36, Anders Hovmöller wrote:
Please let's all agree that April 1 is the worst day of the year.
Maybe in Python 4, datetime.datetime should silently convert 1st April
to the 2nd? :-P
Converting silently is not Pythonic. It
I just wanted to warn people that I don't know if any of the authors of PEP
582 subscribe to python-ideas and they have not brought it forward for
discussion yet, so there's no guarantee of a response.
On Mon, Apr 1, 2019 at 5:27 AM Calvin Spealman wrote:
> While the PEP does show the version
On Mon, 1 Apr 2019 at 16:36, Anders Hovmöller wrote:
>
> Please let's all agree that April 1 is the worst day of the year.
Maybe in Python 4, datetime.datetime should silently convert 1st April
to the 2nd? :-P
Paul
___
Python-ideas mailing list
Please let's all agree that April 1 is the worst day of the year.
> On 1 Apr 2019, at 16:27, Antoine Pietri wrote:
>
> While the switch to Python 3 did an excellent job in removing some of
> the old inconsistencies we had in the language, pretty much everyone
> agrees that some other
On Mon, 1 Apr 2019 at 15:59, Todd wrote:
> Currently there is no empty set literal. This is a hold-over from when there
> were no sets. Now would be a good opportunity to add one. I suggest {}
> become an empty set and {:} be an empty dict.
There should be no need for two styles - now that
On Mon, Apr 1, 2019, 10:28 Antoine Pietri
wrote:
> While the switch to Python 3 did an excellent job in removing some of
> the old inconsistencies we had in the language, pretty much everyone
> agrees that some other backwards-incompatible changes could be made to
> remove some old warts and
On Mon, Apr 1, 2019 at 7:50 AM Antoine Pitrou wrote:
>
> And 01 / 04 / 2019 should return a April 1st datetime.
>
> (except in the US, of course)
>
Where it would of course be I / / MMXV, unless you have ISO-8601
set in which case it would be MMXV - - I
On Mon, 1 Apr 2019 10:41:40 -0400
Dan Sommers
<2qdxy4rzwzuui...@potatochowder.com>
wrote:
> On 4/1/19 10:27 AM, Antoine Pietri wrote:
>
> > - The / operator returns floats, which loses information when both of
> > the operands are integer. In Python 4, “1 / 2” should return a
> > decimal.Decimal.
On 4/1/19 10:27 AM, Antoine Pietri wrote:
- The / operator returns floats, which loses information when both of
the operands are integer. In Python 4, “1 / 2” should return a
decimal.Decimal. To ease the transition, we propose to add a new “from
__future__ import decimal_division” in Python 3.9
David Mertz writes:
> OK, I'll acknowledge my comment might have overstated the bar to overcome.
> A parser added to the standard library doesn't need to be perfect for
> everyone. But adding to stdlib *does* provide a kind of endorsement of the
> right default way to go about things.
While the PEP does show the version number as part of the path to the
actual packages, implying support for multiple versions, this doesn't seem
to be spelled out in the actual text. Presumably __pypackages__/3.8/ might
sit beside __pypackages__/3.9/, etc. to keep future versions capable of
On Mon, 1 Apr 2019 at 01:01, Steven D'Aprano wrote:
>
> On Mon, Apr 01, 2019 at 12:02:25PM +1300, Greg Ewing wrote:
> > Dan Sommers wrote:
> >
> > >without_prefix
> > >without_suffix
> > >
> > >They're a little longer, but IMO "without" helps
> > >reenforce the immutability of the underlying
David Mertz writes:
> While I can imagine proposing one for inclusion in the standard
> library, you'd have to choose one (or write a new one) and explain
> why that one is better for everyone (or at least a better starting
> point) than all the others are.
In principle, no, one just needs
On 3/31/19 1:48 AM, Chris Angelico wrote:
> > * strip_prefix/strip_suffix
I don't like "strip" because .strip already has a different meaning,
although the inclusion of prefix/suffix makes the intended sematics
clear enough for the new methods. I wonder if it might make the
semantics of .strip
32 matches
Mail list logo
