[Python-ideas] Re: Python __main__ function
Artemis wrote: > > So your proposal is reducing features instead of > > expanding them. > > Surely, the __name__ variable would remain, so if people needed a more > > powerful way of doing it they could use that? But then, we introduce > > multiple ways of > > doing the same thing... > > The OP is proposing as a possibility: "we could require user to have only one if __name__ == '__main__':". In that case, functionality will be reduced, won't it? In any case, the proposal has been discussed and rejected in the past (PEP 299 https://www.python.org/dev/peps/pep-0299/) as Paul Sokolovsky has pointed out. ___ 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/H5TJ5RELMIJVVUZOEDGZE4TCCPOJTVIG/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Python __main__ function
redradist＠gmail.com wrote: > Hi all, > In Python we often use the following syntax to call the main logic of script > when it > was ran: > def main(): > pass # whatever should be done for `python ./script.py` > > if __name__ == '__main__': > main() > > Maybe it is a time to introduce the new module level function like __main__ ? > Consider the following code: > def __main__(): > pass # whatever should be done for `python ./script.py` > > It is much easy an less code to write ;) > Under-hood Python just will generate the following code: > def __main__(): > pass # whatever should be done for `python ./script.py` > > # Below generated code > if __name__ == '__main__': > __main__() > > If there are two if __name__ == '__main__': it is also not an issue: > def __main__(): > pass # whatever should be done for `python ./script.py` > > def main(): > pass # whatever should be done for `python ./script.py` > > if __name__ == '__main__': > main() > > # Below generated code > if __name__ == '__main__': > __main__() > > Or we could require user to have only one if __name__ == '__main__': > ... > What do you think, please share your opinion ... While is possible to use if __name__ == '__main__': several times in the same script, your proposed magic function def __main__() cannot be redefined. Not to speak about lexical scope differences between one approach and the other. So your proposal is reducing features instead of expanding them. (Sorry for repeating the message. The first one went to another thread) ___ 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/OIVWKH44TWQMVO5JOHKUCM7VMDSKVB7M/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Equality between some of the indexed collections
Greg Ewing wrote: > On 6/05/20 7:45 pm, Henk-Jaap Wagenaar wrote: > > So... say you are solving a problem in 1d, you do > > that on a real number > > x, right? Now you solve it in 2d, so you do your work on a pair (x, y), > > then you might solve it in 3d and do your work on a triplet (x, y, z). A > > few days later you generalize it to n-dimensions and you get a > > sequence > > At this point I would say that you haven't created an infinite > tuple, you've created an infinite sequence of finite tuples. > > Then, a few days later you generalize it to infinite > > sequences (x_1, > > x_2, ...). > > Now here I would stop and say, wait a minute, what does this > proof look like? I'm willing to bet it involves things that > assume some kind of intrinsic order to the elements of this > "tuple". If it does, and it's an extension to the finite > dimensional cases, then I would say you were really dealing > with sequences, not tuples, right from the beginning. > Now I must admit I was a bit hesitant about writing that > statement, because in quantum theory, for example, one often > deals with vector spaces having infinitely many dimensions. > You could consider an element of such a space as being an > infinite tuple. > However, to even talk about such an object, you need to be > able to write formulas involving the "nth element", and those > formulas will necessarily depend on the numerical value of > n. This gives the elements an intrinsic order, and they will > have relationships to each other that depend on that order. > This makes the object more like a sequence than a tuple. > Contrast this with, for example, a tuple (x, y, z) representing > coordinates in a geometrical space. There is no inherent > sense in which the x coordinate comes "before" the y coordinate; > that's just an accident of the order we chose to write them > down in. We could have chosen any other order, and as long as > we were consistent about it, everything would still work. > This, I think, is the essence of the distinction between > tuples and sequences in mathematics. Elements of sequences > have an inherent order, whereas elements of a tuple have at > best an arbitrarily-imposed order. However, in Python, tuples and lists are both sequences, ordered sets of elements. So it is not completely unreasoned to see them as Ahmed Amr is proposing: that is, so similar types that you can expect that if they have the same element, they are equal. (Like frozensets and sets in the "set type" domain). Indeed, tuples and lists are equivalent in Python: `(list() == list(tuple()) and tuple(list()) == tuple()) is True`. Do not misunderstand me. I agree with the idea that tuples and lists are different by design while frozenset and sets are not (as Steven D'Aprano pointed out in a previous posts). But considering tuples and lists as just ordered sets of elements and based their equality on their elements, not in their type, is an appealing idea. I think that some Pythonists would not disagree. A different thing is the practicality of this. ___ 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/T6BP6JBPMGCJEX4QF6SY4SM72344AEYF/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Equality between some of the indexed collections
Steven D'Aprano wrote: > On Tue, May 05, 2020 at 09:34:28AM -, jdve...@gmail.com wrote: > > (frozenset() == set()) is True shocked > > me. > > According to wikipedia https://en.wikipedia.org/wiki/Equality_(mathematics): > > "equality is a relationship between two quantities or, more generally two > > mathematical > > expressions, asserting that the quantities have the same value, or that the > > expressions > > represent the same mathematical object." > > If lists and tuples are considered different "mathematical objects" > > (different types), they cannot be considered equal --tough they can be > > equivalent, for instance ([1, 2, 3] == list((1, 2, 3)) and tuple([1, > > 2, 3]) == (1, 2, 3)) is True. > > There is no good correspondence between "mathematical objects" and > types. Even in mathematics, it is not clear whether the integer 1 as the > same mathematical object as the real number 1, or the complex number 1, > or the quaternion 1. > In Python, we usually say that if a type is part of the numeric tower > ABC, then instances with the same numeric value should be considered > equal even if they have different types. But that's not a hard rule, > just a guideline. > And it certainly shouldn't be used as a precedent implying that > non-numeric values should behave the same way. > If you are looking for a single overriding consistant principle for > equality in Python, I think you are going to be disappointed. Python > does not pretend to be a formal mathematically consistent language > and the only principle for equality in Python is that equality means > whatever the object's __eq__ method wants it to mean. > > I can only explain (frozenset() == set()) is > > True vs (list() == tuple()) is False if: > > a) frozensets and sets are considered the same "mathematical > > > > objects". So immutability vs mutability is not a relevant feature in > > Python equality context. Then, list() == tuple() should be True > > if > > no other feature distinguishes lists from tuples, I suppose... > > List and tuple are distinguished by the most important feature of all: > the designer's intent. Tuples are records or structs, not frozen lists, > which is why they are called tuple not frozen list :-) even if people > use them as a defacto frozen list. > On the other hand, frozensets are frozen sets, which is why they compare > equal. > Does this make 100% perfectly logical sense? Probably not. But it > doesn't have to. Lists and tuples are considered to be independent kinds > of thing, while sets and frozensets are considered to be fundamentally > the same kind of thing differentiated by mutability. > (In hindsight, it might have been more logically clear if mutable sets > inherited from immutable frozensets, but we missed the chance to do > that.) Thanks for your reply. I do not expect any kind of full correspondence between mathematical objects and programming objects. Just reasoning by analogy and trying to understand how lists and tuples cannot be equal and frozensets and sets can be on similar grounds. Mostly asking than answering. Designers' intent is an admissible answer, of course. A cat and a dog can be equal if equality is defined as "having the same name". However, designers' intent is one thing, and users' understating is another one. >From your words, I have learnt that --from designers' point of view-- tuples >are different from lists in their nature while sets and frozensets are mostly >the same kind of thing --roughly speaking of course... I wonder if users share that view. I feel that it is not unreasonable to expect that frozenset and set cannot be equal on the grounds that they are different types (as tuples and lists are different types too). From that perspective, equality on tuples / lists and frozensets / sets should follow similar rules. Not being that way is surprising. That is all. However, if sets and frozensets are "are considered to be fundamentally the same kind of thing differentiated by mutability", as you said, why not tuples and lists? And that is, I guess, the reasoning behind proponent's claim. What if the difference between tuples and lists is not so deep or relevant and they just differ on mutability? Asking again... ___ 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/4AKVBC3GLGJLAQXB55NQA55KKELC6Y23/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Equality between some of the indexed collections
Raymond Hettinger wrote:
> > On May 3, 2020, at 6:19 PM, Steven D'Aprano st...@pearwood.info wrote:
> > frozenset and set make a counterexample:
> > frozenset({1}) == {1}
> > True
> > Nice catch! That's really interesting. Is there reasoning
> > behind
> > frozenset({1}) == {1} but [1] != (1,), or is it just an accident
> > of
> > history?
> > Conceptually, sets are sets, whether they are mutable or frozen.
> > Right. This isn't an accident. It is by design.
> Also, some numeric types are specifically designed for cross-type comparison:
> >>> int(3) == float(3) == complex(3, 0)
> True
>
> And in Python 2, by design, str and unicode were comparable:
> >>> u'abc' == 'abc'
> True
>
> But the general rule is that objects aren't cross-type comparable by default.
> We have
> to specifically enable that behavior when we think it universally makes
> sense. The modern
> trend is to avoid cross-type comparability, enumerates and data classes for
> example:
> >>> Furniture = Enum('Furniture', ('table', 'chair', 'couch'))
> >>> HTML = Enum('HTML', ('dl', 'ol', 'ul', 'table'))
> >>> Furniture.table == HTML.table
> False
>
> >>> A = make_dataclass('A', 'x')
> >>> B = make_dataclass('B', 'x')
> >>> A(10) == B(10)
> False
>
> Bytes and str are not comparable in Python 3:
> >>> b'abc' == 'abc'
> False
>
> > Isn't a tuple
> > essentially just a frozenlist? I know the intended
> > semantics of tuples and lists tend to be different, but I'm not sure that's
> > relevant.
> > In terms of API, it might look that way. But in terms of use cases, they
> are less alike: lists-are-looping, tuples-are-for-nonhomongenous-fields.
> List are like
> database tables; tuples are like records in the database. Lists are like C
> arrays;
> tuples are like structs.
> On the balance, I think more harm than good would result from making sequence
> equality
> not depend on type. Also when needed, it isn't difficult to be explicit that
> you're
> converting to a common type to focus on contents:
> >>> s = bytes([10, 20, 30])
> >>> t = (10, 20, 30)
> >>> list(s) == list(t)
>
> When you think about it, it makes sense that a user gets to choose whether
> equality is
> determined by contents or by contents and type. For some drinkers, a can of
> beer is equal
> to a bottle of bear; for some drinkers, they aren't equal at all ;-)
> Lastly, when it comes to containers. They each get to make their own rules
> about what
> is equal. Dicts compare on contents regardless of order, but OrderedDict
> requires that
> the order matches.
> Raymond
`(frozenset() == set()) is True` shocked me.
According to wikipedia https://en.wikipedia.org/wiki/Equality_(mathematics):
"equality is a relationship between two quantities or, more generally two
mathematical expressions, asserting that the quantities have the same value, or
that the expressions represent the same mathematical object."
If lists and tuples are considered different "mathematical objects" (different
types), they cannot be considered equal --tough they can be equivalent, for
instance `([1, 2, 3] == list((1, 2, 3)) and tuple([1, 2, 3]) == (1, 2, 3)) is
True`.
I can only explain `(frozenset() == set()) is True` vs `(list() == tuple()) is
False` if:
a) `frozenset`s and `set`s are considered the same "mathematical objects". So
immutability vs mutability is not a relevant feature in Python equality
context. Then, `list() == tuple()` should be `True` if no other feature
distinguishes lists from tuples, I suppose...
b) language designers found `(frozenset() == set()) is True` convenient (why?).
Then, why is not `(list() == tuple()) is True` so convenient?
c) it is a bug and `frozenset() == set()` should be `True`.
___
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/KWMD2ILZ4YN3V2A75HCDFX7YIL7S5FWL/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: PEP 618: Add Optional Length-Checking To zip
Alex Hall wrote: > If you use the word 'even' and tell me it has to do with lengths (or any > number) I'm going to think of multiples of 2, not equality. > On Mon, May 4, 2020 at 3:52 PM jdve...@gmail.com > wrote: > > Guido van Rossum wrote: > > I should really stay out of this (hundreds of > > messages and still > > bickering^Wbikeshedding :-), but I personally find strict=True less > > confusing than equal=True, both for zip() and for map(). If I didn't know > > what was going on, seeing equal=True would make me wonder about whether > > equality between the elements might be involved somehow. > > On Sun, May 3, 2020 at 9:42 PM Christopher Barker python...@gmail.com > > wrote: > > On Sun, May 3, 2020 at 6:17 PM Steven D'Aprano > > st...@pearwood.info > > wrote: > > map(func, x, y, strict=True) # ? > > Admittedly the word "strict" in the context of map would be rather > > confusing. > > This a really good argument for "equal" rather than "strict". > > Sorry, I'm not seeing why this would be confusing for map but not > > zip. And "equal" might suggest that x and y need to be equal. > > of course it would be confusing for zip. I and others have been > > advocating > > for "equal" over "strict" for a whiie. this is yet another argument. > > Since > > I never liked "strict", I'm not sure I can argue why it might be more > > confusing or map than zip :-) > > Perhaps "truncate" or even "trunc" is a better keyword than either > > strict or equal. Not that I'm arguing for a > > keyword here. > > But it wouldn't be truncating anything. If we want to be wordy, > > equal_length would do it -- but I wouldn't want to be that wordy. > > -CHB > > Christopher Barker, PhD > > Python Language Consulting > > Teaching > > Scientific Software Development > > Desktop GUI and Web Development > > wxPython, numpy, scipy, Cython > > 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/DK3PG4. > > .. > > Code of Conduct: http://python.org/psf/codeofconduct/ > > --Guido van Rossum (python.org/~guido) > > Pronouns: he/him **(why is my pronoun here?) > > http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-c. > > .. > > What about even as "equal in number or amount"? > > > > 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/GLAEXJ... > > Code of Conduct: http://python.org/psf/codeofconduct/ Ok,`even`is one of those scarce polysemic words in English ;-) Meaning depends on context and message receiver's expectations, of course. But... "add an even mixture of milk and cream" and "the curtain rod and the top of the window should be even" --examples taken from wordreference-- are quite similar to say "zip even iterators". To me, "zip even iterators" is more precise than "zip strict iterators or "zip equal iterators" --since they are no equal, just equal in length. Obviously, my prefer option is `force_equal_length` but... you know... verbose... ___ 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/GILI4RXOPRKXVKILIJ7L5KHPZ2VY5GMU/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: PEP 618: Add Optional Length-Checking To zip
Guido van Rossum wrote: > I should really stay out of this (hundreds of messages and still > bickering^Wbikeshedding :-), but I personally find strict=True less > confusing than equal=True, both for zip() and for map(). If I didn't know > what was going on, seeing equal=True would make me wonder about whether > equality between the elements might be involved somehow. > On Sun, May 3, 2020 at 9:42 PM Christopher Barker python...@gmail.com > wrote: > > On Sun, May 3, 2020 at 6:17 PM Steven D'Aprano st...@pearwood.info > > wrote: > > map(func, x, y, strict=True) # ? > > > > Admittedly the word "strict" in the context of map would be rather > > confusing. > > This a really good argument for "equal" rather than "strict". > > Sorry, I'm not seeing why this would be confusing for map but not > > zip. And "equal" might suggest that x and y need to be equal. > > of course it would be confusing for zip. I and others have been advocating > > for "equal" over "strict" for a whiie. this is yet another argument. Since > > I never liked "strict", I'm not sure I can argue why it might be more > > confusing or map than zip :-) > > Perhaps "truncate" or even "trunc" is a better keyword than either > > strict or equal. Not that I'm arguing for a > > keyword here. > > But it wouldn't be truncating anything. If we want to be wordy, > > equal_length would do it -- but I wouldn't want to be that wordy. > > -CHB > > -- > > Christopher Barker, PhD > > Python Language Consulting > > > > Teaching > > Scientific Software Development > > Desktop GUI and Web Development > > wxPython, numpy, scipy, Cython > > > > > > 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/DK3PG4... > > Code of Conduct: http://python.org/psf/codeofconduct/ > > -- > --Guido van Rossum (python.org/~guido) > Pronouns: he/him **(why is my pronoun here?) > http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-c... What about `even` as "equal in number or amount"? ___ 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/GLAEXJCTNX2EFGUNCVU4NQ3TQGTIY6QN/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: RFC: For Loop Invariants
André Roberge wrote:
> On Fri, Apr 10, 2020 at 5:26 PM Elliott Dehnbostel pydehnbos...@gmail.com
> wrote:
> > Hello Everyone,
> > If I've done this incorrectly, please let me know so that I can
> > improve/revise. I'm new to the Python community and quite enjoy the more
> > functional features of Python 3, but have I have a peeve about it. I'd like
> > to propose and discuss the following enhancement to Python 3:
> > Consider the following trivial for-loop:
> > chars = "abcaaabkjzhbjacvb"
> > seek = {'a','b','c'}
> > count = 0for a in chars:
> > if a in seek:
> > count += 1
> > Gross. Twice nested for a simple count.
> > count = 0
> > for a in chars:
> > count = count + 1 if a in seek else count
> > Once nested -- if nested == gross, then this is not gross. (However, I
> prefer the twice nested which I find clear and simple -- not gross.)
> André Roberge
> >
> > 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/A2PTKI...
> > Code of Conduct: http://python.org/psf/codeofconduct/
> >
Nothing wrong with
```
for a in chars:
if a in seek:
count += 1
```
It is readable and does the job. There are other approaches that can do the job
too.
For instance,
```
len([char for char in chars if char in seek])
```
So why do we need a new syntax for this case? What does this new syntax so
special?
___
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/EGDK5ELS2KACDKQQ5T7MHWTKLFMM3KPQ/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Alternative to iterator unpacking that wraps iterator-produced ValueError
Soni L. wrote: > On 2020-04-09 8:48 a.m., Rhodri James wrote: > > [Muchly snipped] > > On 09/04/2020 12:27, Soni L. wrote: > > To put it simple, unpacking raises > > ValueError: > > But if the iterator raises ValueError, there's no way to tell it > > apart from the unpacking: > > I don't see how this is any different from any other case when you get > > the same exception for different errors. If for some reason you > > really care, subclass ValueError to make a finer-grained exception. > > And the workaround for this is a bit ugly. We > > already convert e.g. > > StopIteration into RuntimeError in many cases, why can't we do so > > here too? > > Surely the correct "workaround" is not to do the thing that raises the > > exception? > > Technically, I consider it a bug that bugs can shadow API-level > > exceptions. Any API defining API-level exceptions must carefully control > > the exceptions it raises. In this case I'd like to use the ValueError > > from the iterator unpacking API, on my API. But since the iterator > > unpacking API doesn't control its exceptions, this just does a great job > > of masking bugs in the code instead. > > Equally, anything doing computation in __get__ should not propagate > LookupError except where explicitly intended. And that's not how those > things are often implemented, unfortunately. There's a reason ppl > complain so much about certain frameworks "eating all the exceptions". > They use exceptions as part of their API but let user code raise those > API-level exceptions, which, because they're part of the API, get > handled somewhere. Strictly speaking, there is any unpackaging error in your example. Your example raises its own ValueError before any unpackaging error is raised. Indeed ``` x, y = foo() ``` also raises your own `ValueError` and there is any unpackaging error involved. On the other hand, an alternative design that does not raise any exception, does raise the proper unpackaging exception. For instance: ``` def foo(): yield True return x = foo() x, = foo() x, y = foo() ``` outputs: ``` Traceback (most recent call last): File "...", line 7, in x, y = foo() ValueError: not enough values to unpack (expected 2, got 1) ``` So, IMHO, you are mixing two different things here. Am I wrong? Are you talking about something different? Thank 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/UBCF6LQCBGPMZERLOVQONEJPSCO5QGRO/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Explicitly defining a string buffer object (aka StringIO += operator)
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: returning a namedtuple on dict.items()
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: Explicitly defining a string buffer object (aka StringIO += operator)
I completely agree with Andrew Barnert. I just want to add a little comment about overriding the `+=` (and `+`) operator for StringIO. Since StringIO is a stream --not a string--, I think `StringIO` should continue to use the common interface for streams in Python. `write()` and `read()` are fine for streams (and files) and you can find similar `write` and `read` functions in other languages. I cannot see any advantage on departing from this convention. ___ 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/LFGQVJDOGBBJ7CIYHISM4X4IZDWLGFII/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Limit 'import as' syntax
joperez＠hotmail.fr wrote: > There should be one-- and preferably only one --obvious way to do it. (from > The Zen of > Python https://www.python.org/dev/peps/pep-0020/) > However, in something as basic as import syntax, that's not the case. This > example comes > from PEP 221 (https://www.python.org/dev/peps/pep-0221/) > : > A slightly special case exists for importing sub-modules. The statement > import os.path > stores the module os locally as os, so that the imported submodule path is > accessible as > os.path. As a result, > import os.path as p > stores os.path, not os, in p. This makes it effectively the same as > from os import path as p > Not only it doesn't respect the Zen of Python, but it's also quite > counterintuitive > because as explained in the PEP, the behavior of import os.path as p is not > the same than import os.path, while from os import path as p is > quite consistent with or without as. > There is one case where import ... as ... is consistent (and justified IMHO), > that's for statements like import _thread as thread, only the imported object > is aliased (as from ... import ... as ... do). > Looking at the standard library, only few dozens of lines match the regex > ^import > \w+\.(\w|\.)+ as, while the other (equivalent) form has hundreds of matches. > That's why I propose to restrict the aliased import statement (import ... as > ...) to not be able to alias imported submodule, letting from ... import ... > as ... statement be the only to do it. > The roadmap could be to depreciate the statement with a warning in a few next > releases, to > remove finally remove the syntax. > (hoping my English is okay) `import ...` and `from ... import ...` does not behave in the same manner as it is explained in docs: https://docs.python.org/3/reference/simple_stmts.html#import. So they are not equivalent statements. `import os.path as p` and `from os import path as p` bind the same local name to the same object, that is true. However, they do in a quite different manner. And this difference can be relevant, for instance, when are dealing with circular imports (ok, I cannot remember any example of this right now). So I do not see how they are violating any principle in PEP 20 "The Zen of Python". Anyway, The Zen of Python is an inspirational document, not a law. Even it it was the law, any law has its exceptions and PEP 221 "Import As" presents and explains one useful exception. In my opinion... Thank 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/MGLG5YJMDLDU3LHCJP2POCVFW33342LB/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: More appropriate behavior for the NotImplemented object
Steven D'Aprano wrote: > On Wed, Mar 11, 2020 at 09:42:15AM -, Steve Jorgensen wrote: > > I realize this is probably something that would be > > hard to change for > > compatibility reasons. Maybe someone can think of a way around that > > though? > > It seems to me that not NotImplemented should result in > > NotImplemented and attempting to convert it to bool should raise > > a > > TypeError exception. > > To my disappointment, you will get your wish, at least for the second > part: > https://bugs.python.org/issue35712 > I am disappointed because, to me, it is a fundamental part of Python's > object model that everything can be interpreted as a truthy/falsey > object (in the absence of bugs). > Anyway, the deprecation warning has been checked in, so it's probably > only a matter of time before you will get your TypeError :-) Oouh, I also feel disappointed. Indeed, I feel that NotImplemented is a fiasco and that a TypeError exception should be raised instead. But I suppose it is central to duck typing concept... ___ 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/7VCQ6MZPC7MRX4FFPAG7X4AIAD7AP4SU/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: More appropriate behavior for the NotImplemented object
Steve Jorgensen wrote: > I realize this is probably something that would be hard to change for > compatibility > reasons. Maybe someone can think of a way around that though? > It seems to me that not NotImplemented should result in > NotImplemented and attempting to convert it to bool should raise > a TypeError exception. > Take the following example: > def __lt__(self, other): > return not self.__ge__(other): > > def __le__(self, other): > return not self.__gt__(other): > > def __ge__(self, other): > > > Currently, this will not work because NotImplemented is truthy and > not NotImplemented is False, so it is necessary to complicate > the implementations of __lt__ and __le__ to specifically check > whether the value returned from the complementary method returned > NotImplemented or not. > If the value of not NotImplemented was NotImplemented then > the coding pattern above would simply work. Yeah, it seems contra-intuitive. But there is some logic in that behaviour. `not NotImplemented` is a boolean test and, I think, it follows the "Truth Value Testing" (https://docs.python.org/3/library/stdtypes.html#truth). According to that, `bool(NotImplemented)` returns True so `not bool(NotImplemented)` returns False. Ultimately, the NotImplemented singleton is like any other Python object and, from some point of view, it is logical that it behaves like other objects. From that point of view, `not NotImplemented` must not return `NotImplemented` ever --it is not a boolean value! Raising a TypeError when executing `bool(NotImplemented)`? Why? In my understanding, if you are comparing two object with different types (which cannot be compared), False is not a wrong answer. Remember that NotImplemented is a "special value which should be returned to indicate that the operation is not implemented with respect to the other type" and its purpose is that "the interpreter will try the reflected operation on the other type" (https://docs.python.org/3/library/constants.html#NotImplemented). So, IMHO, you should check if __ge__ returns a NotImplemented singleton or not and react accordingly to the result of that test. ___ 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/BDCOTQVEHG4Q7MYBLNGNXA2W36FAUP7Y/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Control adding script path/CWD to sys.path
I see... never use this feature. I make extensive use of running modules from local (non-PYTHONPATH) directories. When these modules import (local) sub-modules, the best and simplest method I have found is running them from top directory of the corresponding application. I can run any module in the corresponding hierarchy easily. (Plus running other utilities just providing relative imports.) That is my workflow, so my recommendation on running modules and avoiding import errors. ___ 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/FWWI44HUDVXKNHXISSWL3E2WACGPODV2/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Control adding script path/CWD to sys.path
Eryk Sun wrote: > On 2/24/20, jdve...@gmail.com jdve...@gmail.com wrote: > > > > It is the intended and the expected behaviour. The > > working directory is > > always added to the sys.path. > > You mean always in this particular context, i.e. the working directory > is added normally when executing a command via -c or a module as a > script via -m. When executing a script normally, the script directory > gets added, which is reasonably secure. Yeah, you are right. > Adding the working directory to sys.path is ok for the interactive > shell and -c commands, but I don't understand why it gets added with > -m, which is a security hole, and to me an annoyance. It can be > disabled with isolated mode, but that's a blunt instrument that > disables too much. If current directory is not added to the sys.path, how can modules be imported outside PYTHONPATH? https://docs.python.org/3/glossary.html#term-import-path Python cannot guess where your modules are if paths to search for them are not provided. If you run a script from terminal it is assumed that your modules are in the working directory. Is another asumption possible? Maybe you can pass this path via CLI but I think that this is not currently possible. As long as I know, you must include your path in PYTHONPATH or run it from a proper directory. Correct me if I am wrong. On the other hand, can you explain why adding the current directory to importable paths creates a security hole? I am curious. No idea about this. ___ 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/CPAI6PX3VITXJQLA53CJ6QMAT2T5T5I6/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Control adding script path/CWD to sys.path
Nick Timkovich wrote: > > Are you familiar with the -I option for "isolated mode"? > https://docs.python.org/3/using/cmdline.html#id2 > -I > Run Python in isolated mode. This also implies -E and -s. In isolated mode > sys.path contains neither the script’s directory nor the user’s > site-packages directory. All PYTHON* environment variables are ignored, > too. Further restrictions may be imposed to prevent the user from injecting > malicious code. New in version 3.4. Oooh... Can you provide some examples on the use of -I? I try to use along with -m (`python -I -m a.b`) and get this error: "python: Error while finding module specification for 'a.b' (ModuleNotFoundError: No module named 'a')". On the other hand `python -m a.b -I` just passed -I as a script's CLI argument. Of course, I get the expected results if run `python -I` on terminal. ___ 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/QTZRM5QZI6DI7D43XVYX2GR75IX5SUFX/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Incremental step on road to improving situation around iterable strings
Alex Hall wrote: > > Conversely, I can't remember a case where I've ever > > accidentally > > iterated over a string when I meant not to. > > Do you ever return a string from a function where you should have returned > a list containing one string? Or similarly passed a string to a function? > Forgotten to put a trailing comma in a singleton tuple? Forgotten to add > .items() to for key, value in kwargs:? > > compelling arguments are typically > > around demonstrating how much code would be demonstrably better with > > the new behaviour > > That represents a misunderstanding of my position. I think I'm an outlier > among the advocates in this thread, but I do not believe that implementing > any of the ideas in this proposal would significantly affect code that > lives in the long term. Some code would become slightly better, some > slightly worse. My concern surrounds the user experience when debugging > code that accidentally iterates over a string. So it's impossible for me to > show you code that becomes significantly better because that's not what I'm > arguing about, and it's unfair to say that quoting people who have > struggled with these bugs is not evidence for the problem. > Similarly for jdveiga, I cannot give you "real workable surprising code" > because I'm talking about code that isn't workable as a result of being > surprising. I have given examples of real non-working surprising code, and > I can give more, and if that's not indicative of a real problem then I'm > very confused and would appreciate more explanation. > On Mon, Feb 24, 2020 at 7:11 PM Paul Moore p.f.mo...@gmail.com wrote: > > On Mon, 24 Feb 2020 at 16:23, Alex Hall alex.moj...@gmail.com wrote: > > Roughly, though I think you might be hearing me > > wrong. There is lots of > > existing code that correctly and intentionally iterates over strings. And > > code that unintentionally does it probably doesn't live for long. But if > > you took a random sample of all the times that someone has written code > > that creates new behaviour which iterates over a string, most of them would > > be mistakes. And essentially the developer was 'wrong' in those instances. > > In my case, since I can't think of when I've needed to iterate over a > > string, I've probably been wrong at least 90% of the time. > > Conversely, I can't remember a case where I've ever accidentally > > iterated over a string when I meant not to. I can remember many > > times when I've relied on strings being iterable. > > Me quoting my experience is neither more nor less valuable than you > > quoting yours. However, mine aligns with the current behaviour of > > Python, and keeping things as they are so that my experience doesn't > > change has no backward compatibility implications. So I don't need to > > justify a preference that the language does what suits me best :-) > > I don't think (I haven't checked the thread closely) that anyone is > > saying your experience/expectation is "wrong". But to be sufficient to > > result in a change in the language, you have to establish that your > > behaviour is significantly better than the status quo, and I don't > > think that you're doing that at the moment. And IMO, you're never > > likely to do so simply by quoting numbers of people who do or don't > > prefer the current behaviour - compelling arguments are typically > > around demonstrating how much code would be demonstrably better with > > the new behaviour, along with showing that code that is detrimentally > > affected has an easy workaround. Your .chars() proposal targets the > > latter question, but neither you, nor anyone else in past iterations > > of this discussion, have yet come up with anything persuasive for the > > former, that I'm aware of. > > Paul > > If you can provide a real code of strings wrongdoing, I will be convinced. On the contrary, you have provided two examples --as long as I can remember-- on the expected and implemented behaviour of strings in Python. Nothing wrong on language implementation. Just your desire that things work in a different manner -- but this is not suffice to change the foundations of any programming language: start your own language if you feel so disappointed; Guido did. I am really eager to be convinced. Please, show us a snippet that proves your point of view. If you cannot, accept that Python's string model is just a convention and that programming languages are purely conventional. Computation is not about Python, or Lisp, or Java, is about algorithms. ___ 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/RQTZ464QSQZUVIFROYSTGESP3FR3PFZD/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Incremental step on road to improving situation around iterable strings
Paul Moore wrote: > On Mon, 24 Feb 2020 at 16:23, Alex Hall alex.moj...@gmail.com wrote: > you have to establish that your > behaviour is significantly better than the status quo, and I don't > think that you're doing that at the moment. And IMO, you're never > likely to do so simply by quoting numbers of people who do or don't > prefer the current behaviour - compelling arguments are typically > around demonstrating how much code would be demonstrably better with > the new behaviour, along with showing that code that is detrimentally > affected has an easy workaround. Your .chars() proposal targets the > latter question, but neither you, nor anyone else in past iterations > of this discussion, have yet come up with anything persuasive for the > former, that I'm aware of. > Paul Yeah, I tiresomely agree (can I say that in English?) Once again... we need evidence: real workable surprising code! Please... ___ 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/GK6IS2NHENLN2UZQUCH7PLPVBPVF64WZ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Control adding script path/CWD to sys.path
Brianvanderburg2 wrote: > This is just an idea, which may not in practice be a major problem but can at > times be > an inconvenience. I thought I had posted this in the "python -m" thread a > little while > back but checking my history it does't appear I did, I do apologize if this > is a > duplicate. > 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 appears to result in CWD being used. > But, depending on the directory structure, modules imported may not be the > expected > modules. For instance, if developing a package 'mypackage', with some OS > specific code > organized into an os module or subpackage "mypackage.os", and then running > something like > "python -m pytest" or "pylint ..." in the directory for the package would > cause an "import > os" to treat the mypackage/os(.py) module or package as the top level import > and cause > errors. (I've actually had this happen which is what prompts this idea) It is the intended and the expected behaviour. The working directory is always added to the sys.path. If you have a hierarchy such as a.b.c.d (corresponding to a/b/c/d filesystem tree) and you run the module c from the sub-directory c, you cannot expect that python guesses that c is a sub-package of a and runs the script as if you are calling from folder a. You must call c from directory a and import it with the corresponding a.b.c hierarchy: python -m a.b.c ___ 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/HR6U3G4UBNZ2UW7V4F5IZQ5OPUNP2VAJ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Make ~ (tilde) a binary operator, e.g. __sim__(self, other)
Aaron Hall wrote: > The context for this is statistics , so I'll quote Wolfram on tilde in the > context of > statistics: http://mathworld.wolfram.com/Tilde.html > "In statistics, the tilde is frequently used to mean "has the distribution > (of)," for > instance, X∼N(0,1) means "the stochastic (random) variable X has the > distribution N(0,1) > (the standard normal distribution). If X and Y are stochastic variables then > X∼Y means "X > has the same distribution as Y." I think that you have refuted your own idea. You have argued that ~ is rightful statistical operator. But Python is not an statistical language. Python is a general purpose programming language while R is a statistical one. They have different domains so what is useful and right in R it is not necessary useful and right in Python. I cannot see a case for a statistical operator in Python. ___ 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/IZMGSVIEHWDASTLUDP5AXLQKMZ4BPDGR/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Make ~ (tilde) a binary operator, e.g. __sim__(self, other)
Aaron Hall wrote: > Currently, Python only has ~ (tilde) in the context of a unary operation (like > -, with __neg__(self), and +, __pos__(self)). > ~ currently calls __invert__(self) in the unary context. > I think it would be awesome to have in the language, as it would allow > modelling along the > lines of R that we currently only get with text, e.g.: > smf.ols(formula='Lottery ~ Literacy + Wealth + Region', data=df) > With a binary context for ~, we could write the above string as pure Python, > with > implications for symbolic evaluation (with SymPy) and statistical modelling > (such as with > sklearn or statsmodels) - and other use-cases/DSLs. > In LaTeX we call this \sim (Wikipedia indicates this is for "similar to"). > I'm not too particular, but __sim__(self, other) would have the benefits of > being both short and consistent with LaTeX. > This is not a fully baked idea, perhaps there's a good reason we haven't > added a binary > ~. It seems like I've seen discussion in the past. But I couldn't find such > discussion. And as I'm currently taking some statistics courses, I'm getting > R-feature-envy again... > What do you think? > Aaron Hall I really do not fully understand your proposal. I do not know nothing about R and my statistical knowledge has gone long ago. However, I think that we cannot expect that Python accommodates every existing domain. Let me explain: Python have not special features, syntax, operators to deal with SQL, HTML, ini files, OpenGL, etc. These domains, and others, are supported via libraries, outside of the language core. ~ exists in bit-wise context and, as long as I know, it comes from C --I have never used it indeed in Python. It is a unary operator because it works in that way as a bitwise operator. I cannot see any improvement in becoming ~ into a binary operator. I imagine that a binary ~ would have a completely different meaning from a unary ~. I can foresee many problems here. In my opinion, you should prove that binary ~ has a relevant benefit for the whole language, not just for R tasks. It should be useful in some different domains and behave consistently --or at least so consistent as possible-- in those domains. Can you, for instance, envision other uses of binary ~ beyond R? ___ 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/UMXBIM6TSOTR76KOBOJXGVJUDMX7IHBT/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Incremental step on road to improving situation around iterable strings
Greg Ewing wrote: > On 24/02/20 9:32 am, jdve...@gmail.com wrote: > > It is a common "pattern" in any languages to walk > > along strings, > > letter by letter. > > Maybe in some other languages, but I very rarely find myself doing > that in Python. There is almost always some higher level way of > doing what I want. Not talking about how frequent walking on strings is done. I just saying that most languages provide a "pattern" (say, a way) of looping on strings (via indexing, via iterators, etc.) So, most languages, in some manner, "use" strings as they are sequences of characters. Like Python does. Since Python has a sequence type, strings were modelled as character sequence-objects and so they behave. In your opinion, if strings should not be sequences in Python, what they should be? > > if strings are not longer sequences, how would > > Python do slicing on strings > > It's quite possible for a type to support slicing but not indexing. Yeah, of course... do you think that we need to change the current syntax and the underlying string model to accommodate slicing but not indexing? What are we going to gain and what are we going to lose? ___ 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/EMOJ6WYZA5F5QAFZ6CHQBFQ2IVGIS6TX/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Incremental step on road to improving situation around iterable strings
Alex Hall wrote: > > Strings already have an exception in this area. Usually x in y means > any(x == elem for elem in y). It makes the two meanings of in > match Actually, `in` means the same in strings, in sequences, in lists, etc. But, in Python's view, a string is composed of sub-strings, the smallest one being a character. So `in` looks for substrings and characters in strings. Looks strange to you? It is coherent with the nature of strings in Python. , and to me (I don't know if this is true) it's the reason that iterating over > dictionaries yields the keys, although personally I'd find it more convenient > if it > yielded the items. Oh, I think that dictionaries iterate over keys because you can get the associate item using the keys (not vice-versa). But, probably this is not the real reason. > Another somewhat related example: we usually accept that basically every > object can be > treated as a boolean, even more so of it has a __len__. But numpy and pandas > break this 'rule' by raising an exception if you try to treat an array as a > boolean, Well, I think that some objects (mainly implementing __bool__ and some related magic methods) can be evaluated as boolean. Of course, __bool__ and __len__ can be overridden and objects can refuse to be evaluated as boolean as you pointed out. I do not catch the analogy with str class... Every object, every class can be redefined in Python... > In a sense these libraries decided that while unambiguous behaviour could be > defined, > the intention of the user would always be ambiguous. The same could be said > for strings. > Needing to iterate over a string is simply not common unless you're writing > something like > a parser. So even though the behaviour is well defined and documented, when > someone tries > to iterate over a string, statistically we can say there's a good chance > that's not what > they actually want. Are you implying that developers are wrong when they iterate over strings? Seriously? Does it matter in any case? Strings must be defined in Python in some way. Immutable sequence strings was the choice. If they are sequences, they must behave as sequences. If they were foo objects, they must behave foo objects. The implementation, the syntax, and the semantics of strings are coherent in Python. If you want to change this, you must change the foundations of Python strings. We should not be wrong about this. Ultimately, it does matter how many people iterate on strings. That is not the question. > And in the face of ambiguity, refuse the temptation to guess. > I do think it would be a pity if strings broke the tradition of indexable > implies > iterable, but "A Foolish Consistency is the Hobgoblin of Little Minds". The > benefits in > helping users when debugging would outweigh the inconsistency and the minor > inconvenience > of adding a few characters. Users who are expecting iteration to work because > indexing > works will quickly get a helpful error message and fix their problem. At the > risk of > overusing classic Python sayings, Explicit is better than implicit. > However, we could get the benefit of making debugging easier without having > to actually > break any existing code if we just raised a warning whenever someone iterates > over a string. It doesn't have to be a deprecation warning and we don't need > to ever > actually make strings non-iterable. I do not agree at all. Every programming language makes a compromise. Languages are defined by what they do and what they do not. Python has chosen to be a immutable string sequence language and in my humble opinion it has been coherent with that choice. Other alternatives would be chosen, of course. But they were not. It is not a question of right or wrong, better or worse. It is a question of being consistent. And, I should say, Python is consistent in this particular point. > I'm out of time, so I'll just quickly say that I prefer .chars as a > property without the (). And jdveiga you asked what would be the advantage of > all this after I made my previous post about it biting beginners, I'm not > sure if you > missed that or you were just typing yours when I made mine. Yeah, I was typing and, yeah, I had answered you as soon as I saw your message. Sorry, but I do not agree with you once again ;-) ___ 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/FX5SMGSP5KPKGZG646TB6UYOJZ7JRD4J/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Incremental step on road to improving situation around iterable strings
Sebastian Berg wrote: > However, in the same code, often strings are actually not desired to be > handled as sequences. > I.e. some code uses strings as sequences of characters, but most code > probably uses the meaning that a string is a word, or sentence: the > individual character has no useful meaning on its own. Humm... It is not a matter of how often. It about the underlying type of strings and the derived behaviour. In Python, they are immutable sequences of characters. It does matter if you use them as characters, as words, as bibles... If you have a list of integers, does it behave differently if it contains a few countries' GDP, the songs in each Metallica's LPs, or the first two hundred primes? No, it does not. It is a list, a sequence, and you can deal with that list in the same ways as you can deal with a string sequence. Because they are both collections. This is fine in most cases and I like to know when it is not. > you make it a property rather than a function, you could think about > also forcing string.chars[0] in the first case. And once again... which is the superiority of strings.chars[0] over strings[0]? Maybe I am dumb, but I can see the difference. > Coming from NumPy, there is a subtle spectrum: > > strings are primarily scalars for which sequence behaviour > is well defined and often convenient > lists/tuples are typical collections/sequences > NumPy arrays are more element focused than most collections > (operators modify the elements not the container). > Nice point. However, we are talking about Python, not NumPy. A nice solution for NumPy is not necessary a good one for Python. You can list lots of languages and libraries which do differently than Python but... it does not matter! The question is different: is it right that Python string are immutable sequences or not? Should we change this or not? Sorry, but to the date, I do not see any (Python) example that proves that Python strings need a change like this. We can discuss endless about strings nature and essence but, in my opinion, we need to focus on real code, on real flaws. Thank for your comments. ___ 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/PE7Y4NNBVVNCF3KODF364RQGDCJG2EWG/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Incremental step on road to improving situation around iterable strings
Alex Hall wrote:
> I've also had to special case strings when dealing with iterables
> generically, and it's annoying, but it's not a big deal. The real problem
> is when you meant to pass an iterable of strings and you just passed a
> single string and it produces confusing behaviour - something more subtle
> than each character being laid out separately. And even this is not that
> hard for experienced devs like us to figure out, but it really bites
> beginners hard, and I think that's the argument worth focusing on.
> A common example is when beginners write code like this:
> cursor.execute('INSERT INTO strings VALUES (?)', 'hello')
>
> and get this confusing error:
> sqlite3.ProgrammingError: Incorrect number of bindings supplied. The
> current statement uses 1, and there are 5 supplied.
> Finding questions about these is pretty easy, below are some examples:
> https://stackoverflow.com/questions/54856759/sqlite3-programmingerror-incorr...
> https://stackoverflow.com/questions/16856647/sqlite3-programmingerror-incorr...
> https://stackoverflow.com/questions/6066681/python-sql-select-statement-from...
> https://stackoverflow.com/questions/33768447/incorrect-number-of-bindings-su...
> https://stackoverflow.com/questions/35560106/incorrect-number-of-bindings-su...
> https://stackoverflow.com/questions/58786727/incorrect-number-of-bindings-su...
> So first of all, I think we should probably have a check in the sqlite3
> library for passing a single string as a parameter.
> But in the general case, it would be great if strings weren't iterable and
> trying to iterate over them raised an exception with a helpful generic
> message, like:
> "Strings are not iterable - you cannot loop over them or treat them as a
> collection. Perhaps you meant to use string.chars(), string.split(), or
> string.splitlines()?"
`(3)` and `(3,)` are not the same and I think there is nothing wrong with
literal integers.
A library implemented in a confusing way is not an example of nothing wrong on
Python strings. (I myself has made this stupid mistake many times and I cannot
blame neither Python nor sqlite for being careless.)
In my humble opinion, your example does not prove that iterable strings are
faulty. They can be tricky in some occasions, I admit it... but there are many
tricks in all programming languages especially for newbies (currently I am
trying to learn Lisp... again).
___
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/74NAU7D5T4HYYXTE7LFYGZPBYB44F3KJ/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Incremental step on road to improving situation around iterable strings
Steve Jorgensen wrote: > > The only change I am proposing is that the iterability for characters in a > string be moved from the string object itself to a view that is returned from > a > chars() method of the string. Eventually, direct iteratability would be > deprecated and then removed. That sounds completely unnecessary to me. Can you provide any example on the superiority of your proposal (compared to current implementation)? Sorry, but I can see your point. Why do we need to convert a sequence in another sequence or sequence-like object? Where is the advantage? Or are you proposing that strings will not be sequences in Python any longer? Why? How? Are they going to be what? In my point of view, there is nothing wrong in modelling strings as sequence (or as lists like Lisp, or arrays like C). It has advantages and caveats... such as any alternative. However, I think that strings as immutable sequences of characters is a nice and efficient solution in Python context (like null-terminated arrays are in C). Really... you need to provide a example on what is wrong with strings in Python now and how you propose to solve that. ___ 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/MGSEB4WNSNQQADG5BZRHK5BILO22WY4P/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Incremental step on road to improving situation around iterable strings
Kyle Stanley wrote: > In order for this proposal to be seriously considered, I think it's > necessary to cite many realistic examples where the current behavior is > problematic enough to justify changing the current behavior, and that > adding a str.chars() and eventually removing the ability to iterate over > strings would provide a better fix than any existing solutions. Simply > stating that much of the Python community considers the current behavior to > be "somewhat problematic" based on previous suggestions is certainly not > going to be adequately convincing, at least not to me. > But, even in the case that we are able to conclude that the current > behavior causes significant issues that can't be addressed as well with > existing solutions, I strongly suspect that this is going to be the case of > change that is far too fundamental to Python to be changed at this point, > even with a distant deprecation warning and many years of advanced notice > regarding the removal/change after that. I agree. I can barely imagine what is wrong with Python's strings. Can you please provide any example? It is a common "pattern" in any languages to walk along strings, letter by letter. Python's strings provide a powerful way of doing it --as a sequence which is a fundamental type in the language. No need to dealing with indexes, terminators, lengths, boundaries, etc. I love Python because of this and hate C's and Java's strings. On the other hand, what about slices? Since slices operate in sequences and lists, if strings are not longer sequences, how would Python do slicing on strings according to your proposal? I think strings as immutable strings is indeed a wise implementation decision on Python. Thank 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/PETKSMJ7SH2SN7VGXIRNQW4DTFUUKD2P/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: PYTHONLOGGING env variable
Ok... Though some kind of logging configuration, even a default one, is always present. For example, when logging.info() module method --or some one similar-- is called for the first time, it creates a basic logger with a last resort handler if none exists --at least up to my knowledge. So automatic set up, but set up indeed. In any case... most important to me... I do not really know nothing about comprehensive logging. I made a search on web and on my books but does not find anything useful. Could you provide me any link or additional information on that matter, please? Thank 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/GLMJWTMZGOU3PKIUW756R4QS3VHOMPGX/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: PYTHONLOGGING env variable
So, are you suggesting that -L must create a basic logger with the given logging level? Is it right? It can work... ___ 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/NDKOGWMCCXUXL66QQM5XNLMCDYPSZIRJ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: PYTHONLOGGING env variable
Nice idea... in principle. But, what if my program has several loggers with several handlers each having its own logging info level? Would the Python's interpreter CLI argument (or the ENV variable) override all loggers and handlers logging levels? Why should CLI / ENV override those loggers and handlers? Ok... I know that the above-mentioned logging configuration is probably seldom used in real world... But logging module allows that kind of uses. For instance, in my case, I used to create a (root) logger with two handlers: a stream to stdout and log file. the stdout stream has a higher logging level (say, critical) than the log file (say, info) -- so most log records go to file while worst messages are also display in terminal. Additionally... if the logging level is changed by the program at some point, I think that the CLI / ENV logging level will become useless. Talking about me again, I used to create a logger with logging.getLogger and change immediately its logging level to the desired level with logger.setLevel. So, in my case, the CLI / ENV level would be overridden even before any log message was issued. Of course, most developers probably do not do that but... it can be done. Or not? Or are you suggesting a different approach? Are you suggesting that CLI / ENV would create an ex novo basicConfig logger (beyond program's loggers and handlers) and that all program's log messages would be sent to that CLI / ENV logger instead of (or also to) program's loggers? Thank 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/DAUVSZ56SRDWHDZGBDCP5CCE2IYBL2UX/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: SQL string prefix idea
May I suggest mark string with comments instead of populating the interpreter
with lost of "string" templates?
Something like
"SELECT * FROM table" # string: sql
Or
"spam ham eggs # template: html
IDEs can read this comment and highlight (and do some other static checks) on
the commented strings.
It can be easily combined with raw strings and f-strings such as:
f"{my_string} ham" # doctype: html
___
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/7FWPN7GFZNRQ7YCV35DJAOSL7XKXIFMM/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: PEP 572: Is it a good ideas that walrus operator can be used in assertions since it causes side effects?
Thank you for all your answers. They were all very instructive to me. However, after further investigation, I feel that I have made a mistake when putting this topic on the table. When walrus operator was discussed, it was proposed to restrict assignment expressions to if, elif, and while statements. That proposal was rejected. I realised now that that also applies, by analogy, to assert statement. So, sorry for taking this issue back. My apologies. I was not my intention to re-start any superseded debate. The walrus operator, as you know, has been —and will be— highly controversial and material on this matter is enormous. Reviewing all this material is a huge task that I should have done before speaking. Sorry again and thank 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/MACCFXXNIL3EDUAFR7ZVGK36B4I6SATO/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: PEP 572: Is it a good ideas that walrus operator can be used in assertions since it causes side effects?
Sorry, Soni, I do no speak Lua. Can you provide any documentation on that point? I have found a function called assert but I am not sure that it works like assertions in Python. ___ 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/A3CYE66PHTP3PSFD6GPGFA2EJQRH4GQL/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: PEP 572: Is it a good ideas that walrus operator can be used in assertions since it causes side effects?
Good point, Brandt. However, `global` is not used in the assertion itself as walrus operator can be. My point is: is it good to add a new way of causing side effects in assertions? Thank 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/NCQ7QNB7MGGJP5TSL2WRP2O2W4FXQP7G/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] PEP 572: Is it a good ideas that walrus operator can be used in assertions since it causes side effects?
Hi,
Recently the idea has come to me that walrus operator can have some issues when
use in assertions.
I have been taught that assertions must not produce side effects at all. This
is a problem in languages such as C. But not in Python (until 3.8) since it
does not allow assignment expressions. But now, for best or worst, we have the
walrus operator and a code like this is possible:
`python3.8 -c "assert (always := True); print(f'{always=}')"`
Which outputs:
```
always=True
```
since the assertion is always true.
However, if assertions are disabled:
`python3.8 -Oc "assert (always := True); print(f'{always=}')"`
it raises an exception:
```
Traceback (most recent call last):
File "", line 1, in
NameError: name 'always' is not defined
```
because of the side effect caused by the walrus operator.
Do not you think that disabling walrus operators in assertions would be a good
idea? Would be it possible?
Personally, I do not see many advantages in walrus operator (versus
disadvantages, of course). However, in the case of assertions, a nice and
secure feature of Python has been lost without any apparent benefit.
Thank 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/KJFG76RXMZ2YVNZ4WXYY4TTQWSDJSMGY/
Code of Conduct: http://python.org/psf/codeofconduct/
