date:20200331

Hello,

On Tue, 31 Mar 2020 16:28:22 +1100
Steven D'Aprano  wrote:

> On Mon, Mar 30, 2020 at 10:08:06PM -0700, Guido van Rossum wrote:
> > On Mon, Mar 30, 2020 at 10:00 PM Steven D'Aprano
> >  wrote:
> >   
> > > > it’s optimized for a different use case than string building,  
> > >
> > > It is? That's odd. The whole purpose of StringIO is to build
> > > strings.  
> 
> I misspoke: it is not the *whole* purpose. See below.

Steven, I appreciate keeping up discussion from the same angle as I see
it. (I read the thread in chronological order, and see that I could
save on some replies, just +1's your.)

For the last sentence above, I could offer an explanation "from the
other side". Just imagine that we took io.StringIO and:

1. Limit its constructor to StringIO(). (No parameters, no universal
newlines!)
2. Leave only the methods .write(), .getvalue(), and remove all other
methods.

Now, the *whole* purpose of such a class would be string building, it
literally can't do anything else.

Suppose we now indeed split off such a class, and named it
StringBuilder. We'd now have an bit of issue explaining why all that
was done. "StringBuffer implements subset of the functionality of
StringIO". D'oh. 

Looking on the implementation side, this StringBuffer class would also
have the machinery already present in StringIO, like backing store for
accumulated content, size/offset into this backing store. Yes, perhaps
it could have code a bit more specialized for just writing and no
reading, but is it worth code duplication?

So, the core of the criticism seems to be that StringIO was designed for
"another purpose" and that it "does much more". It's a bit strange
argumentation that a more generic/featureful object can't (just
can't) be used for subset of its functionality, you should be always
concerned that it can do much more. It's a bit strange logic, akin to
"lists are intended to store arbitrary objects, so if you store
integers in them, you're doing something wrong".

Let's get to our StringBuffer class as constructed above. Now that it
doesn't have "IO" at the end, we perhaps can give up and add __iadd__
method to it, having the same semantics as .write(), but returning
self (thanks for correction!). But if we can do that, then with
the arguments above re: entity and code duplication, perhaps we can do
that on the original StringIO. About the only thing that can preclude
that is an irrational belief that given that originally it was intended
for more general usecase, then we can't, just can't, nudge to make it
more comfortable for a subset of its usage.

-- 
Best regards,
 Paul  mailto:pmis...@gmail.com
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/74KZDMS5U2Z6RSB5GZXWZ6WSAEAIRZ45/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Compound with .. else statement

On Mar 31, 2020, at 03:06, Jimmy Thrasibule  wrote:
> 
> 
>> 
>> But if you use a context manager which silences the exception, like
>> contextlib.suppress() or unittest.TestCase.assertRaises(), it is easy to
>> do too.
>> 
>> was_not_raised = False
>> with my_context():
>>   do_something_sensitive()
>>   was_not_raised = True
>> if was_not_raised:
>> print("We're all safe.")
> 
> That is indeed a way to workaround my use case. I do still find a
> with/else more elegant.

It might help your proposal to just show a small concrete and realistic example 
of how this workaround parallels the workaround for not having for/else, and 
how your proposed change would let you improve your code’s readability in 
exactly the same way as for/else. At least for me, it’s always been easier to 
show a newcomer to Python the point of for/else with a nice example than to try 
to explain the semantics and why they’re useful, and I assume the same would be 
true here.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/C5ATRBHHKOIOFIWET2J7ONGOJGK7VGBA/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Explicitly defining a string buffer object (aka StringIO += operator)

On Mar 31, 2020, at 12:06, Paul Sokolovsky  wrote:

I don’t know why you think being snarky helps make your case. If you make a 
mistake and it’s pointed out and you give a sarcastically over-enthusiastic 
thanks, that doesn’t change the fact that it‘s wrong, and if your rationale 
depends on things that aren’t true, your proposal doesn’t stand.

For example, your demonstration that str.join takes 10x the memory of StringIO 
in CPython is wrong because you didn’t actually include the cost of the list of 
buffers inside the StringIO, and once you do, StringIO is actually larger 
rather than 1/10th the size. It doesn’t matter how much you try to belittle 
that point or the way it was made by exaggeratedly apologizing, it’s still true 
that changing everyone’s code to do things your way instead of the way they’ve 
always done things would increase, not decrease, their memory usage, not just 
in theoretical possible implementations of Python but in multiple real life 
implementations, including CPython.

___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/PFFAM7PZ7R7X2YBMF3GA3T5QPN3ENR6E/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Explicitly defining a string buffer object (aka StringIO += operator)

Hello,

On Mon, 30 Mar 2020 23:20:28 -0400
David Mertz  wrote:

> I have myself been "guilty" of using the problem style for N < 10.  In
> fact, I had forgotten about the optimization even, since my uses are
> negligible time.

I personally don't think it's a "problem style" per se. I'm using it all
the time. I'm going to keep using it. We all love Python for being a
language which you can easily prototype in, and don't have to
concern yourself with implementation details unless you want. My
concern for Python to be a language which can be progressively and
easily optimized when you need it.

Going over the code and changing many lines along the lines of diff:

- buf += piece
+ buf.append(piece)

isn't my idea of "seamless" optimization, especially that I know
it guaranteedly will grow my memory usage.

Sadly I came to conclusion that even

- buf += piece
+ buf.write(piece)

patching hurts my aesthetic feelings. At least, that's the only
explanation I have for why in one of my modules
https://github.com/pfalcon/pycopy-lib/blob/master/utokenize/utokenize.py#L44
I converted one loop from "str +=" to "StringIO.write()", but not
another. I then tried to think what could help with that and having +=
on StringIO seemed to do the trick.

> 
> For stuff like this, it's fast no matter what:
> 
> for clause in query_clauses:
> sql += clause
> 
> Maybe I have a WHERE or two.  Maybe an ORDER BY.  Etc.  But if I'm
> sure there won't be more than 6 such clauses to the query I'm
> building, so what? Or probably likewise with bits of a file path, or
> a URL with optional parameters, and a few other things.
> 
> On Mon, Mar 30, 2020 at 11:15 PM David Mertz  wrote:
> 
> > Does anyone know if any linters find and warn about the `string +=
> > word` in a loop pattern? It feels like a linter would be the place
> > to do that.  I don't think we could possibly make it an actual
> > interpreter warning given borderline OK uses (or possibly even
> > preferred ones).  But a little nagging in tooling could draw
> > attention.

[]

-- 
Best regards,
 Paul  mailto:pmis...@gmail.com
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/JTWGFXK3KTTTRLXW25OKE7SH37A47AGV/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: PEP 9999: Retire animal-unfriendly language

On Mar 31, 2020, at 12:03, Oleg Broytman  wrote:
> 
> Animals can fight or run, but plants cannot. So we must protect
> plants more, not less!

That’s just what the plants want you to believe. Have you ever seen how trees 
get on when there are no humans about? No, of course you haven’t, because it’s 
impossible. If a tree falls in the forest and nobody’s around to hear it, it’s 
probably breaking into your house. Trust me, your average tree (not a larch, of 
course, but they’re hardly average) can outrun a hedgehog without breaking a 
sweat. We need to treat each plant individually, not overgeneralize them as a 
group. Sure, a young, innocent oak sapling deserves our protection, but some of 
those redwoods, well, they didn’t get to be 4700 years old by being helpless. 
Get cornered by one of them in a dark alley in Mammoth and you’ll be wishing it 
was a bunch of redcurrants or a tiger you were dealing with. Which is why we 
should all hunt and eat redwood trees rather than cows or bananas. And don’t 
even get me started on sunflowers.

___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/SCVCAXII4Z4U53XBBQBMCCHDVQRHS35O/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: PEP 9999: Retire animal-unfriendly language

On Mar 31, 2020, at 10:54, Evpok Padding  wrote:
> 
> 
> Even if you think this is clever or funny, are you absolutely sure you needed 
> to share it with the subscribers to this mailing list?

Now, I’ve noticed a tendency for this thread to get rather silly. Now I do my 
best to keep things moving along, but I’m not having things getting silly. 
Those last two replies got very silly indeed. And the one about the animal 
cruelty was even sillier. Now, nobody likes a good laugh more than I do. Except 
perhaps my wife and some of her friends. Oh, yes, and Captain Johnson. Come to 
think of it, most people like a good laugh more than I do, but that’s beside 
the point. Now, let’s have a good, clean, healthy April Fools’ PEP thread. Get 
some air into your lungs. 9, 9, 9, 9 and all that. Ah yes, that’s better. Now 
let’s hope this doesn’t get silly.

___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/AYF2T7HKXIICVGQH7IDW3ROSOPNLLGXY/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Explicitly defining a string buffer object (aka StringIO += operator)

2020-03-31 Thread jdveiga

Paul Sokolovsky wrote:
> Hello,
> On Mon, 30 Mar 2020 16:25:07 -0700
> Christopher Barker python...@gmail.com wrote:
> > As others have pointed out, the OP started in a  bit
> > of an oblique
> > way, but it maybe come down to this:
> > There are some use-cases for a mutable string type.
> > For avoidance of doubt: nothing in my RFC has anything to do, or
> implies, "a mutable string type". A well-know pattern of string
> builder, yes. Piggybacking on existing StringIO/BytesIO classes, yes.
> Anything else, no.
> To not leave it cut and dry: IMHO, we need more const'ness in Python,
> not less. I my dreams I already do stuff like:
> from __future__ import const
> class Foo:
> pass
> # This is an alias for "Foo"
> Bar: const = Foo
> # This is a variable which can store a reference to Foo or any other class
> Baz = Foo
> [This is not a new RFC! Please start a new thread if you'd like to pick
> it up ;-)]

