Every Python program that I have ever written implicitly relies on the current
behavior of list. Changing the builtin list type would be such a massive
breaking change that it simply is not going to happen. As others have noted,
writing your own list subclass would solve your problem here.
I
On 11/20/2020 11:53 PM, Chris Angelico wrote:
> [snip]
> Use the simpler options until you can't use them. Then use the more
> complicated options.
Yea, use the simpler options. This is why I have switched from Python to C#
when writing desktop apps, simply because distributing a single exe file
On 9/17/2020 6:56 PM, Chris Angelico wrote:
> On Fri, Sep 18, 2020 at 8:54 AM Ben Rudiak-Gould wrote:
>> This is a terrible idea.
>>
>> No one should ever be trying to extract data from strings that are obviously
>> meant for human consumption, like "It is 11:45 PM".
>>
>> I'll grant you that it'
On 9/12/2020 12:05 PM, Greg Ewing wrote:
> On 12/09/20 8:36 pm, Serhiy Storchaka wrote:
>> it is not hard to write your
>> own helper with interface and defaults that suit you. It will take less
>> time than writing a letter in a mailing list.
>
> Obviously what's needed is an IDE feature such th
What about code that depends on __file__ to add installation dependent import
paths to sys.path? I have written code like that myself, and I've seen it
elsewhere too.
--Edwin
On 8/20/2020 9:06 PM, Christopher Barker wrote:
> I really like pathlib.
>
> But for a while is was painful to use, 'ca
On 8/7/2020 10:47 PM, Ricky Teachey wrote:
> On Fri, Aug 7, 2020 at 9:25 PM Edwin Zimmerman <mailto:ed...@211mainstreet.net>> wrote:
>
> On 8/7/2020 8:28 PM, Greg Ewing wrote:
> > I don't think anyone has the appetite for a Python 4 any
> > time
On 8/7/2020 8:28 PM, Greg Ewing wrote:
> I don't think anyone has the appetite for a Python 4 any
> time soon.
>
I'm included in "anyone" here. From reading this list, it seems to me that
"Python 4" is invoked as some folks favorite magical justification for
proposing major breaking changes. P
Random832 [mailto:random...@fastmail.com] wrote:
> On Tue, Jul 14, 2020, at 21:24, Chris Angelico wrote:
> > I actively oppose it because it isn't possible. Anything that is safe
> > will not have all of pickle's functionality. A nerfed version of
> > pickle that can only unpickle a tiny handful of
() and pyarrow.deserialize())
On Mon, Jul 13, 2020, 7:57 AM Chris Angelico mailto:ros...@gmail.com> > wrote:
On Mon, Jul 13, 2020 at 8:58 PM Edwin Zimmerman mailto:ed...@211mainstreet.net> > wrote:
>
> On 7/11/2020 11:17 PM, Greg Ewing wrote:
>
> On 12/07/20 1:01 pm, Edw
On 7/11/2020 11:17 PM, Greg Ewing wrote:
> On 12/07/20 1:01 pm, Edwin Zimmerman wrote:
>> As I see it, the unsafe callables (eval, exec, os.system, etc) are generally
>> functions, and safe ones(int, list, dict) are generally classes, though
>> there certainly would be
As I see it, the unsafe callables (eval, exec, os.system, etc) are generally
functions, and safe ones(int, list, dict) are generally classes, though there
certainly would be exceptions.
Would it be too great of a breaking change to block function callables by
default? That might be an increment
The bottom line is that pickle should never be used in a security sensitive
context. Several years ago I spent about 5 minutes writing a custom pickle
fuzzer. It ran for about 60 seconds before segfaulting. Fortunately, the last
time I ran my fuzzer (about a year ago), all I could produce was
On 6/28/2020 4:10 PM, Giampaolo Rodola' wrote:
> From:
> https://github.com/python/peps/commit/0c6427dcec1e98ca0bd46a876a7219ee4a9347f4
>
> > Instead of requiring that comments be written in Strunk & White Standard
> > English, require instead that English-language comments be clear and easily
>
This is still true. There are some of us that will scream very very loud if
the std lib disappears from Python installers. However, I think there could
easily be a way to satisfy both parties here. How difficult would it be to
release both full and minimal installers for every release? That
On 6/9/2020 9:21 PM, Jonathan Goble wrote:
> On Tue, Jun 9, 2020, 8:47 PM Edwin Zimmerman <mailto:ed...@211mainstreet.net>> wrote:
>
> Wouldn't this break backwards compatibility with everything the whole way
> back to 3.0? I fear a future with where I have
Wouldn't this break backwards compatibility with everything the whole way back
to 3.0? I fear a future with where I have to run a 2to3 type tool on
third-party dependencies just to get them to work with my 3.7 code base.
--Edwin
On 6/9/2020 8:06 PM, Guido van Rossum wrote:
> In Python 3.10 we
On 5/25/2020 8:29 AM, redrad...@gmail.com wrote:
> Edwin Zimmerman wrote:
>> On Monday, May 25, 2020 redrad...@gmail.com [mailto:redrad...@gmail.com]
>> wrote
>>> Edwin Zimmerman wrote:
>>> On 5/25/2020 5:56 AM, redrad...@gmail.com
>>> wrote:
>>>
On Monday, May 25, 2020 redrad...@gmail.com [mailto:redrad...@gmail.com] wrote
> Edwin Zimmerman wrote:
> > On 5/25/2020 5:56 AM, redrad...@gmail.com wrote:
> > > Edwin Zimmerman wrote:
> > Sub-interpreters are a work in progress. The API is not anywhere near
>
On 5/25/2020 5:56 AM, redrad...@gmail.com wrote:
>>> Edwin Zimmerman wrote:
> Only if your workload is CPU bound. Python optimizes IO bound workload
> performance by
> releasing the GIL while doing IO. Green threads generally do not offer this
> option.
>
> Real thre
On 5/23/2020 6:24 PM, redrad...@gmail.com wrote:
> Hi all,
>
> I am very exciting about the sub-interpreters ... but I do not like some
> parts ...
> Consider the following code:
> ```python
> import _xxsubinterpreters as interpreters
> import threading
> import textwrap as tw
> import marshal
>
>
On 5/23/2020 8:52 AM, Stephen J. Turnbull wrote:
> Executive summary:
>
> I'd like to make three points.
>
> 1. Accessibility matters, and I think this change would be
> inaccessible to users of screen readers.
> 2. Yes, a variety of tools imposes a burden, but also confers
> benefits.
>
On 5/21/2020 5:51 PM, Thierry Parmentelat wrote:
>>
>>
>> Python-arrow.png
>
> that’s nice ! it’s a real shame though, and a bit of a waste honestly, that
> everybody needs to cook their own brew of an editor to get there
> and primarily all I’m trying to say is that, one day, this will be a legal
On Thursday, May 21, 2020 1:14 PM MRAB [mailto:pyt...@mrabarnett.plus.com] wrote
> On 2020-05-21 16:48, Serhiy Storchaka wrote:
> > 21.05.20 16:45, Alex Hall пише:
> >> ≥ instead of >= might be an improvement because that's a
> >> symbol learned in school, but ultimately the student still needs to
On Thursday, May 21, 2020 9:20 AM Joao S. O. Bueno
[mailto:jsbu...@python.org.br] wrote
> On Thu, 21 May 2020 at 10:06, Thierry Parmentelat
> wrote:
> >
> >
> >
> > > On 21 May 2020, at 14:48, Joao S. O. Bueno wrote:
> > >
> > > (I had a coleague once which did
> > > set a special VIM config to
On April 28, 2020 9:38 AM Soni L. wrote:
> On 2020-04-28 7:50 a.m., Edwin Zimmerman wrote:
> > On 4/27/2020 11:47 PM, Soni L. wrote:
> > [snip]
> > > tbh my particular case doesn't make a ton of practical sense. I have
> > > config files and there may be
On 4/27/2020 11:47 PM, Soni L. wrote:
[snip]
> tbh my particular case doesn't make a ton of practical sense. I have config
> files and there may be errors opening or deserializing them, and I have a
> system to manage configs and overrides. which means you can have multiple
> config files, and y
I doubt that you will find many people on this list who are willing to do your
homework for you. It will be very hard to convince most of the people on this
list if the only reason you can give is "I think this would look great". Great
ideas are based on real needs, not on flights of fancy.
O
27 matches
Mail list logo