If I understand you are proposing a change from StringIO `write` method to `+=` 
operator. Is it right?

I cannot see any advantage on this proposal since there is no real change in 
the implementation of StringIO. Or are you proposing any change in the 
underlying implementation and I have missed that point?

In this case, I disagree with you: StringIO is a stream and I think that it is 
wrong to make it to "look & feel" like a string. That is my opinion.

Sorry if I misunderstand you.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/PHGIESG7VEBZZQGI2IZW7DHWH4MJWLOF/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: PEP 9999: Retire animal-unfriendly language

2020-03-31 Thread Mark Dickinson

>
>
> Proposed alternatives
> =
>
> Keeping with the good practice of referencing sketches from Monty
> Python's
> Flying Circus, this PEP proposes to adopt the fruits mentioned in the
> `"Self-Defence Against Fresh Fruit" sketch`_:
>
> * raspberry (not currently in use)
> * banana  (68 times in standard library)

[...]


Sorry, I'm afraid that "banana" is not an acceptable alternative here. It's
well known that botanically, bananas are a type of fish. Please see the
study at https://www.goodreads.com/quotes/6870748 for more information on
this.

-- 
Mark
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/ROQI5Z3DP3KRYNC456RAZGCUWSDAU7LO/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: returning a namedtuple on dict.items()

2020-03-31 Thread Nadav Wexler

that's what I assumed...
thanks for the reply! :)

On Tue, Mar 31, 2020 at 9:08 PM Serhiy Storchaka 
wrote:

> 31.03.20 20:15, Nadav Wexler пише:
> > Hi,
> > That is my first post here, I hope it's the right place for it.
> >
> > so I was using some dicts had the following code:
> >  env = dict(t for t in os.environ.items() if 'SUBSTRING' not in
> > t[0])
> >
> > and I thought: It could have really been nice if i could do:
> >  env = dict(t for t in os.environ.items() if 'SUBSTRING' not in
> > t.key)
> >
> > now I see that environ is not exactly a dict, but i think this is useful
> > for all dictionary types. on the other hand, dicts are everywhere and
> > i'm not sure about the performance impact of this for those that just
> > ignore the access by attribute.
> >
> > of course, a matching t.value must be in place as well. ;)
> > I would have opened a PR just to try out, but I feel this is so in the
> > core that I'd first like to hear some comments.
> > I was searching if anyone else had this idea before but couldn't find
> > anything.
>
> This idea was proposed multiple times and was rejected. Python is
> optimized for raw tuples, it is one of most important type. Many
> operations with tuples are much faster than operations with named tuples
> (including creating and destroying). Tuples emitted by dict.item() (an
> enumerate(), and zip()) are usually short-living and produced in mass.
> So replacing tuples with named tuples would harm a lot of code which do
> not need attribute access.
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/VRVLQHMKFMVEC4T7VN5QEVSFGPEZWG7P/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/IPYV2L4H5N5CANRQZMCLK422SBPJU7PN/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Explicitly defining a string buffer object (aka StringIO += operator)

Hello,

On Mon, 30 Mar 2020 16:25:07 -0700
Christopher Barker  wrote:

> As others have pointed out, the OP started in a  bit of an oblique
> way, but it maybe come down to this:
> 
> There are some use-cases for a mutable string type.

For avoidance of doubt: nothing in my RFC has anything to do, or
implies, "a mutable string type". A well-know pattern of string
builder, yes. Piggybacking on existing StringIO/BytesIO classes, yes.
Anything else, no.

To not leave it cut and dry: IMHO, we need more const'ness in Python,
not less. I my dreams I already do stuff like:

from __future__ import const

class Foo:
pass

# This is an alias for "Foo"
Bar: const = Foo

# This is a variable which can store a reference to Foo or any other class
Baz = Foo

[This is not a new RFC! Please start a new thread if you'd like to pick
it up ;-)]

-- 
Best regards,
 Paul  mailto:pmis...@gmail.com
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/XS6FCMOYALLDJWQDZY33OZDAOM3LFJ47/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Explicitly defining a string buffer object (aka StringIO += operator)

Hello,

On Mon, 30 Mar 2020 13:59:42 -0700
Andrew Barnert  wrote:

> On Mar 30, 2020, at 13:06, Paul Sokolovsky  wrote:
> > 
> > I appreciate expressing it all concisely and clearly. Then let me
> > respond here instead of the very first '"".join() rules!' reply I
> > got.  
> 
> Ignoring replies doesn’t actually answer them.

I'm happy to discuss various points, but it would be nice to have
discussion focused, giving that the change proposed is pretty simple.
I'm not sure if it my fault by having tried to structure the original
RFC as a poor-man's PEP (so it's somewhat long'ish), but I definitely
would like to avoid discussing extended topics along the lines of
"there're some mundane languages which offer those string builder
classes, but Python is so, SO, special, that it doesn't need it, and
whoever thinks otherwise just doesn't get it" or "building a string
from pieces by putting pointers to pieces into array, and then
concatenating them together is the PEAK achievement of the computer
science, and whoever didn't get that just... just... didn't read
CPython (yes, CPython!) FAQ".

> > The issue with "".join() is very obvious:
> > 
> > --
> > import io
> > import sys
> > 
> > 
> > def strio():
> >sb = io.StringIO()
> >for i in range(5):
> >sb.write(u"==%d==" % i)
> >print(sys.getsizeof(sb) + sys.getsizeof(sb.getvalue()))  
> 
> This doesn’t tell you anything useful. As the help for getsizeof
> makes clear, “Only the memory consumption directly attributed to the
> object is accounted for, not the memory consumption of objects it
> refers to”. So this gives you some fixed value like 152, no matter
> how big the buffer and other internal objects may be.

Yeah, I tried to account for that with "sys.getsizeof(sb) +
sys.getsizeof(sb.getvalue())", thanks for noticing that.

> If you’re using CPython with the C accelerator, none of those things
> are available to you from the API, but a quick scan of the C source
> shows what’s there, and it’s generally actually more storage than the
> list version. Oversimplifying a bit: While you’re building, it keeps
> a _PyAccu structure, which is basically a wrapper around that same
> list of strings. When you call getvalue() it then builds a Py_UCS4*
> representation that’s in this case 4x the size of the final string
> (since your string is pure ASCII and will be stored in UCS1, not
> UCS4). And then there’s the final string.

Thanks very much for this intro into the CPython
io.StringIO implementation, much appreciated. Please let me return the
favor and explain how StringIO implemented in Pycopy, which I happen to
maintain, and in MicroPython (as the original implementation was written
by me there). So, there's an array of bytes. Both implementations use
utf-8 to store strings. So, StringIO stores as many bytes as there're
actual data in (utf-8) strings. Of course, there's some over-allocation
policy to avoid severe quadratic behavior on growing. Overall, storing N
bytes of string data requires N + small % of N bytes of data. No
additional array of pointers is needed. Original constituent strings
(each over-allocated of course) can be GCed in the meantime.

The moral is known, and was stated in the original RFC: for as
long as somebody's attention is fixated on CPython, the likely
reply from them would be: "there's no problem with CPython3, so there's
nothing to fix". It takes to step up, think about *multiple*
implementations and *interface* they *can* offer.

> So, if this memory issue makes join unacceptable, it makes your
> optimization even more unacceptable.
> 
> And thinking about portable code makes it even worse. Your code might
> be run under CPython and take even more memory, or it might be run
> under a different Python implementation where StringIO is not
> accelerated (where it’s just a TextIOWrapper around a BytesIO) and
> therefore be a whole lot slower instead. So it has to be able to deal
> with both of those possibilities, not just one; code that uses the
> usual idiom, on the other hand, behaves pretty similarly on all
> implementations.

Indeed, it absolutely and guaranteedly wastes a lot of memory. (It's
also the fastest, no worries.) 

> > There's absolutely no need why performing trivial operation of
> > accumulating string content should take about order of magnitude
> > more memory than actually needed for that string content. Don't get
> > me wrong
> > - if you want to spend that much of your memory, then sure, you
> > can. But jumping with that as *the only right solution* whenever
> > somebody mentions "string concatenation" is a bit ... umm,
> > cavalier  
> 
> And making a wild guess about how things might be implemented and
> offering an optimization based on that guess that actually makes
> things worse and refusing to even reply when people point out the
> problems isn’t even more cavalier?

The point I tried to show is that StringIO is never worse than str +=
regarding performance (stats for 8

[Python-ideas] Re: PEP 9999: Retire animal-unfriendly language

2020-03-31 Thread Oleg Broytman

On Tue, Mar 31, 2020 at 09:08:50PM +0300, Serhiy Storchaka 
 wrote:
> 31.03.20 20:52, Antoine Pitrou пише:
> > Your search is incomplete, for example you failed to account for
> > occurrences of "cheese" and "milkshake".
> 
> I thought palm trees are plants.

   Animals can fight or run, but plants cannot. So we must protect
plants more, not less!

Oleg.
-- 
Oleg Broytmanhttps://phdru.name/p...@phdru.name
   Programmers don't die, they just GOSUB without RETURN.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/PAKIUCXE5233ZRCE7UZL3AULNX2IJRNL/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: PEP 9999: Retire animal-unfriendly language

2020-03-31 Thread Dan Sommers

On Tue, 31 Mar 2020 19:17:18 +0200
Gerrit Holl  wrote:

> Abstract
> 

> Python has long used metasyntactic variables that are based on the
> consumption of meat and dairy products, such as "spam", "ham", and
> "eggs".

> This language is not considerate to pigs or chicken and violates the
> spirit of the Code of Conduct.  This PEP proposes to retire the use
> of those names in official Python documentation and source code and
> to recommend users of Python to do the same.

Dear Sir,

I wish to complain in the strongest possible terms about the PEP which
has just been posted about the unseemly treatment of farm animals.

My farm raised pythons are never confined to a cage, and I assure you
that all mistreatment is deliberately unsystematic.

Brigadier Sir Daniel Sommers, retired, Mrs.

>Local Variables:
>mode: indented-text
>indent-tabs-mode: nil
>sentence-end-double-space: t
>fill-column: 70
>coding: utf-8
>End:

Oh, dear Lord, no, please don't start another emacs/vi war, let alone
a lengthy line length debate.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/D4YT6BBCUUXLMAKDXLCDYSDT3SHZTQ7F/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: PEP 9999: Retire animal-unfriendly language

2020-03-31 Thread Ricky Teachey

Just in case this was not proposed in jest:

How about just adding a note stipulating that if found offensive, all
references to animal derived products are encouraged to be interpreted as
their real or hypothetical plant-based alternatives, some of which exist
today (plant based "ham", "chicken") and others that will presumably also
exist in the future (unless I'm wrong, plant based eggs)?

On Tue, Mar 31, 2020, 2:13 PM Serhiy Storchaka  wrote:

> 31.03.20 20:52, Antoine Pitrou пише:
> > Your search is incomplete, for example you failed to account for
> > occurrences of "cheese" and "milkshake".
>
> I thought palm trees are plants.
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/FNBM2HSIH4KHSCSV2CB7MW6NBDTWUDZJ/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/R7IY36E3RSVWLSHWFCE5DPATOQIG7EFL/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: PEP 9999: Retire animal-unfriendly language

2020-03-31 Thread Chris Angelico

On Wed, Apr 1, 2020 at 4:19 AM Gerrit Holl  wrote:
> Abstract
> 
>
> Python has long used metasyntactic variables that are based on the
> consumption of meat and dairy products, such as "spam", "ham", and
> "eggs".
> This language is not considerate to pigs or chicken and violates the
> spirit of the Code of Conduct.  This PEP proposes to retire the use
> of those names in official Python documentation and source code and to
> recommend users of Python to do the same.
>

While I wholeheartedly agree with your intention here, I believe the
backward incompatibilities would make this untenable. We will need a
migration plan. Unfortunately, African swallows are non-migratory,
severely impacting your proposal.

ChrisA
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/FRNE2HZWLBSONIHYHK2Z3OVXCRT4MMY7/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Issue 34850: Syntax Warning in the real world (is 0 / is 1)

2020-03-31 Thread M.-A. Lemburg

On 3/31/2020 7:58 PM, Serhiy Storchaka wrote:
> 31.03.20 20:21, Andrew Barnert via Python-ideas пише:
>> Do you have code that you think actually _should_ be using is 1? Or
>> code that you have to compile over and over (e.g., your deployment
>> server doesn’t cache .pyc files, or you spawn new instances all the
>> time without pre-built .pycs, or your app generates and compiles code
>> on the fly, or …) and can’t change? If there are legitimate cases like
>> those, I think that could definitely be a compelling argument against
>> using SyntaxWarning here. But “the warning fired as intended and
>> showed me a bug in my code” isn’t. And without more context, it’s hard
>> to know which is the case here. So can you explain why this is a
>> problem for you?
> 
> Twice in the last month I have been creating a PR for CPython which
> contains "is 1". I knew what I do.
> 
> One of them was in C. I needed very fast and simple test for integers 0
> and 1, so I used the C equivalent of the "is" operator (compared
> pointers) with objects representing Python integers 0 and 1. And more, I
> used private CPython singletons _PyLong_Zero and _PyLong_One. There is
> no guarantee that all integer 0 an 1 are represented as these singletons
> (even in CPython), but it was only for optimization. In worst case I
> would lose an optimization but still got a correct result.
> 
> In second PR, I needed to determine if the optional argument with
> default value 1 was passed, and use fast path if it was not passed. "==
> 1" did not work, because 1.0 was error. It was first time when I
> encountered a SyntaxWarning I added myself. The workaround was simple:
> add a global `_ONE = 1` and use it as a default value and with the "is"
> operator. It would work even if 1 was not interned. In any way, this PR
> was rejected.
> 
> Conclusion? If you know what do you do you can find a workaround. But if
> you use this because you do not know difference between "is" and "=="
> and it works for you now, the warning can save you from possible bugs
> and teach you something.

I think that's good reasoning. "is " will almost always be
a typo or misunderstanding of what "is" actually does.

"is" should really only be used to determine whether some variable
is pointing to a specific object. Using singletons for e.g. default
values is a case where such a test can be put to good use  - just beware
of certain optimizations in CPython, e.g. the interning of small
integers and (some) single character strings.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Experts (#1, Mar 22 2020)
>>> Python Projects, Coaching and Support ...https://www.egenix.com/
>>> Python Product Development ...https://consulting.egenix.com/

::: We implement business ideas - efficiently in both time and costs :::

   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
   Registered at Amtsgericht Duesseldorf: HRB 46611
   https://www.egenix.com/company/contact/
 https://www.malemburg.com/
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/QCDJLPRW5WQDKYFNEQRD5IXPBEXCM4KU/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: PEP 9999: Retire animal-unfriendly language


31.03.20 20:52, Antoine Pitrou пише:

Your search is incomplete, for example you failed to account for
occurrences of "cheese" and "milkshake".


I thought palm trees are plants.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/FNBM2HSIH4KHSCSV2CB7MW6NBDTWUDZJ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: returning a namedtuple on dict.items()

31.03.20 20:15, Nadav Wexler пише:

Hi,
That is my first post here, I hope it's the right place for it.

so I was using some dicts had the following code:
env = dict(t for t in os.environ.items() if 'SUBSTRING' not in
t[0])

and I thought: It could have really been nice if i could do:
env = dict(t for t in os.environ.items() if 'SUBSTRING' not in
t.key)

now I see that environ is not exactly a dict, but i think this is useful
for all dictionary types. on the other hand, dicts are everywhere and
i'm not sure about the performance impact of this for those that just
ignore the access by attribute.

of course, a matching t.value must be in place as well. ;)
I would have opened a PR just to try out, but I feel this is so in the
core that I'd first like to hear some comments.
I was searching if anyone else had this idea before but couldn't find
anything.

This idea was proposed multiple times and was rejected. Python is
optimized for raw tuples, it is one of most important type. Many
operations with tuples are much faster than operations with named tuples
(including creating and destroying). Tuples emitted by dict.item() (an
enumerate(), and zip()) are usually short-living and produced in mass.
So replacing tuples with named tuples would harm a lot of code which do
not need attribute access.

___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/VRVLQHMKFMVEC4T7VN5QEVSFGPEZWG7P/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Issue 34850: Syntax Warning in the real world (is 0 / is 1)

31.03.20 20:21, Andrew Barnert via Python-ideas пише:

Do you have code that you think actually _should_ be using is 1? Or code that
you have to compile over and over (e.g., your deployment server doesn’t cache
.pyc files, or you spawn new instances all the time without pre-built .pycs, or
your app generates and compiles code on the fly, or …) and can’t change? If
there are legitimate cases like those, I think that could definitely be a
compelling argument against using SyntaxWarning here. But “the warning fired as
intended and showed me a bug in my code” isn’t. And without more context, it’s
hard to know which is the case here. So can you explain why this is a problem
for you?

Twice in the last month I have been creating a PR for CPython which
contains "is 1". I knew what I do.

One of them was in C. I needed very fast and simple test for integers 0
and 1, so I used the C equivalent of the "is" operator (compared
pointers) with objects representing Python integers 0 and 1. And more, I
used private CPython singletons _PyLong_Zero and _PyLong_One. There is
no guarantee that all integer 0 an 1 are represented as these singletons
(even in CPython), but it was only for optimization. In worst case I
would lose an optimization but still got a correct result.

In second PR, I needed to determine if the optional argument with
default value 1 was passed, and use fast path if it was not passed. "==
1" did not work, because 1.0 was error. It was first time when I
encountered a SyntaxWarning I added myself. The workaround was simple:
add a global `_ONE = 1` and use it as a default value and with the "is"
operator. It would work even if 1 was not interned. In any way, this PR
was rejected.

Conclusion? If you know what do you do you can find a workaround. But if
you use this because you do not know difference between "is" and "=="
and it works for you now, the warning can save you from possible bugs
and teach you something.

___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/PCVDL5UGVB4FUTK2NCT7YJGRJAUBPK7C/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: PEP 9999: Retire animal-unfriendly language

2020-03-31 Thread Evpok Padding

Even if you think this is clever or funny, are you absolutely sure you
needed to share it with the subscribers to this mailing list?

On Tue, 31 Mar 2020 at 17:46, Andrew Barnert via Python-ideas <
python-ideas@python.org> wrote:

> Dear Sir, I wish to complain in the strongest possible terms about the PEP
> which you have just transmitted about the inconsiderateness of spam. Many
> of my best friends are horned Vikings, and only a few of them are animal
> torturers. Yours faithfully, Brigadier Sir Andrew Barnert, OBE, retired,
> Mrs.
>
> Sent from my iPhone
>
> > On Mar 31, 2020, at 10:21, Gerrit Holl  wrote:
> >
> > (needs a sponsor)
> >
> > latest version at
> > https://github.com/gerritholl/peps/blob/animal-friendly/pep-.rst
> >
> > PEP: 
> > Title: Retire animal-unfriendly language
> > Author: Gerrit Holl 
> > Discussions-To: python-ideas@python.org
> > Status: Draft
> > Type: Informational
> > Content-Type: text/x-rst
> > Created: 01-Apr-2020
> > Post-History: 01-Apr-2020
> > Sponsor:
> >
> >
> > Abstract
> > 
> >
> > Python has long used metasyntactic variables that are based on the
> > consumption of meat and dairy products, such as "spam", "ham", and
> > "eggs".
> > This language is not considerate to pigs or chicken and violates the
> > spirit of the Code of Conduct.  This PEP proposes to retire the use
> > of those names in official Python documentation and source code and to
> > recommend users of Python to do the same.
> >
> >
> > Motivation and Rationale
> > 
> >
> > Estimates for the number of animals slaughtered for meat every year
> > vary, but `worldindata`_ estimates around 80 billion individuals.
> > Farmed animals are often kept in small cages with little to no access
> > to daylight, suffer stress during life and slaughter, or are otherwise
> > systematically mistreated.
> >
> > The `Python Code of Conduct`_ describes that community members are
> > open, considerate, and respectful.  The Python standard library and
> > documentation contain numerous references to meat or dairy based food
> > products that are not respectful to our fellow inhabitants of planet
> > Earth.  Examples include "spam", "bacon", and "eggs".
> >
> > To align the language use in the standard library and documentation
> > with
> > the Code of Conduct, use of such language should be retired.
> >
> >
> > Current practice
> > 
> >
> > There is a widespread tradition in the Python standard library, the
> > documentation, and the wider community, to include references to Monty
> > Pythons Flying Circus.  The use of "spam", "bacon", "sausage", and
> > "eggs" can be traced back to the `"Spam" sketch`_ originally broadcast
> > by the British Broadcasting Corporation (BBC) on 8 September 1972.
> > In this sketch, a couple are trying to order food in a diner where all
> > items contain spam.  The woman does not like spam and wants to order
> > food without spam.  A group of horned vikings then sing about the
> > wonderful spam.
> >
> > To get an overview of the usage in the current standard library, the
> > command ``cat $(find . -name '*.py') | grep -oi term | wc -l`` was
> > used.
> > This showed 2615 occurences for spam, 593 for ham (this include some
> > false positives, among other reasons due to references to people whose
> > name innociously contains the substring ham), 517 for eggs, 57 for
> > bacon,
> > and 10 for sausage.  Searching ``*.rst`` in the documentation revealed
> > 391 occurrences for spam, 82 for ham, 96 for eggs, 28 for bacon, and
> > 10 for sausage.  The source code for cpython revealed just 2 usages
> > for
> > spam and 1 for eggs.
> >
> > Proposed alternatives
> > =
> >
> > Keeping with the good practice of referencing sketches from Monty
> > Python's
> > Flying Circus, this PEP proposes to adopt the fruits mentioned in the
> > `"Self-Defence Against Fresh Fruit" sketch`_:
> >
> > * raspberry (not currently in use)
> > * banana  (68 times in standard library)
> > * apricot (not currently in use)
> > * pineapple (8 times in standard library)
> > * peach (once in standard library)
> > * redcurrant (not currently in use)
> > * damson (not currently in use)
> > * prune (23 times in standard library)
> >
> > Other possible alternatives keeping with food items:
> >
> > * salad (occurs once in standard library)
> > * aubergine (referred to in the spam sketch)
> > * shallot (the same)
> > * tofu (vegan protein alternative)
> >
> >
> > Specification
> > =
> >
> > For the reasons mentioned in the rationale, all references to meat or
> > dairy
> > products shall be removed from the Python standard library, the
> > documentation,
> > and the cpython source code.  The wider Python community is
> > recommended to
> > follow this practice.  In core Python:
> >
> > * Programmers SHALL NOT use the metasyntactic variables "spam", "ham",
> > "bacon",
> >  or "sausage", neither as variable names, nor in example strings, nor
> >

[Python-ideas] Re: PEP 9999: Retire animal-unfriendly language

2020-03-31 Thread Antoine Pitrou



Your search is incomplete, for example you failed to account for
occurrences of "cheese" and "milkshake".

Regards

Antoine.


On Tue, 31 Mar 2020 19:17:18 +0200
Gerrit Holl  wrote:
> (needs a sponsor)
> 
> latest version at
> https://github.com/gerritholl/peps/blob/animal-friendly/pep-.rst
> 
> PEP: 
> Title: Retire animal-unfriendly language
> Author: Gerrit Holl 
> Discussions-To: python-ideas@python.org
> Status: Draft
> Type: Informational
> Content-Type: text/x-rst
> Created: 01-Apr-2020
> Post-History: 01-Apr-2020
> Sponsor:
> 
> 
> Abstract
> 
> 
> Python has long used metasyntactic variables that are based on the
> consumption of meat and dairy products, such as "spam", "ham", and
> "eggs".
> This language is not considerate to pigs or chicken and violates the
> spirit of the Code of Conduct.  This PEP proposes to retire the use
> of those names in official Python documentation and source code and to
> recommend users of Python to do the same.
> 
> 
> Motivation and Rationale
> 
> 
> Estimates for the number of animals slaughtered for meat every year
> vary, but `worldindata`_ estimates around 80 billion individuals.
> Farmed animals are often kept in small cages with little to no access
> to daylight, suffer stress during life and slaughter, or are otherwise
> systematically mistreated.
> 
> The `Python Code of Conduct`_ describes that community members are
> open, considerate, and respectful.  The Python standard library and
> documentation contain numerous references to meat or dairy based food
> products that are not respectful to our fellow inhabitants of planet
> Earth.  Examples include "spam", "bacon", and "eggs".
> 
> To align the language use in the standard library and documentation
> with
> the Code of Conduct, use of such language should be retired.
> 
> 
> Current practice
> 
> 
> There is a widespread tradition in the Python standard library, the
> documentation, and the wider community, to include references to Monty
> Pythons Flying Circus.  The use of "spam", "bacon", "sausage", and
> "eggs" can be traced back to the `"Spam" sketch`_ originally broadcast
> by the British Broadcasting Corporation (BBC) on 8 September 1972.
> In this sketch, a couple are trying to order food in a diner where all
> items contain spam.  The woman does not like spam and wants to order
> food without spam.  A group of horned vikings then sing about the
> wonderful spam.
> 
> To get an overview of the usage in the current standard library, the
> command ``cat $(find . -name '*.py') | grep -oi term | wc -l`` was
> used.
> This showed 2615 occurences for spam, 593 for ham (this include some
> false positives, among other reasons due to references to people whose
> name innociously contains the substring ham), 517 for eggs, 57 for
> bacon,
> and 10 for sausage.  Searching ``*.rst`` in the documentation revealed
> 391 occurrences for spam, 82 for ham, 96 for eggs, 28 for bacon, and
> 10 for sausage.  The source code for cpython revealed just 2 usages
> for
> spam and 1 for eggs.
> 
> Proposed alternatives
> =
> 
> Keeping with the good practice of referencing sketches from Monty
> Python's
> Flying Circus, this PEP proposes to adopt the fruits mentioned in the
> `"Self-Defence Against Fresh Fruit" sketch`_:
> 
> * raspberry (not currently in use)
> * banana  (68 times in standard library)
> * apricot (not currently in use)
> * pineapple (8 times in standard library)
> * peach (once in standard library)
> * redcurrant (not currently in use)
> * damson (not currently in use)
> * prune (23 times in standard library)
> 
> Other possible alternatives keeping with food items:
> 
> * salad (occurs once in standard library)
> * aubergine (referred to in the spam sketch)
> * shallot (the same)
> * tofu (vegan protein alternative)
> 
> 
> Specification
> =
> 
> For the reasons mentioned in the rationale, all references to meat or
> dairy
> products shall be removed from the Python standard library, the
> documentation,
> and the cpython source code.  The wider Python community is
> recommended to
> follow this practice.  In core Python:
> 
> * Programmers SHALL NOT use the metasyntactic variables "spam", "ham",
> "bacon",
>   or "sausage", neither as variable names, nor in example strings, nor
> in
>   documentation.
> * Programmers SHALL NOT use the metasyntactic variable "eggs" in
> context with
>   food items, but may still use it in context of other body parts.
> Prohibited:
>   ``["salad", "eggs"]``.  Allowed: ``["ovaries", "pouch", "eggs"]``.
> * Programmers SHALL NOT use any other metasyntactic variable that is
> unfriendly
>   to animals.
> 
> The wider Python community is encouraged to adopt these practices as
> well, but
> the continued use of animal-unfriendly metasyntactic variables will
> not be
> considered a violation of the code of conduct.
> 
> 
> Rejected ideas
> ==
> 
> The authors carefully

[Python-ideas] Re: PEP 9999: Retire animal-unfriendly language

Dear Sir, I wish to complain in the strongest possible terms about the PEP 
which you have just transmitted about the inconsiderateness of spam. Many of my 
best friends are horned Vikings, and only a few of them are animal torturers. 
Yours faithfully, Brigadier Sir Andrew Barnert, OBE, retired, Mrs.

Sent from my iPhone

> On Mar 31, 2020, at 10:21, Gerrit Holl  wrote:
> 
> (needs a sponsor)
> 
> latest version at
> https://github.com/gerritholl/peps/blob/animal-friendly/pep-.rst
> 
> PEP: 
> Title: Retire animal-unfriendly language
> Author: Gerrit Holl 
> Discussions-To: python-ideas@python.org
> Status: Draft
> Type: Informational
> Content-Type: text/x-rst
> Created: 01-Apr-2020
> Post-History: 01-Apr-2020
> Sponsor:
> 
> 
> Abstract
> 
> 
> Python has long used metasyntactic variables that are based on the
> consumption of meat and dairy products, such as "spam", "ham", and
> "eggs".
> This language is not considerate to pigs or chicken and violates the
> spirit of the Code of Conduct.  This PEP proposes to retire the use
> of those names in official Python documentation and source code and to
> recommend users of Python to do the same.
> 
> 
> Motivation and Rationale
> 
> 
> Estimates for the number of animals slaughtered for meat every year
> vary, but `worldindata`_ estimates around 80 billion individuals.
> Farmed animals are often kept in small cages with little to no access
> to daylight, suffer stress during life and slaughter, or are otherwise
> systematically mistreated.
> 
> The `Python Code of Conduct`_ describes that community members are
> open, considerate, and respectful.  The Python standard library and
> documentation contain numerous references to meat or dairy based food
> products that are not respectful to our fellow inhabitants of planet
> Earth.  Examples include "spam", "bacon", and "eggs".
> 
> To align the language use in the standard library and documentation
> with
> the Code of Conduct, use of such language should be retired.
> 
> 
> Current practice
> 
> 
> There is a widespread tradition in the Python standard library, the
> documentation, and the wider community, to include references to Monty
> Pythons Flying Circus.  The use of "spam", "bacon", "sausage", and
> "eggs" can be traced back to the `"Spam" sketch`_ originally broadcast
> by the British Broadcasting Corporation (BBC) on 8 September 1972.
> In this sketch, a couple are trying to order food in a diner where all
> items contain spam.  The woman does not like spam and wants to order
> food without spam.  A group of horned vikings then sing about the
> wonderful spam.
> 
> To get an overview of the usage in the current standard library, the
> command ``cat $(find . -name '*.py') | grep -oi term | wc -l`` was
> used.
> This showed 2615 occurences for spam, 593 for ham (this include some
> false positives, among other reasons due to references to people whose
> name innociously contains the substring ham), 517 for eggs, 57 for
> bacon,
> and 10 for sausage.  Searching ``*.rst`` in the documentation revealed
> 391 occurrences for spam, 82 for ham, 96 for eggs, 28 for bacon, and
> 10 for sausage.  The source code for cpython revealed just 2 usages
> for
> spam and 1 for eggs.
> 
> Proposed alternatives
> =
> 
> Keeping with the good practice of referencing sketches from Monty
> Python's
> Flying Circus, this PEP proposes to adopt the fruits mentioned in the
> `"Self-Defence Against Fresh Fruit" sketch`_:
> 
> * raspberry (not currently in use)
> * banana  (68 times in standard library)
> * apricot (not currently in use)
> * pineapple (8 times in standard library)
> * peach (once in standard library)
> * redcurrant (not currently in use)
> * damson (not currently in use)
> * prune (23 times in standard library)
> 
> Other possible alternatives keeping with food items:
> 
> * salad (occurs once in standard library)
> * aubergine (referred to in the spam sketch)
> * shallot (the same)
> * tofu (vegan protein alternative)
> 
> 
> Specification
> =
> 
> For the reasons mentioned in the rationale, all references to meat or
> dairy
> products shall be removed from the Python standard library, the
> documentation,
> and the cpython source code.  The wider Python community is
> recommended to
> follow this practice.  In core Python:
> 
> * Programmers SHALL NOT use the metasyntactic variables "spam", "ham",
> "bacon",
>  or "sausage", neither as variable names, nor in example strings, nor
> in
>  documentation.
> * Programmers SHALL NOT use the metasyntactic variable "eggs" in
> context with
>  food items, but may still use it in context of other body parts.
> Prohibited:
>  ``["salad", "eggs"]``.  Allowed: ``["ovaries", "pouch", "eggs"]``.
> * Programmers SHALL NOT use any other metasyntactic variable that is
> unfriendly
>  to animals.
> 
> The wider Python community is encouraged to adopt these practices as
> well, but
> the

[Python-ideas] Re: returning a namedtuple on dict.items()

2020-03-31 Thread jdveiga

Nadav Wexler wrote:
> Hi,
> That is my first post here, I hope it's the right place for it.
> so I was using some dicts had the following code:
> env = dict(t for t in os.environ.items() if 'SUBSTRING' not in t[0])
> and I thought: It could have really been nice if i could do:
> env = dict(t for t in os.environ.items() if 'SUBSTRING' not in
> t.key)
> now I see that environ is not exactly a dict, but i think this is useful
> for all dictionary types. on the other hand, dicts are everywhere and i'm
> not sure about the performance impact of this for those that just ignore
> the access by attribute.
> of course, a matching t.value must be in place as well. ;)
> I would have opened a PR just to try out, but I feel this is so in the core
> that I'd first like to hear some comments.
> I was searching if anyone else had this idea before but couldn't find
> anything.
> Thanks,
> Nadav

`env = {key: value for key, value in os.environ.items() if 'SUBSTRING' not in 
key}`
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/5AERAPNDPAN4DEWNPKGBNEGQPFIXGEB2/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Issue 34850: Syntax Warning in the real world (is 0 / is 1)

On Mar 31, 2020, at 05:59, Philip Kahn  wrote:
> 
> 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).

Why? As far as I know, that optimization has never been included in any release 
of Jython, Iron, PyPy, Brython, or Skulpt. That particular test is true in some 
of these implementations anyway—in Brython because of a completely different 
optimization (ints up to 2**53 are usually smuggled around as doubles rather 
than as references to objects), in PyPy because of a pessimization they added 
to be more bug-compatible with CPython. And in some implementations it’s true 
sometimes and false other times (e.g., if they merge compile-time constants but 
don’t intern small ints, “is 1” will be true for a value that the compiler 
could reduce to a constant, but false for one that had to be computed at 
runtime). If you’re writing code like this because you expect that all Python 
interpreters will always have this optimization, your code is wrong and just 
happens to work in some situations.

Do you have code that you think actually _should_ be using is 1? Or code that 
you have to compile over and over (e.g., your deployment server doesn’t cache 
.pyc files, or you spawn new instances all the time without pre-built .pycs, or 
your app generates and compiles code on the fly, or …) and can’t change? If 
there are legitimate cases like those, I think that could definitely be a 
compelling argument against using SyntaxWarning here. But “the warning fired as 
intended and showed me a bug in my code” isn’t. And without more context, it’s 
hard to know which is the case here. So can you explain why this is a problem 
for you?
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/MOKVXFXJSZCCK5TGS77POTHSBDJFAREZ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] returning a namedtuple on dict.items()

2020-03-31 Thread Nadav Wexler

Hi,
That is my first post here, I hope it's the right place for it.

so I was using some dicts had the following code:
env = dict(t for t in os.environ.items() if 'SUBSTRING' not in t[0])

and I thought: It could have really been nice if i could do:
env = dict(t for t in os.environ.items() if 'SUBSTRING' not in
t.key)

now I see that environ is not exactly a dict, but i think this is useful
for all dictionary types. on the other hand, dicts are everywhere and i'm
not sure about the performance impact of this for those that just ignore
the access by attribute.

of course, a matching t.value must be in place as well. ;)
I would have opened a PR just to try out, but I feel this is so in the core
that I'd first like to hear some comments.
I was searching if anyone else had this idea before but couldn't find
anything.

Thanks,
Nadav
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/CCEMPVLWUMDE64UBWCPTXKRLRHLNZB56/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] PEP 9999: Retire animal-unfriendly language

2020-03-31 Thread Gerrit Holl

(needs a sponsor)

latest version at
https://github.com/gerritholl/peps/blob/animal-friendly/pep-.rst

PEP: 
Title: Retire animal-unfriendly language
Author: Gerrit Holl 
Discussions-To: python-ideas@python.org
Status: Draft
Type: Informational
Content-Type: text/x-rst
Created: 01-Apr-2020
Post-History: 01-Apr-2020
Sponsor:


Abstract


Python has long used metasyntactic variables that are based on the
consumption of meat and dairy products, such as "spam", "ham", and
"eggs".
This language is not considerate to pigs or chicken and violates the
spirit of the Code of Conduct.  This PEP proposes to retire the use
of those names in official Python documentation and source code and to
recommend users of Python to do the same.


Motivation and Rationale


Estimates for the number of animals slaughtered for meat every year
vary, but `worldindata`_ estimates around 80 billion individuals.
Farmed animals are often kept in small cages with little to no access
to daylight, suffer stress during life and slaughter, or are otherwise
systematically mistreated.

The `Python Code of Conduct`_ describes that community members are
open, considerate, and respectful.  The Python standard library and
documentation contain numerous references to meat or dairy based food
products that are not respectful to our fellow inhabitants of planet
Earth.  Examples include "spam", "bacon", and "eggs".

To align the language use in the standard library and documentation
with
the Code of Conduct, use of such language should be retired.


Current practice


There is a widespread tradition in the Python standard library, the
documentation, and the wider community, to include references to Monty
Pythons Flying Circus.  The use of "spam", "bacon", "sausage", and
"eggs" can be traced back to the `"Spam" sketch`_ originally broadcast
by the British Broadcasting Corporation (BBC) on 8 September 1972.
In this sketch, a couple are trying to order food in a diner where all
items contain spam.  The woman does not like spam and wants to order
food without spam.  A group of horned vikings then sing about the
wonderful spam.

To get an overview of the usage in the current standard library, the
command ``cat $(find . -name '*.py') | grep -oi term | wc -l`` was
used.
This showed 2615 occurences for spam, 593 for ham (this include some
false positives, among other reasons due to references to people whose
name innociously contains the substring ham), 517 for eggs, 57 for
bacon,
and 10 for sausage.  Searching ``*.rst`` in the documentation revealed
391 occurrences for spam, 82 for ham, 96 for eggs, 28 for bacon, and
10 for sausage.  The source code for cpython revealed just 2 usages
for
spam and 1 for eggs.

Proposed alternatives
=

Keeping with the good practice of referencing sketches from Monty
Python's
Flying Circus, this PEP proposes to adopt the fruits mentioned in the
`"Self-Defence Against Fresh Fruit" sketch`_:

* raspberry (not currently in use)
* banana  (68 times in standard library)
* apricot (not currently in use)
* pineapple (8 times in standard library)
* peach (once in standard library)
* redcurrant (not currently in use)
* damson (not currently in use)
* prune (23 times in standard library)

Other possible alternatives keeping with food items:

* salad (occurs once in standard library)
* aubergine (referred to in the spam sketch)
* shallot (the same)
* tofu (vegan protein alternative)


Specification
=

For the reasons mentioned in the rationale, all references to meat or
dairy
products shall be removed from the Python standard library, the
documentation,
and the cpython source code.  The wider Python community is
recommended to
follow this practice.  In core Python:

* Programmers SHALL NOT use the metasyntactic variables "spam", "ham",
"bacon",
  or "sausage", neither as variable names, nor in example strings, nor
in
  documentation.
* Programmers SHALL NOT use the metasyntactic variable "eggs" in
context with
  food items, but may still use it in context of other body parts.
Prohibited:
  ``["salad", "eggs"]``.  Allowed: ``["ovaries", "pouch", "eggs"]``.
* Programmers SHALL NOT use any other metasyntactic variable that is
unfriendly
  to animals.

The wider Python community is encouraged to adopt these practices as
well, but
the continued use of animal-unfriendly metasyntactic variables will
not be
considered a violation of the code of conduct.


Rejected ideas
==

The authors carefully considered the widespread use of the word "bug"
in the meaning of a source code error.  Insects including bugs play
a crucial role in ecosystems around the world, and it is not fair to
blame them for an error that can only be the programmer's.  However,
the use of the word "bug" for a source code error is too much
ingrained
into daily use, it far predates the Python community, is not limited
to
the Python community, and the word "bug" is less unfriendly

[Python-ideas] Re: Issue 34850: Syntax Warning in the real world (is 0 / is 1)

2020-03-31 Thread Nick Timkovich

>
> 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 explicitly want to differentiate between *CPython integer* 0's and
1's and floats? How about Numpy and other numeric libraries?

assert 0.0 is not 0
assert 1.0 is not 1
assert numpy.ones(1, dtype=int)[0] is not 1
assert numpy.int8(1) is not 1

I think you're going to cause sneaky bugs for yourself.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/HLXJHCBM27BWZFWWZRBRBLO2EFYOK7EJ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Explicitly defining a string buffer object (aka StringIO += operator)

2020-03-31 Thread Stephen J. Turnbull

Steven D'Aprano writes:
 > On Mon, Mar 30, 2020 at 10:08:06PM -0700, Guido van Rossum wrote:

 > > StringIO was created in order to fit code designed to a file,
 > > where all you want to do is capture its output and process it
 > > further, in the same process.

 > But it does that by *building a string*, does it not?

Not all two-pass processes on external streams build strings
internally.  At least, earlier you insisted that StringIO is not a
string.

 > That's what the getvalue() method is for.

True, but there's no guarantee a given process will ever invoke it.
For example, I might read a file encoded as ISO-2022 into a StringIO,
then read that StringIO normalizing it to another StringIO as NFD,
then encode it to a file as UTF-8.  Look Ma, no .getvalue!

Steve
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/5BBJ3HVBA4F6RASCFRAGAUPGFOVEG3GI/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Issue 34850: Syntax Warning in the real world (is 0 / is 1)

2020-03-31 Thread Chris Angelico

On Tue, Mar 31, 2020 at 11:57 PM Philip Kahn  wrote:
>
> Yikes, this change is spitting out a lot of warnings on first run, and plenty 
> in stuff that's not my code to boot.
>
> A huge number of the cases, though, seem to be "is 0" and "is 1" comparisons. 
> Having read through the original issue I get where the SyntaxWarning is 
> coming from, but it seems it'd be a genuine end-user experience improvement 
> to not raise the warning on those two classic "truthy" comparisons.
>
> 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).
>
> Mostly wanted to get that out there, but for now I'm rolling back my python 
> version rather than seeing a deluge of useless warnings. Right now, this is 
> just a great way to drown out real warnings in noisy unhelpful ones.
>

Your code is buggy. The warnings are telling you that your code is
buggy, even though *at the moment* it happens to work. And the fix is
simple - replace every "is 0" with "== 0", and your code will be
correct.

ChrisA
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/XJ4HBKNUFS7BQTEBEC5AH2HREQWY7VN2/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Issue 34850: Syntax Warning in the real world (is 0 / is 1)

2020-03-31 Thread Philip Kahn

Yikes, this change is spitting out a lot of warnings on first run, and
plenty in stuff that's not my code to boot.

A huge number of the cases, though, seem to be "is 0" and "is 1"
comparisons. Having read through the original issue I get where the
SyntaxWarning is coming from, but it seems it'd be a genuine end-user
experience improvement to not raise the warning on those two classic
"truthy" comparisons.

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).

Mostly wanted to get that out there, but for now I'm rolling back my python
version rather than seeing a deluge of useless warnings. Right now, this is
just a great way to drown out real warnings in noisy unhelpful ones.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/JVHOMRPCXFGR4L64T7M6CFJULPP3IMTI/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Compound with .. else statement

2020-03-31 Thread Jimmy Thrasibule

> But if you use a context manager which silences the exception, like
> contextlib.suppress() or unittest.TestCase.assertRaises(), it is easy to
> do too.
>
>  was_not_raised = False
>  with my_context():
>do_something_sensitive()
>was_not_raised = True
>  if was_not_raised:
>  print("We're all safe.")

That is indeed a way to workaround my use case. I do still find a
with/else more elegant.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/TO7ZCRVTPKSUL5EJ76F2IOMGUBTYLA33/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Compound with .. else statement


31.03.20 01:32, Christopher Barker пише:
In case Serhiy's answer wasn't clear: context managers can be written to 
handle exceptions (within their context) in any way you see fit.


that is: the method:
|
|
|__exit__(||self||, exc_type, exc_value, exc_traceback):|

get the exception, and information about it, of one is raised, so you 
can handle it anyway you want.


Actually I meant the opposite. Sorry for being unclear. In normal case 
the context manager does not silence a raised exception, so control flow 
is never passed to the statement past the with block if an exception is 
raised inside the with block.


But if you use a context manager which silences the exception, like 
contextlib.suppress() or unittest.TestCase.assertRaises(), it is easy to 
do too.


was_not_raised = False
with my_context():
  do_something_sensitive()
  was_not_raised = True
if was_not_raised:
print("We're all safe.")

You do not need a special syntax for this. was_not_raised will never be 
set to True if do_something_sensitive() raises an exception.

___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/ERCV4NY5MHHXVZMSFZDISRG3OKIFRLOC/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Explicitly defining a string buffer object (aka StringIO += operator)

2020-03-31 Thread Stephen J. Turnbull

Steven D'Aprano writes:

 > [I]t ought to be clear from Paul's well-written and detailed post,
 > which carefully explains what he wants.

Whose value to Python I still don't understand, because AFAICS it's
something that on the one hand violates TOOWTDI and has no parallels
elsewhere in the io module, and on the other hand is trivial to
implement for any programmer who really thirsts for StringIO.__iadd__.
Unless there are reasons why a derived class won't do?

I agree there seem to be possible space performance issues with
str.join that are especially painful for embedded applications (as
came out later in the thread I believe), but if those are solved by
StringIO, they're solved by StringIO.  So the whole thing seems to be
a cosmetic need for niche applications[1] for a niche platform[2] that
is addressed by a 4-line class definition[3] for users who want the
syntactic sugar.  Me, I'm perfectly happy with StringIO.write because
that's what I expect from the io module.  FWIW YMMV of course.

Footnotes: 
[1]  I don't even use strings at all in any of my adafruit applications!

[2]  OK, that's going too far, sorry.  Embedded matters, their needs
are real needs, and they face tight constraints most of us rarely need
to worry about.  It's still at present a minority platform, I believe,
and the rest of the sentence applies AFAIK.

[3]  Paul's "exact alias of .write() method", which can be done in 1
line, fails because .write() doesn't return self.  Thanks, Serhiy.  In
the stdlib we might even want a check for "at end of buffer" (.write()
can overwrite Unicode scalars anywhere in the buffer).  That's
definitely overengineering for a user, but in the stdlib, dunno.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/FBYJRWHOAUP4GQ73ADHBDW4MNDCTK5PM/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Explicitly defining a string buffer object (aka StringIO += operator)