[Python-ideas] Re: re.match(pattern, string, require=True)
The *re* module is a black swan, because most of stdlib raises exceptions on invalid arguments or not being able to deliver. It's impossible to change *re* now, so wrapping the calls should be the right solution. -- Juancarlo Añez mailto:apal...@gmail.com On Sun, Oct 22, 2023 at 5:19 AM Stephen J. Turnbull < turnbull.stephen...@u.tsukuba.ac.jp> wrote: > Chris Angelico writes: > > > Why create a new argument, then mandate that you use it everywhere, > > just to achieve what's already happening? > > "Newbies don't read code backwards very well" seems to be the > point. > > While I'm not of the school that "I learned this painfully, so newbies > should learn this painfully", I do think that novice Python > programmers should learn that > > 1. "None has no .xxx attribute" means that some previous code (often > but not always a regex match) was unable to perform some task > and returned None to indicate failure. > 2. If the failure was expectable, your code is buggy because it > didn't test for None, and if it was unexpected, some code > somewhere is buggy because it allowed an invariant to fail. > > On the cost side, there are so many cases where a more finely divided > Exception hierarchy would help novices quite a bit but experts very > little that this case (easy to learn) would open the floodgates. I > believe Guido has specifically advised against such a hierarchy. I'm > against this change. > > 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/MIE4OFPAG5CTNMUR7FYJSX66UMDHIH57/ > 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/QCKOSYRIFF4O27CUFIUV76NGPQYI4FQP/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Bringing the print statement back
On several functional languages that allow function invocations without
enclosing arguments in parentheses all functions take a single argument.
For multiple arguments the single argument is a tuple. For no arguments the
single argument is an empty tuple.
I've read the comments and I see more fear than dislike in them.
Because the feature is mostly implemented, I think it would be good to add
it to the language with a __future__ guard. Then the community as a whole
can evaluate the pros and cons.
I would implement the feature for *all* expressions (including
arguments/parameters).
--
Juancarlo Añez
mailto:apal...@gmail.com
On Tue, Jun 9, 2020 at 8:09 PM Guido van Rossum wrote:
> In Python 3.10 we will no longer be burdened by the old parser (though 3rd
> party tooling needs to catch up).
>
> One thing that the PEG parser makes possible in about 20 lines of code is
> something not entirely different from the old print statement. I have a
> prototype:
>
> Python 3.10.0a0 (heads/print-statement-dirty:5ed19fcc1a, Jun 9 2020,
> 16:31:17)
> [Clang 11.0.0 (clang-1100.0.33.8)] on darwin
> Type "help", "copyright", "credits" or "license" for more information.
> Cannot read termcap database;
> using dumb terminal settings.
> >>> print 2+2
> 4
> >>> print "hello world"
> hello world
> >>> print "hello", input("Name:")
> Name:Guido
> hello Guido
> >>> print 1, 2, 3, sep=", "
> 1, 2, 3
> >>>
>
> But wait, there's more! The same syntax will make it possible to call
> *any* function:
>
> >>> len "abc"
> 3
> >>>
>
> Or any method:
>
> >>> import sys
> >>> sys.getrefcount "abc"
> 24
> >>>
>
> Really, *any* method:
>
> >>> class C:
> ... def foo(self, arg): print arg
> ...
> >>> C().foo 2+2
> 4
> >>>
>
> There are downsides too, though. For example, you can't call a method
> without arguments:
>
> >>> print
>
> >>>
>
> Worse, the first argument cannot start with a parenthesis or bracket:
>
> >>> print (1, 2, 3)
> 1 2 3
> >>> C().foo (1, 2, 3)
> Traceback (most recent call last):
> File "", line 1, in
> TypeError: C.foo() takes 2 positional arguments but 4 were given
> >>> print (2+2), 42
> 4
> (None, 42)
> >>> C().foo [0]
> Traceback (most recent call last):
> File "", line 1, in
> TypeError: 'method' object is not subscriptable
> >>>
>
> No, it's not April 1st. I am seriously proposing this (but I'll withdraw
> it if the response is a resounding "boo, hiss"). After all, we currently
> have a bunch of complexity in the parser just to give a helpful error
> message to people used to Python 2's print statement:
>
> >>> print 1, 2, 3
> File "", line 1
> print 1, 2, 3
> ^
> SyntaxError: Missing parentheses in call to 'print'. Did you mean print(1,
> 2, 3)?
> >>>
>
> And IIRC there have been a number of aborted attempts at syntactic hacks
> to allow people to call functions (like print) without parentheses,
> although (I think) none of them made it into a PEP. The PEG parser makes
> this much simpler, because it can simply backtrack -- by placing the
> grammar rule for this syntax (tentatively called "call statement") last in
> the list of alternatives for "small statement" we ensure that everything
> that's a valid expression statement (including print() calls) is still an
> expression statement with exactly the same meaning, while still allowing
> parameter-less function calls, without lexical hacks. (There is no code in
> my prototype that checks for a space after 'print' -- it just checks that
> there's a name, number or string following a name, which is never legal
> syntax.)
>
> One possible extension I didn't pursue (yet -- dare me!) is to allow
> parameter-less calls inside other expressions. For example, my prototype
> does not support things like this:
>
> >>> a = (len "abc")
> File "", line 1
> a = (len "abc")
> ^
> SyntaxError: invalid syntax
> >>>
>
> I think that strikes a reasonable balance between usability and reduced
> detection of common errors.
>
> I could also dial it back a bit, e.g. maybe it's too much to allow
> 'C().foo x' and we should only allow dotted names (sufficient to access
> functions in imported modules and metho
[Python-ideas] Re: Power Assertions: Is it PEP-able?
If assertions have an associated block, then `pdb` can be invoked within. I
almost never use debuggers, so I don't remember, but I think a recent
Python version introduced the likes of `debug()` to step into the
pre-configured debugger.
About the "power assertions" proposal in this thread, once everything is in
place to produce the output as proposed, then libraries may come in to
produce different output formats.
My personal preference is for a form of assertions that don't go away, ever.
Regarding the syntax, I think that should be the last part of the design.
If you think about it, a block associated with the assert should execute
when the assertion fails, so maybe it should be something like:
*assert* *cond* *else:* *block*
with an AssertionError raised if *"block"* does not raise.
Another proposal out there that has the same semantics is:
*unless* *cond*: *block*
Yet I find that using a negative keyword makes things ugly. I'd rather
stick to "*assert*", or maybe go for "*invariant*" statement, to be rid of
the legacy of the meaning of *"assert"* in Python's history.
*invariant* *cond*: *block*
After all, I think it's invariants what I've been after in my recent posts.
It's easy to document that the *"cond"* must be cheap because it will
*_always_* be executed, and that the *"block"* can be as complex as
required by the severity of the failure.
I still think that there's different levels of criticality to failed
assertions, and that an exception hierarchy that has levels can help build
more reliable systems.
On Tue, Sep 14, 2021 at 5:52 PM Finn Mason wrote:
> I think that this is a great idea. However, pipes only point to one
> character, which can be confusing. (Citation: many tracebacks before 3.10.)
>
> I'm wondering: Could failed assertions step you into `pdb`, if they are
> used for testing purposes? Could there be a way to specify different levels
> of assertions? For example, maybe certain assertions are turned off with -O
> or -OO, others turned off only with -O, and some that never are?
> There are lots of ways `assert` could be improved, and the question is
> how? What is/are the best way(s)?
>
> --
> Finn Mason
>
> On Mon, Sep 13, 2021, 5:36 AM Juancarlo Añez wrote:
>
>> What about asserts that are not used for testing, but as classic “unless
>>> there’s a bug, this should hold”?
>>
>>
>> To me this relates to the thread about having a structured *assert* that
>> doesn't go away with *-O*.
>>
>> My purpose when addressing *assert* was precisely the *“unless there’s a
>> bug, this should hold”* kind of assertions.
>>
>> In that context, introducing additional yet known costs (as in this
>> "power" idea), providing for different exception types (maybe all
>> descending from AssertError?), and allowing for a block to prepare the
>> exception, are all worth it.
>>
>> Introducing the new syntax for *assert* would imply zero cost for
>> existing assertions.
>>
>> On Sun, Sep 12, 2021 at 10:28 AM Guido van Rossum
>> wrote:
>>
>>> This is cool.
>>>
>>> AFAIK pytest does something like this. How does your implementation
>>> differ?
>>>
>>> What is your argument for making this part of the language? Why not a
>>> 3rd party library?
>>>
>>> What about asserts that are not used for testing, but as classic “unless
>>> there’s a bug, this should hold”? Those may not want to incur the extra
>>> cost.
>>>
>>> —Guido
>>>
>>> On Sun, Sep 12, 2021 at 07:09 wrote:
>>>
>>>> Hi all,
>>>>
>>>> I’d like your comments and feedback on an enhancement that introduces
>>>> power assertions to the Python language.
>>>>
>>>> Proposal
>>>>
>>>> This feature is inspired by a similar feature of the Groovy
>>>> language[1], and is effectively a variant of the `assert` keyword.
>>>> When an assertion expression evaluates to `False`, the output shows not
>>>> only the failure, but also a breakdown of the evaluated expression from the
>>>> inner part to the outer part.
>>>>
>>>> For example, a procedure like:
>>>> ```python
>>>> class SomeClass:
>>>> def __init__(self):
>>>> self.val = {'d': 'e'}
>>>>
>>>> def __str__(self):
>>>> return str(self.val)
>>>>
>>>> sc = SomeClass()
>>>>
>>>> assert sc.val['d'] == &#
[Python-ideas] Re: Power Assertions: Is it PEP-able?
gt;> >> [1] >> http://docs.groovy-lang.org/next/html/documentation/core-testing-guide.html#_power_assertions >> [2] >> https://browncoat-ninjas.github.io/nimoy/examples/#power-assertions-beta >> [3] https://github.com/browncoat-ninjas/nimoy/ >> [4] >> https://github.com/browncoat-ninjas/nimoy/blob/develop/nimoy/ast_tools/expression_transformer.py#L77 >> [5] >> https://github.com/browncoat-ninjas/nimoy/blob/develop/nimoy/assertions/power.py >> ___ >> 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/T26DR4BMPG5EOB3A2ELVEWQPYRENRXHM/ >> Code of Conduct: http://python.org/psf/codeofconduct/ >> > -- > --Guido (mobile) > ___ > 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/EEVHXKWUMVSEPAR73WOBQM3BO7NESPBZ/ > Code of Conduct: http://python.org/psf/codeofconduct/ > -- Juancarlo *Añez* ___ 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/RHXMGHUXNSHJTDBNAI3ZQGWZXN2TDFLN/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Different exceptions for assert
Steve, I've seen *unless* discussed and rejected before, but it is a good enough syntax for the purpose of asserting invariants, and it should be useful for other purposes (because it has been proposed before). The semantics are clear, and the implementation is simple with the new Python parser shortcutting to an "*if not"*. I do really like this option. On Sun, Sep 12, 2021 at 1:46 AM Steven D'Aprano wrote: > On Sat, Sep 11, 2021 at 02:30:10PM -0400, Juancarlo Añez wrote: > > > *invariant* cond: etc > > A software invariant is still an assertion. > > In another post, I semi-suggested a new (soft) keyword: > > unless condition: > # block > raise Exception > > But really, it's just an "if not". > > if not condition: > unless condition: > assert condition: > > are all exactly the same amount of typing. It's not clear that learning > a new keyword `unless` is more readable than just using `if not`. > > I think it might work better in languages that attempt to follow natural > language (e.g. XTalk languages) than one like Python with a relatively > minimal amount of syntax. But it is clear to me that using `assert` for > non-assertions is misleading. > > -- > 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/ERBJUTXNAVALGUGDPC7EHQT3LUP3NQHB/ > Code of Conduct: http://python.org/psf/codeofconduct/ > -- Juancarlo *Añez* ___ 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/3GOYGFSNKEGVB2NFC6MT5C2U7KNS3UEG/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Different exceptions for assert
David,
It seems I didn't state clearly enough my original statement, which is that
software will *_always_ *fail, even because of faulty hardware components,
or cosmic rays.
For software to be resilient, it must assert it's expected state.
But that doesn't have to be with the *assert* statement, perhaps less so
when the Python tradition is that those go away with just a "-O".
I won't vouch for an *"invariant"* statement, because that's probably too
much to ask for.
So I'll just use *"if"* to assert more invariants in the code I write.
Cheers,
On Sat, Sep 11, 2021 at 2:05 PM David Mertz, Ph.D.
wrote:
> On Sat, Sep 11, 2021 at 9:20 AM Juancarlo Añez wrote:
>
>> I'm happy about dropping the DBC theme and rebooting to make *assert* easier
>> to use so it gets used more.
>>
>
> I agree with Steven, Marc-Andé, and others in seeing "using assertions
> more" as an anti-goal.
>
> This isn't to say that a given program should have fewer—nor more—lines
> that start with `assert`. Rather, assertions should be use to ASSERT
> conditions that should NEVER be violated. They are NOT to check whether
> user input is bad. Nor whether a disk is unreliable. Nor whether a
> computation takes too long. Nor whether a value is outside of a useful
> range. Nor any of the other things that regular exception handling is well
> designed for.
>
> If for some reason you find yourself completely unable to write "if not
> (condition_to_check): ..." for mysterious reasons, you could use assert
> this way (but don't):
>
> >>> try:
> ... assert 2+2==5, "Bad arithmetic"
> ... except AssertionError:
> ... print("Configuring stuff to log problem")
> ... raise
> ...
> Configuring stuff to log problem
> Traceback (most recent call last):
> File "", line 2, in
> assert 2+2 == 5, "Bad arithmetic"
> AssertionError: Bad arithmetic
>
> But again, that's bad code for the same reason your proposal would be bad
> code. Assertions have the entire purpose of being possible to disable, and
> to express conditions a programmer believes are *necessarily true*.
>
>
> --
> Keeping medicines from the bloodstreams of the sick; food
> from the bellies of the hungry; books from the hands of the
> uneducated; technology from the underdeveloped; and putting
> advocates of freedom in prisons. Intellectual property is
> to the 21st century what the slave trade was to the 16th.
>
--
Juancarlo *Añez*
___
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/CWNOAP4UF7ECVMOXPJQQICEZPIDA576V/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Different exceptions for assert
Marc-Andre, I must agree that the current state of assertions with "-O" and "-OO" is difficult to impossible to change. Perhaps I'm looking for an: *invariant* cond: etc Regards, On Sat, Sep 11, 2021 at 11:00 AM Marc-Andre Lemburg wrote: > On 11.09.2021 15:17, Juancarlo Añez wrote: > > Of course, none of this will make sense to programmers with a strong > belief that > > assertions must always be turned off in production runs. > > You seem to be missing that the Python optimize mode turns off > all code which is related to debugging (__debug__ is set to False, > the compiler doesn't generate code for "if __debug__: ..." statements). > > assert is just one of the instances where this happens: > > > https://docs.python.org/3/reference/simple_stmts.html#grammar-token-assert-stmt > > asserts are meant to help find bugs in programs, not check for > user input errors. They document assumptions a programmer has made > when writing the code, which are then tested with a test suite to > make sure the assumptions hold as invariants of the application. > > For anything which can go wrong at production run-time, please use > normal if-statement checks and raise appropriate exceptions. > > Using assert in such cases is dangerous and can render your > application broken, while everything appears to be running fine > when testing. > > Unlike regular if-statement checks, asserts are meant to never > trigger an exception in production code -- which is why they > are removed with -O. > > This is not about whether or not to use -O in production environments, > it's about preventing user input exceptions from going unnoticed > when code is run with -O (e.g. the deployment team or a user > decided to always use -O in production). > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Experts (#1, Sep 11 2021) > >>> 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/ > > -- Juancarlo *Añez* ___ 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/TEV4XSLWV4IU3TD2KDDVZEKJYPFUDELS/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Different exceptions for assert
It's fair to note that complex arguments to assertions can be hacked with:
*assert* cond, (
f'{conputesomething} {and more}'
f''{some more}'
)
The exception type can't be changed, though.
On Sat, Sep 11, 2021 at 9:17 AM Juancarlo Añez wrote:
> Stephen,
>
> Assertions have their roots in mathematics, as does most everything in
> programming languages.
>
> I'm happy about dropping the DBC theme and rebooting to make *assert* easier
> to use so it gets used more.
>
> I liked the suggestion of:
>
> *assert *cond:
>
> # prepare failure information
>
> *raise *ExType(args)
>
>
> Because the current:
>
> *assert *cond, arg
>
>
> Will always raise AssertionError, and do a str(arg), which means that
> *arg* must be simple, or rely on a function that creates more complex
> reporting.
>
> It think it would be fine if ExtType->AssertionError is enforced. Then
> there could be a hierarchy of AssertionError depending on the type of
> problem or its severity.
>
> Of course, none of this will make sense to programmers with a strong
> belief that assertions must always be turned off in production runs.
>
> I, on the other hand, believe that any complex computation or algorithm
> should assert its expected state and abort if the expectations are not met,
> even when the reason for the failure is unknown. Think about financial,
> insurance, transportation, or medical algorithms.
>
> By epistemological reasons a failure caused by a bug is almost *_always_*
> unexpected,
> and the reasons for the failure are unknown at runtime (a shorter version
> is that "programmers don't write bugs on purpose, so bugs are always
> unforseen").
>
>
> On Sat, Sep 11, 2021 at 12:32 AM Stephen J. Turnbull <
> stephenjturnb...@gmail.com> wrote:
>
>> Juancarlo A�+Pez writes:
>> > assert cond:
>> > # Write some debugging info to a log.
>> > ...
>> > raise ExtType(args)
>> >
>> > I like the idea of preparing the arguments for the assertion message
>> in a
>> > context that gets executed only when the assertion fails.
>>
>> The more I see this elaborated, the less I like it. "assert" has a
>> traditional meaning in programming, which is only a slight extension
>> on the English meaning (that you can turn the check off for
>> performance).
>>
>> Although the idea that assert could be the fundamental building block
>> for design-by-contract (DBC), to my mind this has three problems.
>>
>> (1) You're coopting a keyword that has a consistent established
>> meaning in English, in programming languages in general, and in
>> Python, and changing that meaning.
>>
>> (2) I doubt that "assert" alone is sufficient for DBC. In practice,
>> you'll want a more expressive, larger vocabulary. It's not clear
>> that *any* of that vocabulary is best expressed by "assert" at
>> this point. If not, why mess with what works?
>>
>> (3) There's a subtle difference between an assertion and a contract.
>> An assertion is a statement of fact: it's either right or it's
>> wrong. But the whole point of contracts in the real world is that
>> they are constraints on behavior to be enforced. The assumption
>> is that it's possible to be in violation of the contract. The
>> point of *asserting* something is that you believe it's absolutely
>> true, there's no point in going on if it's false. You have to
>> start over.
>>
>> A presumption that violation is possible may not be true of the
>> contracts in DBC, I don't know. But I would prefer not to mix the
>> difficulties of the semantics of "contract" with the simplicity of
>> the semantics of "assert".
>>
>> Steve
>>
>>
>
> --
> Juancarlo *Añez*
>
--
Juancarlo *Añez*
___
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/BUX2AHAJRPKOX2MTNEK4IOP5V3TH7JJW/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Different exceptions for assert
Stephen, Assertions have their roots in mathematics, as does most everything in programming languages. I'm happy about dropping the DBC theme and rebooting to make *assert* easier to use so it gets used more. I liked the suggestion of: *assert *cond: # prepare failure information *raise *ExType(args) Because the current: *assert *cond, arg Will always raise AssertionError, and do a str(arg), which means that *arg* must be simple, or rely on a function that creates more complex reporting. It think it would be fine if ExtType->AssertionError is enforced. Then there could be a hierarchy of AssertionError depending on the type of problem or its severity. Of course, none of this will make sense to programmers with a strong belief that assertions must always be turned off in production runs. I, on the other hand, believe that any complex computation or algorithm should assert its expected state and abort if the expectations are not met, even when the reason for the failure is unknown. Think about financial, insurance, transportation, or medical algorithms. By epistemological reasons a failure caused by a bug is almost *_always_* unexpected, and the reasons for the failure are unknown at runtime (a shorter version is that "programmers don't write bugs on purpose, so bugs are always unforseen"). On Sat, Sep 11, 2021 at 12:32 AM Stephen J. Turnbull < stephenjturnb...@gmail.com> wrote: > Juancarlo A�+Pez writes: > > assert cond: > > # Write some debugging info to a log. > > ... > > raise ExtType(args) > > > > I like the idea of preparing the arguments for the assertion message in > a > > context that gets executed only when the assertion fails. > > The more I see this elaborated, the less I like it. "assert" has a > traditional meaning in programming, which is only a slight extension > on the English meaning (that you can turn the check off for > performance). > > Although the idea that assert could be the fundamental building block > for design-by-contract (DBC), to my mind this has three problems. > > (1) You're coopting a keyword that has a consistent established > meaning in English, in programming languages in general, and in > Python, and changing that meaning. > > (2) I doubt that "assert" alone is sufficient for DBC. In practice, > you'll want a more expressive, larger vocabulary. It's not clear > that *any* of that vocabulary is best expressed by "assert" at > this point. If not, why mess with what works? > > (3) There's a subtle difference between an assertion and a contract. > An assertion is a statement of fact: it's either right or it's > wrong. But the whole point of contracts in the real world is that > they are constraints on behavior to be enforced. The assumption > is that it's possible to be in violation of the contract. The > point of *asserting* something is that you believe it's absolutely > true, there's no point in going on if it's false. You have to > start over. > > A presumption that violation is possible may not be true of the > contracts in DBC, I don't know. But I would prefer not to mix the > difficulties of the semantics of "contract" with the simplicity of > the semantics of "assert". > > Steve > > -- Juancarlo *Añez* ___ 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/2EETNAKNLL3U3IMCHCYTWR7G5XA2NIUL/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Different exceptions for assert
assert cond: # Write some debugging info to a log. ... raise ExtType(args) I like the idea of preparing the arguments for the assertion message in a context that gets executed only when the assertion fails. On Thu, Sep 9, 2021 at 7:16 PM MRAB wrote: > On 2021-09-09 22:31, Juancarlo Añez wrote: > > Well, if the idea makes sense, then I'm certain that we'll have a very > > long and productive discussion about the best syntax here (re: *:=*). > > > > ;-) > > > > For backwards compatibility and no surprises: > > > > > > *assert: *ExType, cond, args > > > > > > It doesn't break anything, ExtType defaults to AssertionError, and > > linters can check that /args/ match ExType. > > > > A more readable and pythonic syntax would be: > > > > *assert *cond: ExtType(args) > > > > > Or, perhaps: > > assert cond: raise ExtType(args) > > That would make it more like an if and would leave open the possibility > of extending it to accept multiple lines: > > assert cond: > # Write some debugging info to a log. > ... > raise ExtType(args) > > Just a thought. > > > Forgoing the comma doesn't break anything, linters can check the > > ExType() typing, and the semantics would be those of: > > > > *if* __debug__ *and* *not *cond: > > > > *raise* ExType(args) > > > > > > Although I would drop the check for /__debug__/ if an explicit ExtType > > is given. > > > > It's similar to the changes introduced for: > > > > > > *except* (OneEx, TwoEx): > > > > > > On Thu, Sep 9, 2021 at 12:16 PM Guido van Rossum > <mailto:gu...@python.org>> wrote: > > > > Ooh, that’s a nice idea. If the message is an exception instance, > > raise it instead of AssertionError. Unfortunately it’s not 100% > > backwards compatible. We could address that with the syntax > > > >assert cond, raise=ExcType(args) > > > > Maybe we could deprecate the case > > > >assert cond, ExcType(args) > > > > So that eventually the raise= keyword can become optional. > > > > —Guido > > > > On Thu, Sep 9, 2021 at 09:04 Juancarlo Añez > <mailto:apal...@gmail.com>> wrote: > > > > Steven, > > > > The purpose is to make it easier to make software more resilient. > > > > The inspiration was this article that reminded me that software > > /_will always fail_/, and also reminded me about all the > > discussions around DBC and Eiffel: > > > > https://www.youtube.com/watch?v=AaZ_RSt0KP8 > > <https://www.youtube.com/watch?v=AaZ_RSt0KP8> > > > > > > IOW, my premise is that we should be using /_lots_/ of > > assertions, /_always_/, and that for that we need to make them > > easier to write, and easier to handle in the event of the > > unavoidable failures. Seeking unit-test coverage is not enough > > because unit tests don't run in production. > > > > I will concede that code written under the /"Python culture"/ > > tends to be resilient because the semantics of defaults and > > border conditions are explicit in the documentation, and > > implemented thus. > > > > Perhaps it's enough to allow for: > > > > *assert */cond/*, *ExType(args) > > > > > > > > On Tue, Sep 7, 2021 at 9:28 PM Steven D'Aprano > > mailto:st...@pearwood.info>> wrote: > > > > On Tue, Sep 07, 2021 at 11:12:37AM -0400, Juancarlo Añez > wrote: > > > I won't propose a syntax, but I think it would be useful > > if *assert* could > > > raise an exception different from *AssertionError*. > > > > > > This is in the context of "Design by contrast" (DBC) as a > > useful companion > > > to "Test-driven development" and other forms of external > > tests. > > > > I don't see why that would be useful. DBC assertions are > > assertions. You > > are *asserting* that a condition is always true. Since it is > > always > > true, it should be safe to disable those DBC assertion > >
[Python-ideas] Re: Different exceptions for assert
Christopher,
The *if* version has the condition inverted, and it's structure makes it
look as part of the algorithm, instead of an assertion over an invariant.
Following with the ideas on this thread, it would be possible for -OO to
turn off only assertions with exceptions that descend from AssertionError.
More on my answer to Steven
On Thu, Sep 9, 2021 at 12:35 PM Christopher Barker
wrote:
> Take a look at the archives of this list -- there was a large
> conversation about DBC a while back (a year, two years ??? )
>
> I think if you really want to support DBC, there will need to be more
> changes than this -- though there are libraries that support it with
> current Python.
>
> Also, let's be clear about hte language re use -- when you say:
>
> there should be lots of assertions, do you mean the english were
> assertion, or the Python keyword assert?
>
> If the former, than you are free, or course, to use a ordinary if and
> raise to make all sort sof assertions about the code at runtime.
>
> To me -- the entire point of the assert statement is that it is for
> testing, and can be turned off. If you want to check a condition always,
> just use an if and a raise:
>
> How is this:
>
> if value < 0:
> raise ValueError("this only works with positive numbers")
>
> Any more difficult to read or write than:
>
> assert value >= 0, raise ValueError("this only works with
> positive numbers")
>
> -CHB
>
>
>
>
>
>
>
>
>
>
> On Thu, Sep 9, 2021 at 9:05 AM Juancarlo Añez wrote:
>
>> Steven,
>>
>> The purpose is to make it easier to make software more resilient.
>>
>> The inspiration was this article that reminded me that software *_will
>> always fail_*, and also reminded me about all the discussions around DBC
>> and Eiffel:
>>
>> https://www.youtube.com/watch?v=AaZ_RSt0KP8
>>
>>
>> IOW, my premise is that we should be using *_lots_* of assertions,
>> *_always_*, and that for that we need to make them easier to write, and
>> easier to handle in the event of the unavoidable failures. Seeking
>> unit-test coverage is not enough because unit tests don't run in production.
>>
>> I will concede that code written under the *"Python culture"* tends to
>> be resilient because the semantics of defaults and border conditions are
>> explicit in the documentation, and implemented thus.
>>
>> Perhaps it's enough to allow for:
>>
>> *assert **cond**, *ExType(args)
>>
>>
>>
>> On Tue, Sep 7, 2021 at 9:28 PM Steven D'Aprano
>> wrote:
>>
>>> On Tue, Sep 07, 2021 at 11:12:37AM -0400, Juancarlo Añez wrote:
>>> > I won't propose a syntax, but I think it would be useful if *assert*
>>> could
>>> > raise an exception different from *AssertionError*.
>>> >
>>> > This is in the context of "Design by contrast" (DBC) as a useful
>>> companion
>>> > to "Test-driven development" and other forms of external tests.
>>>
>>> I don't see why that would be useful. DBC assertions are assertions. You
>>> are *asserting* that a condition is always true. Since it is always
>>> true, it should be safe to disable those DBC assertion checks once your
>>> software is in production.
>>>
>>> I could *maybe* see that having fine distinction between pre-condition,
>>> post-condition and invariant failures would be useful, but without a
>>> system in place to allow those to be globally enabled/disabled
>>> separately, what's the point?
>>>
>>> In any case, in the event of a contract failure, there's really nothing
>>> you can do except log the error and exit. Raising errors like TypeError
>>> etc will encourage people to abuse assertions and contracts by catching
>>> those exceptions, for checking caller-supplied parameters and user data,
>>> or for flow control.
>>>
>>>
>>> --
>>> 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/B4GZYQZEYBHCEZMB4GA2IK5GSNFOOE4P/
>>> Code of Conduct: http://python.org/psf/codeofconduct/
>>>
>>
>>
>> --
>> Juancarlo *Añez*
>> _
[Python-ideas] Re: Different exceptions for assert
Well, if the idea makes sense, then I'm certain that we'll have a very long and productive discussion about the best syntax here (re: *:=*). ;-) For backwards compatibility and no surprises: *assert: *ExType, cond, args It doesn't break anything, ExtType defaults to AssertionError, and linters can check that *args* match ExType. A more readable and pythonic syntax would be: *assert *cond: ExtType(args) Forgoing the comma doesn't break anything, linters can check the ExType() typing, and the semantics would be those of: *if* __debug__ *and* *not *cond: *raise* ExType(args) Although I would drop the check for *__debug__* if an explicit ExtType is given. It's similar to the changes introduced for: *except* (OneEx, TwoEx): On Thu, Sep 9, 2021 at 12:16 PM Guido van Rossum wrote: > Ooh, that’s a nice idea. If the message is an exception instance, raise it > instead of AssertionError. Unfortunately it’s not 100% backwards > compatible. We could address that with the syntax > > assert cond, raise=ExcType(args) > > Maybe we could deprecate the case > > assert cond, ExcType(args) > > So that eventually the raise= keyword can become optional. > > —Guido > > On Thu, Sep 9, 2021 at 09:04 Juancarlo Añez wrote: > >> Steven, >> >> The purpose is to make it easier to make software more resilient. >> >> The inspiration was this article that reminded me that software *_will >> always fail_*, and also reminded me about all the discussions around DBC >> and Eiffel: >> >> https://www.youtube.com/watch?v=AaZ_RSt0KP8 >> >> >> IOW, my premise is that we should be using *_lots_* of assertions, >> *_always_*, and that for that we need to make them easier to write, and >> easier to handle in the event of the unavoidable failures. Seeking >> unit-test coverage is not enough because unit tests don't run in production. >> >> I will concede that code written under the *"Python culture"* tends to >> be resilient because the semantics of defaults and border conditions are >> explicit in the documentation, and implemented thus. >> >> Perhaps it's enough to allow for: >> >> *assert **cond**, *ExType(args) >> >> >> >> On Tue, Sep 7, 2021 at 9:28 PM Steven D'Aprano >> wrote: >> >>> On Tue, Sep 07, 2021 at 11:12:37AM -0400, Juancarlo Añez wrote: >>> > I won't propose a syntax, but I think it would be useful if *assert* >>> could >>> > raise an exception different from *AssertionError*. >>> > >>> > This is in the context of "Design by contrast" (DBC) as a useful >>> companion >>> > to "Test-driven development" and other forms of external tests. >>> >>> I don't see why that would be useful. DBC assertions are assertions. You >>> are *asserting* that a condition is always true. Since it is always >>> true, it should be safe to disable those DBC assertion checks once your >>> software is in production. >>> >>> I could *maybe* see that having fine distinction between pre-condition, >>> post-condition and invariant failures would be useful, but without a >>> system in place to allow those to be globally enabled/disabled >>> separately, what's the point? >>> >>> In any case, in the event of a contract failure, there's really nothing >>> you can do except log the error and exit. Raising errors like TypeError >>> etc will encourage people to abuse assertions and contracts by catching >>> those exceptions, for checking caller-supplied parameters and user data, >>> or for flow control. >>> >>> >>> -- >>> 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/B4GZYQZEYBHCEZMB4GA2IK5GSNFOOE4P/ >>> Code of Conduct: http://python.org/psf/codeofconduct/ >>> >> >> >> -- >> Juancarlo *Añez* >> ___ >> 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/3HUS3M74VI2ECMOSGAN4QLLI3PZWXA3H/ >> Code of Conduct: http://python.org/psf/codeofconduct/ >> > -- > --Guido (mobile) > -- Juancarlo *Añez* ___ 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/O4LLILQJWNTS4JTTI2BUZ7CGLG4V3YMA/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Different exceptions for assert
Let me re-*assert* ;-) External tests will not be invoked at runtime, yet failures *_will_* occur at runtime because of a variety of environmental factors (including cosmic rays). Software should assert at least some of its preconditions, postconditions, and invariants. How can we make that easy and syntactically pleasant? On Thu, Sep 9, 2021 at 12:02 PM Juancarlo Añez wrote: > Steven, > > The purpose is to make it easier to make software more resilient. > > The inspiration was this article that reminded me that software *_will > always fail_*, and also reminded me about all the discussions around DBC > and Eiffel: > > https://www.youtube.com/watch?v=AaZ_RSt0KP8 > > > IOW, my premise is that we should be using *_lots_* of assertions, > *_always_*, and that for that we need to make them easier to write, and > easier to handle in the event of the unavoidable failures. Seeking > unit-test coverage is not enough because unit tests don't run in production. > > I will concede that code written under the *"Python culture"* tends to be > resilient because the semantics of defaults and border conditions are > explicit in the documentation, and implemented thus. > > Perhaps it's enough to allow for: > > *assert **cond**, *ExType(args) > > > > On Tue, Sep 7, 2021 at 9:28 PM Steven D'Aprano > wrote: > >> On Tue, Sep 07, 2021 at 11:12:37AM -0400, Juancarlo Añez wrote: >> > I won't propose a syntax, but I think it would be useful if *assert* >> could >> > raise an exception different from *AssertionError*. >> > >> > This is in the context of "Design by contrast" (DBC) as a useful >> companion >> > to "Test-driven development" and other forms of external tests. >> >> I don't see why that would be useful. DBC assertions are assertions. You >> are *asserting* that a condition is always true. Since it is always >> true, it should be safe to disable those DBC assertion checks once your >> software is in production. >> >> I could *maybe* see that having fine distinction between pre-condition, >> post-condition and invariant failures would be useful, but without a >> system in place to allow those to be globally enabled/disabled >> separately, what's the point? >> >> In any case, in the event of a contract failure, there's really nothing >> you can do except log the error and exit. Raising errors like TypeError >> etc will encourage people to abuse assertions and contracts by catching >> those exceptions, for checking caller-supplied parameters and user data, >> or for flow control. >> >> >> -- >> 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/B4GZYQZEYBHCEZMB4GA2IK5GSNFOOE4P/ >> Code of Conduct: http://python.org/psf/codeofconduct/ >> > > > -- > Juancarlo *Añez* > -- Juancarlo *Añez* ___ 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/PZMYE7KOWWILJPWEENNCFXVEQOWL3W7J/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Different exceptions for assert
Steven, The purpose is to make it easier to make software more resilient. The inspiration was this article that reminded me that software *_will always fail_*, and also reminded me about all the discussions around DBC and Eiffel: https://www.youtube.com/watch?v=AaZ_RSt0KP8 IOW, my premise is that we should be using *_lots_* of assertions, *_always_*, and that for that we need to make them easier to write, and easier to handle in the event of the unavoidable failures. Seeking unit-test coverage is not enough because unit tests don't run in production. I will concede that code written under the *"Python culture"* tends to be resilient because the semantics of defaults and border conditions are explicit in the documentation, and implemented thus. Perhaps it's enough to allow for: *assert **cond**, *ExType(args) On Tue, Sep 7, 2021 at 9:28 PM Steven D'Aprano wrote: > On Tue, Sep 07, 2021 at 11:12:37AM -0400, Juancarlo Añez wrote: > > I won't propose a syntax, but I think it would be useful if *assert* > could > > raise an exception different from *AssertionError*. > > > > This is in the context of "Design by contrast" (DBC) as a useful > companion > > to "Test-driven development" and other forms of external tests. > > I don't see why that would be useful. DBC assertions are assertions. You > are *asserting* that a condition is always true. Since it is always > true, it should be safe to disable those DBC assertion checks once your > software is in production. > > I could *maybe* see that having fine distinction between pre-condition, > post-condition and invariant failures would be useful, but without a > system in place to allow those to be globally enabled/disabled > separately, what's the point? > > In any case, in the event of a contract failure, there's really nothing > you can do except log the error and exit. Raising errors like TypeError > etc will encourage people to abuse assertions and contracts by catching > those exceptions, for checking caller-supplied parameters and user data, > or for flow control. > > > -- > 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/B4GZYQZEYBHCEZMB4GA2IK5GSNFOOE4P/ > Code of Conduct: http://python.org/psf/codeofconduct/ > -- Juancarlo *Añez* ___ 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/3HUS3M74VI2ECMOSGAN4QLLI3PZWXA3H/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Different exceptions for assert
I won't propose a syntax, but I think it would be useful if *assert* could
raise an exception different from *AssertionError*.
This is in the context of "Design by contrast" (DBC) as a useful companion
to "Test-driven development" and other forms of external tests.
Basically, the proposal is to allow for an exception type and value to be
specified in *assert*, instead of the customary:
if not assertion:
raise ValueError('a message')
Perhaps the assertion would not go away with *-OO* when an exception type
is specified?
>From my experience, assertions are useful in most non-trivial cases, and
should be there on any complex case. Perhaps we'd use more assertions if
they become easier to use and more customizable?
The agile trend has been in favor of external tests (like unit tests). I
think that we should not forget about the value of software that verifies
its state at runtime through assertions.
An SO reference to the basic inquiry:
https://stackoverflow.com/questions/1569049/making-pythons-assert-throw-an-exception-that-i-choose
--
Juancarlo *Añez*
___
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/KIREHCFXUS6Z7TCE7UBFNANQFEOHMHUB/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: What about having a .get(index, default) method for arrays like we have for dicts?
Hello!
Which would be the use cases for this feature?
I can't think of one.
I think that "nice to have" leads to the ways of Perl.
Regards,
On Sat, Jun 27, 2020 at 9:34 AM Daniel. wrote:
> When I need to traverse nested dicts, is a common pattern to do
>
> somedict.get('foo', {}).get('bar', {})
>
> But there is no such equivalent for arrays, wouldn't be nice if we can
> follow
>
> somedict.get('foo', {}).get('bar', []).get(10) ... ?
>
> What I do in this case is surround with try/except IndexError and set some
> variable to None, or wrap the try/except block in a function. But this is
> noise in my opinion, I just want to follow the same reasoning that I have
> with dicts: I'm searching for some path deep nested, and want a default if
> not found.
>
> What do you think?
>
> Regards
> --
> “If you're going to try, go all the way. Otherwise, don't even start. ..."
> Charles Bukowski
> ___
> 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/LLK3EQ3QWNDB54SEBKJ4XEV4LXP5HVJS/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
--
Juancarlo *Añez*
___
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/OAEFKC3MJNQ57ONGZPHY54CEKTMVGQEF/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: python -m quality of life improvements
> > The biggest difference is that scripts can't do relative imports. So > here's a counter-proposal: Allow "from . import modulename" to import > "modulename.py" from the directory that contains the script that > Python first executed (or, for interactive Python, the current > directory as Python started). > Understanding "script" as a free standing ".py"... I loved your suggestion because of it's convenience, but I worry it could be a security hole. I have scripts in ~/bin, in ./bin, and in ./scripts. And for ./scripts, it would be most useful if `from .. import` was allowed, so there was no more `import sys; sys.path.insert(0, '.'). I believe the above is addressed on a PEP (which number I don't remember). The discussion that has followed validates the OP's concern (even if the originally proposed solution is not right). It's hard to write scripts in Python that have access to the modules they intuitively should have access to, without patching (`sys.path.insert(...)` is awful) -- Juancarlo *Añez* ___ 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/UDG4GRHXQYXR4LYHEHP5EGEQAOECHZZC/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: python -m quality of life improvements
Hi Soni, For the last time, `python -m` takes a _module identifier_ as argument, not a path. For a module identifier to make sense, the `PYTHONPATH` must be set, or assumed. Remember that you're free to write your own `mypython` script which takes whatever arguments you want, with whatever actions you need. Cheers! On Sat, Jan 11, 2020 at 7:02 PM Soni L. wrote: > except I don't want to override PYTHONPATH. > > when you run a module with "python -m", it uses "." as one of the path > elements. when you run a script with "python" it *doesn't use "." as one of > the path elements*, instead replacing it with the path to the script. > > ideally "python -m" would also be able to check that you're running what > you think you're running. maybe "python -m module.submodule@/path"? and > then it'd check that "/path/module/submodule.py" or > "/path/module/submodule/__main__.py" exists. and use "/path" instead of "." > in the sys.path. > > I want a "python -m" clone with "python" semantics, basically. it makes > development easier all around. and "python -m" provides a much nicer > project structure than "python" IMO and I'd like to encourage ppl to switch > their "python" projects to "python -m" projects. > > On 2020-01-11 7:28 p.m., Juancarlo Añez wrote: > > Soni, > > Others have explained it already. `python -m` expects a _module_ as > parameter, and that module is searched by the rules `import` follows under > `PYTHONPATH`. > > What you're asking for is that `python` sets `PYTHONPATH` before executing > a module. Maybe another option to `python`? > > python -p /path/to -m foo > > > I would agree that would be nice. > > > > On Sat, Jan 11, 2020 at 6:07 PM Soni L. wrote: > >> why are we allowed to have fancy `python /path/to/foo.py` but not fancy >> `python -m /path/to/foo`? if `python` was capable of detecting modules and >> automatically deciding package roots, none of this would even be an >> argument and I'd just use `python /path/to/module/submodule/__main__.py` >> (with "module" having an __init__.py) and be done with it. but python can't >> do that because backwards compatibility and whatnot. >> >> so I propose we shove the solution into python -m instead. why's that so >> bad? it's simply ergonomics. >> >> On 2020-01-11 6:28 p.m., Juancarlo Añez wrote: >> >> Soni, >> >> Perhaps what you're looking for is available by writing a short Python >> program with a shebang? Then PYTHONPATH would be set to the directory of >> the program (many small projects include a `run.py` in the project's base >> directory). >> >> You can also place the program in ~/bin if it does `export PYTHONPATH`. >> >> Then, I have this alias for one of my home-brewed tools, and it works as >> I want: >> >> alias chubby='PYTHONPATH=~/chubby ~/.virtualenvs/chubby/bin/python -Oum >> chubby' >> >> >> I too think that the semantics of `python -m` are fine. >> >> On Sat, Jan 11, 2020 at 1:46 PM Soni L. wrote: >> >>> I just want python foo/bar/baz/qux/__main__.py but with imports that >>> actually work. -m works, but requires you to cd. -m with path would be >>> an more than huge improvement. >>> >>> and it absolutely should look for the given module in the given path. >>> not "anywhere in the PYTHONPATH". >>> >>> On 2020-01-11 2:21 p.m., Steven D'Aprano wrote: >>> > On Sat, Jan 11, 2020 at 11:27:51AM -0300, Soni L. wrote: >>> > >>> > > PYTHONPATH=foo/bar python -m baz.qux >>> > > >>> > > becomes >>> > > >>> > > python -m foo/bar/baz.qux >>> > > >>> > > which is less of a kludge. >>> > >>> > Sorry Soni, I completely disagree with you. >>> > >>> > The status quo `PYTHONPATH=foo/bar python -m baz.qux` is explicit about >>> > changing the PYTHONPATH and it uses a common, standard shell feature. >>> > This takes two well-designed components that work well, and can be >>> > understood in isolation, and plugging them together. The first part of >>> > the command explicitly sets the PYTHONPATH, the second part of the >>> > command searches the PYTHONPATH for the named module. >>> > >>> > Far from being a kludge, I think this is elegant, effective design. >&
[Python-ideas] Re: python -m quality of life improvements
Soni, Others have explained it already. `python -m` expects a _module_ as parameter, and that module is searched by the rules `import` follows under `PYTHONPATH`. What you're asking for is that `python` sets `PYTHONPATH` before executing a module. Maybe another option to `python`? python -p /path/to -m foo I would agree that would be nice. On Sat, Jan 11, 2020 at 6:07 PM Soni L. wrote: > why are we allowed to have fancy `python /path/to/foo.py` but not fancy > `python -m /path/to/foo`? if `python` was capable of detecting modules and > automatically deciding package roots, none of this would even be an > argument and I'd just use `python /path/to/module/submodule/__main__.py` > (with "module" having an __init__.py) and be done with it. but python can't > do that because backwards compatibility and whatnot. > > so I propose we shove the solution into python -m instead. why's that so > bad? it's simply ergonomics. > > On 2020-01-11 6:28 p.m., Juancarlo Añez wrote: > > Soni, > > Perhaps what you're looking for is available by writing a short Python > program with a shebang? Then PYTHONPATH would be set to the directory of > the program (many small projects include a `run.py` in the project's base > directory). > > You can also place the program in ~/bin if it does `export PYTHONPATH`. > > Then, I have this alias for one of my home-brewed tools, and it works as I > want: > > alias chubby='PYTHONPATH=~/chubby ~/.virtualenvs/chubby/bin/python -Oum > chubby' > > > I too think that the semantics of `python -m` are fine. > > On Sat, Jan 11, 2020 at 1:46 PM Soni L. wrote: > >> I just want python foo/bar/baz/qux/__main__.py but with imports that >> actually work. -m works, but requires you to cd. -m with path would be >> an more than huge improvement. >> >> and it absolutely should look for the given module in the given path. >> not "anywhere in the PYTHONPATH". >> >> On 2020-01-11 2:21 p.m., Steven D'Aprano wrote: >> > On Sat, Jan 11, 2020 at 11:27:51AM -0300, Soni L. wrote: >> > >> > > PYTHONPATH=foo/bar python -m baz.qux >> > > >> > > becomes >> > > >> > > python -m foo/bar/baz.qux >> > > >> > > which is less of a kludge. >> > >> > Sorry Soni, I completely disagree with you. >> > >> > The status quo `PYTHONPATH=foo/bar python -m baz.qux` is explicit about >> > changing the PYTHONPATH and it uses a common, standard shell feature. >> > This takes two well-designed components that work well, and can be >> > understood in isolation, and plugging them together. The first part of >> > the command explicitly sets the PYTHONPATH, the second part of the >> > command searches the PYTHONPATH for the named module. >> > >> > Far from being a kludge, I think this is elegant, effective design. >> > >> > It seems to me that your proposed syntax is the kludge: it mixes >> > pathnames and module identifiers into a complex, potentially >> > ambiguous "half path, half module spec" hybrid: >> > >> > foo/bar/baz.qux >> > * foo/bar/ is a pathname >> > * baz.qux is a fully-qualified module identifier, not a file name >> > >> > The reader has to read that and remember that even though it looks >> > exactly like a pathname, it isn't, it does not refer to the file >> > "baz.qux" in directory "foo/bar/". It means: >> > >> > * temporarily add "foo/bar/" to the PYTHONPATH >> > * find package "baz" (which could be anywhere in the PYTHONPATH) >> > * run the module baz.qux (which might not be qux.py) >> > >> > >> ___ >> 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/L7RRKAML6GWYXN4ULLD3U2ZOLS6CC4HM/ >> Code of Conduct: http://python.org/psf/codeofconduct/ >> > > > -- > Juancarlo *Añez* > > > -- Juancarlo *Añez* ___ 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/OSLZNG5JFZV3N7Y5C4TG35KQUUZNO2A2/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: python -m quality of life improvements
Soni, Perhaps what you're looking for is available by writing a short Python program with a shebang? Then PYTHONPATH would be set to the directory of the program (many small projects include a `run.py` in the project's base directory). You can also place the program in ~/bin if it does `export PYTHONPATH`. Then, I have this alias for one of my home-brewed tools, and it works as I want: alias chubby='PYTHONPATH=~/chubby ~/.virtualenvs/chubby/bin/python -Oum chubby' I too think that the semantics of `python -m` are fine. On Sat, Jan 11, 2020 at 1:46 PM Soni L. wrote: > I just want python foo/bar/baz/qux/__main__.py but with imports that > actually work. -m works, but requires you to cd. -m with path would be > an more than huge improvement. > > and it absolutely should look for the given module in the given path. > not "anywhere in the PYTHONPATH". > > On 2020-01-11 2:21 p.m., Steven D'Aprano wrote: > > On Sat, Jan 11, 2020 at 11:27:51AM -0300, Soni L. wrote: > > > > > PYTHONPATH=foo/bar python -m baz.qux > > > > > > becomes > > > > > > python -m foo/bar/baz.qux > > > > > > which is less of a kludge. > > > > Sorry Soni, I completely disagree with you. > > > > The status quo `PYTHONPATH=foo/bar python -m baz.qux` is explicit about > > changing the PYTHONPATH and it uses a common, standard shell feature. > > This takes two well-designed components that work well, and can be > > understood in isolation, and plugging them together. The first part of > > the command explicitly sets the PYTHONPATH, the second part of the > > command searches the PYTHONPATH for the named module. > > > > Far from being a kludge, I think this is elegant, effective design. > > > > It seems to me that your proposed syntax is the kludge: it mixes > > pathnames and module identifiers into a complex, potentially > > ambiguous "half path, half module spec" hybrid: > > > > foo/bar/baz.qux > > * foo/bar/ is a pathname > > * baz.qux is a fully-qualified module identifier, not a file name > > > > The reader has to read that and remember that even though it looks > > exactly like a pathname, it isn't, it does not refer to the file > > "baz.qux" in directory "foo/bar/". It means: > > > > * temporarily add "foo/bar/" to the PYTHONPATH > > * find package "baz" (which could be anywhere in the PYTHONPATH) > > * run the module baz.qux (which might not be qux.py) > > > > > ___ > 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/L7RRKAML6GWYXN4ULLD3U2ZOLS6CC4HM/ > Code of Conduct: http://python.org/psf/codeofconduct/ > -- Juancarlo *Añez* ___ 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/U45WS2ZNQ2JYZVSGYFYLHGYFZLUPMEJD/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Integrating Discourse and email for python-ideas
> > There are important and interesting discussions taking place both on Discourse (https://discuss.python.org) and on this email list (Mailman?). Discourse has email integration ( https://discourse.gnome.org/t/interacting-with-discourse-via-email/46). I prefer the rich-text and thorough threading provided by Discourse. Could we switch the email discussions to Discourse email? Has this been considered earlier and rejected? Cheers, -- Juancarlo *Añez* ___ 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/26OF3GV4TJV5QWPQ3OZRMO4AWAUOMV7U/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: findfirst() from findalliter(), and first
All your observations are on the mark, Andrew, so I went ahead and coded the patch against *cpython*. This is the (draft) pull request. https://github.com/python/cpython/pull/17735 I did not write new tests for *findalliter() *or *findfirst()*, because the correctness of *findalliter()* is implied by having *findall()* reimplemented in terms of it, and the correctness of *findfirst()* depends entirely on the correctness of *first()*, and *first()* is an ongoing discussion. Later I may try implementing *findalliter()* in C (move the core of *findall()* to within the outer of *finditer()*?) Cheers, On Sat, Dec 28, 2019 at 4:03 PM Andrew Barnert wrote: > On Dec 28, 2019, at 10:12, Juancarlo Añez wrote: > > > As far as I understand it, my implementation of *findalliter()* matches > the semantics in the *switch* statement. > > > There’s nothing outside the switch statement that converts PyNone values > to empty strings, so whatever the difference is, it must be inside the > switch statement. And, even though your control flow is the same, there are > two obvious ways in which you aren’t using the same input as the C code, so > the semantics aren’t going to be the same. > > The C code pulls values out of the pattern’s internal state without > building a match object. My guess is that this is where the difference > is—either building the match object, or somewhere inside the groups method, > unmatched groups get converted into something else, which the groups method > then replaces with its default parameter, which defaults to None, while the > C state_getslice function is just pulling a 0-length string out of the > input. But without diving into the code that’s just a guess. > > The C code also switches on the number of groups in the pattern (which I > think is exposed from the compiled pattern object?), not the number of > results in the current match. I’d guess that’s guaranteed to always be the > same even in weird cases like nested groups, so isn’t relevant here, but > again that’s just a guess. > > This is the matching implementation: > > for m in re.finditer(pattern, string, flags=flags): > g = m.groups() > if len(g) == 1: > yield g[0] > elif g: > yield tuple(s if s else '' for s in g) > else: > yield m.group() > > > Why not just call groups(default='') instead of calling groups() to > replace them with None and then using a genexpr to convert that None to ''? > > More importantly, you can’t return '', you have to return '' or b'' > depending on the type of the input string, using the same rule (whatever it > is) that findall and the rest of the module use. (I think that’s worked out > at compile time and exposed on the compiler pattern object, but I’m not > sure.) > > And even using a default with groups assumes I guessed right about the > problem, and that it’s the only difference in behavior. If not, it may > still be a hack that only sometimes gets the right answer and just nobody’s > thought up a test case otherwise. I think you really do need to go through > either the C code or the docs to make sure there aren’t any other edge > cases. > > Updated unit test: > > > Are there tests for findall and/or finditer in the stdlib test suite with > wide coverage that you could adapt to compare list(findalliter) vs. findall > or something? > > -- Juancarlo *Añez* ___ 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/35OMYLEM35PGFWCXMVGHHOJRXNXLNTKP/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: findfirst() from findalliter(), and first
oup
# no match
check('y', s)
check('(y)?.*(z)?.*(q)', s)
# empty matches
check('(a).*(y?).*(b)', s)
assert findfirst('y', s, default='THE DEFAULT') == 'THE DEFAULT'
s = 'xxxabxxx'
all_checks(s)
base = s
for i in range(2, 10):
s = base * i
g = re.findall('a', s)
assert len(g) == i
all_checks(s)
Cheers,
On Fri, Dec 27, 2019 at 5:37 PM Andrew Barnert wrote:
> > On Dec 27, 2019, at 09:00, Juancarlo Añez wrote:
> >
> >for m in re.finditer(pattern, string, flags=flags):
> >g = m.groups()
> >if len(g) == 1:
> >yield g[0]
> >elif g:
> >yield g
> >else:
> >yield m.group()
>
> I don’t think this does the same thing as findall in every case. For
> example, for capture groups that don’t participate in the match, you’ll get
> tuples like ('spam', None, '42'), when I’m pretty sure findall always has
> strings no matter what. I’m not sure exactly what the rule is for how it
> does that: maybe it’s just the same thing as m.groups(default='') would
> give you?
>
> At any rate, it seems like this isn’t as trivial to port from C as it
> looked, so this needs solid unit tests. (Maybe the ones for findall are
> already good enough if you just adapt them?)
>
> That’s also a great argument that it should be added to the re module, so
> people don’t have to try to figure out how to port C code to Python and
> then test the hell out of it just to get something that’s only missing in
> the first place for historical/naming reasons.
>
>
>
--
Juancarlo *Añez*
___
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/LGNZ7Q5VUYXHUOCSDID5FL6S5TNUABHR/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Fix statistics.median()?
The signature could be: def median(it, exclude=None): With *exclude* being a value, or collection supporting the *in* operator On Thu, Dec 26, 2019 at 4:14 PM David Mertz wrote: > Maybe we can just change the function signature: > > statistics.median(it, do_wrong_ass_thing_with_nans=False) > > :-) > > But yes, the problem is really with sorted(). However, the implementation > of statistics.median() doesn't HAVE TO use sorted(), that's just one > convenient way to do it. > > There IS NO right answer for `sorted([nan, 1, 2, 3])`. However, there is > a very plausibly right answer for `statistics.median([nan, 1, 2, 3])` ... > or rather, both 'nan' and '2' are plausible (one approach is what Numpy > does, the other is what Pandas does). > > -- > Keeping medicines from the bloodstreams of the sick; food > from the bellies of the hungry; books from the hands of the > uneducated; technology from the underdeveloped; and putting > advocates of freedom in prisons. Intellectual property is > to the 21st century what the slave trade was to the 16th. > ___ > 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/524SWHDA3HVPDIQ6F6S3OMFGFXPCVGLO/ > Code of Conduct: http://python.org/psf/codeofconduct/ > -- Juancarlo *Añez* ___ 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/TRN2MKZQ5RUHVWBVWG3VG5FBPNPPOCVF/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] findfirst() from findalliter(), and first
These are the implementations I added to my library: ```python def findalliter(pattern, string, flags=0): ''' like finditer(), but with return values like findall() implementation taken from cpython/Modules/_sre.c/findall() ''' for m in re.finditer(pattern, string, flags=flags): g = m.groups() if len(g) == 1: yield g[0] elif g: yield g else: yield m.group() def findfirst(pattern, string, flags=0, default=_undefined): """ Avoids using the inefficient findall(...)[0], or first(findall(...)) """ return first(findalliter(pattern, string, flags=flags), default=default) ``` Fon *first()*, maybe calling it *take_one()* will clear up misunderstandings about it's semantics. -- Juancarlo *Añez* ___ 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/2N34FIAA7WBKCI2BQZE2JJAIN5UQZNRC/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: __eq__ and __ne__
Hello, As I remember, __ne__ is implemented by default as *not *__eq__() in the base for hashable classes. Among the reasons to have a separate __ne__ may be implementation efficiency. Another is symmetry and completeness. Read the docs about the minimum a class must to do be: - hashable - sortable On Fri, Dec 27, 2019 at 12:00 PM Siddharth Prajosh wrote: > Why do we need separate functions for == and != ? > > Isn't this supposed to be negation of each other? > ___ > 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/5M6RJNN5V7JPNOR7MF5ZGTSH7VKFI33D/ > Code of Conduct: http://python.org/psf/codeofconduct/ > -- Juancarlo *Añez* ___ 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/5I2VVFGT5ELO3NGE3WURPKJ5SD44JENP/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Argumenting in favor of first()
> The argument that first(it) and next(it) "look the same" doesn't convince > me; if these look the same then all function applications look the same, > and that can certainly not have been Meertens' intention. But if everyone > thinks that first() should raise, fine, this thread is way too long already > (I should have kept it muted :-). > The reason why *first()* must raise is so it can be applied to iterables that may yield *None* as the legit, *first* value. I was after *findall(..)[0]* and other anti-patterns, but, I think that the semantics of *next(it)* cannot be changed to those of *next(iter(it))*, which is what solves most problems, so a new function is needed, one with the semantics of *more_itertools.first()*. As I said elsewhere, maybe it's just a matter of finding the right name, or of admitting that *more_itertools.first()* solved it first. It would be absurd for the docs to provide the source code to *more_itertools.first()* as a recipe, and also absurd to recommend including * more_itertools* in projects (stdlib Python must be self-containing/reliant). Yet! Just agreeing on what the recipe and use-cases in the docs for *itertools* should be would be a great step forward. -- Juancarlo *Añez* ___ 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/NKR5CWQ4VM24YTL43H6VJ4B5BPLECDIS/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Argumenting in favor of first()
> >take_one()? takeone()? take1()? > That could work. The docs can mention that for anything with ordering the result is guaranteed to be the *first* in the order. Do note that the main use case for the function is to consume only the first result of an iterable, generators in particular. In that context, *takeone()* sounds a lot like if any random result is fine. The docs can be simpler (less special cases) if it's called *first()* by just explaining that the result is *next(iter(it))* with provisions for non-yielding iterators and default return values. -- Juancarlo *Añez* ___ 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/MWWVRQFYVIRHDIHDIHGNK5DMAZSERVRY/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Fwd: Re: Argumenting in favor of first()
> > So while 1-arg next() and the try/except StopIteration pattern are > essential and well-known, 2-arg next() is relatively esoteric and > consequently (I think) not nearly as well-known. > And knowing that you must use *iter()* for 2-arg *next()* to (maybe) work right is idiosyncratic. It takes a "Python historian" to understand why it *may be correct* to use: the_first_item_if_ordered = next(iter(container), default='not found') While the semantics of *first()* (whichever the chosen implementation) are straightforward to explain: one_item_if_any = first(return_a_set(), default=-1) or: the_first_item = first(sorted(container)) I agree with others in that the "*default*" argument should be explicit instead of implied. It's how *dict.get()*, and *dict.pop()*, etc., work. The exceptions raised when nothing can be returned from *first()* and there is no *default=* should be the same. -- Juancarlo *Añez* ___ 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/TEFCNAFT2AOXVHQYUB6O6MVXGCQBTGAU/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Fwd: Re: Fwd: re.findfirst()
> > > > Well, match objects already accept subscripting as an alternative to > .group(), so: > > re.search(...)[0] > The semantics are not the same as those of: re.findall(...)[0] Subscripting a Match object will yield the match for a single group, which is always a string, while the first element in the list returned by *findall()* will be a tuple if several groups matched. As others have pointed out, there is an asymmetry in the library regarding Match-return and string/tuple-return functions, and that leads to *findal(...)[0].* -- Juancarlo *Añez* ___ 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/DZX7ICQBZWDZPOPPNUANLSHW2ECKQ7AH/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Fwd: Re: Fwd: re.findfirst()
My glitch. In my mind *finditer()* returned what *findall()*, but it returns *Match* objects. The implementation based on *search()*. Seems appropiate. I just looked in *_sre.c*, and *findall() *uses *search()* and is quite optimized. It seems that the good implementation would be to write a *findalliter()* using the current *findall()* code, and implement *findall() *and *findfirst()* by calling that. On Thu, Dec 5, 2019 at 10:31 PM Guido van Rossum wrote: > On Thu, Dec 5, 2019 at 6:16 PM Juancarlo Añez wrote: > >> It’s unfortunate that these functions aren’t better matched. Why is there >>> a simple-semantics find-everything and a match-semantics find-iteratively >>> and find-one? But I don’t think adding a simple-semantics find-one that >>> works by inefficiently finding all is the right solution. >>> >> >> The proposed implementation for *findfirst()* is: >> >> *return next(finditer(pattern, text, flags=flags), default=default)* >> >> > Um, finditer() returns a Match object, and IIUC findfirst() should return > a string, or a tuple of groups if there's more than one group. So the > actual implementation would be a bit more involved. Something like this, to > match findall() better: > > for match in re.finditer(pattern, text, flags=flags): > # Only act on first match > groups = match.groups() > if not groups: > return match.group(0) # Whole match > if len(groups) == 1: > return groups[0] # One match > return groups > # No match, use default > return default > > Alternatively, replace the first line with this: > > match = re.search(pattern, text, flags=flags) > if match is not None: > > (There are apparently subtle differences between re.search() and > re.findall() -- not sure if they matter in this case.) > > And if the point of proposing first is that novices will figure out how to >>> write first(findall(…)) so we don’t need to add findfirst, then I think we >>> need findfirst even more, because novices shouldn’t learn that bad idea. >>> >> > Yes, my point exactly. > > >> I posted another thread to argue in favor of *first()*, independently of >> *findfirst().* >> > > Also agreed, I've observed that as a common pattern. > > -- > --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-change-the-world/> > -- Juancarlo *Añez* ___ 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/IW7GVG2JL4RWVLPSCCSGUA5ULRZ3WLKP/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Fwd: Re: Fwd: re.findfirst()
> > It’s unfortunate that these functions aren’t better matched. Why is there > a simple-semantics find-everything and a match-semantics find-iteratively > and find-one? But I don’t think adding a simple-semantics find-one that > works by inefficiently finding all is the right solution. > The proposed implementation for *findfirst()* is: *return next(finditer(pattern, text, flags=flags), default=default)* > And if the point of proposing first is that novices will figure out how to > write first(findall(…)) so we don’t need to add findfirst, then I think we > need findfirst even more, because novices shouldn’t learn that bad idea. > I posted another thread to argue in favor of *first()*, independently of *findfirst().* -- Juancarlo *Añez* ___ 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/ISBWUONTALYR4JPS3F6ESB3KJBHGLRES/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Argumenting in favor of first()
I just found this code:
def get_product_item(jsonld_items):
for item in jsonld_items:
if item['@type'] == 'Product':
return item
else:
return {}
My argument is that the intent is clearer in:
def get_product_item(jsonld_items):
return first((item for item in jsonld_items if item['@type'] ==
'Product'), {})
As a reminder, first()'s definition in Python is:
def first(seq, default=None):
return next(iter(seq), default=default)
It could be optimized (implemented in C) if it makes it into the stdlib.
--
Juancarlo *Añez*
___
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/TVFD2RNRAU3SLHGMNQPBO4DHWFT274W3/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Fwd: Re: Fwd: re.findfirst()
On Wed, Dec 4, 2019 at 3:02 PM Guido van Rossum wrote: > Fair enough. I’ll let the OP defend his use case. > The OP thinks that the case for wanting just the string for a first regex match, or a verifiable default if there is no match, is way too common, that the advice on the web is not very good (it should be "write a findfirst() using next() over finditer()", and that novices default to using findall(..)[0], which is troublesome. The proposed implementation of a findfirst() would handle many common cases, and be friendly to newcomers (why do I need to deal with a Match object?), specially if the semantics are those of *findall()*: next(iter(findall(...)), default=default) BTW, a common function in extensions to *itertools* is *first():* def first(seq, default=None): return next(iter(seq), default= default) That function, *first()*, would also be a nice addition in *itertools*, and *findfirst()* could be implemented using it. *first()* avoids most use cases needing to check if a sequence or iterator is empty before using a default value. MHO is that *first()* deals with so many common cases that it should be a builtin. Note that the case for *findfirst()* is weaker if *first()* is available. Yet *findfirst()* solves the bigger problem. -- Juancarlo *Añez* ___ 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/M2OZCN5C26YUJJ4EXLIIXHQBGF6IM5GW/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Fwd: re.findfirst()
There are many ugly recipes about to handle the common use case that could be handled by: def findfirst(regex, text, default=None, flags=0): return next(finditer(regex, text, flags=flags), default=default) The matching and return value semantics would be the same as those of *re.findall()*, but the search would stop on the first match, or return "default" if there wasn't a match (*findfirst()* will return a tuple when more than one group is matched). Typically programmers will use: matched = re.findall(regex, text)[0] which is inefficient, and incorrect when there is no match. Typically, the pattern for the use case will be: m = re.search(regex, text) if m: matched = m.groups() else: matched = default nowadays: matched = m.groups() if (m := re.search(regex, text)) else default The semantics of *findall()* are nicer, and so would be those of *findfirst()*. -- Juancarlo *Añez* ___ 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/G4B4WHAAQLB3AFKL2EKXKZG3XLM673IW/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: A proposal (and implementation) to add assignment and LOAD overloading (was: (Re: Re: Overloading assignment concrete proposal (Re: Re: Operator as first class citizens -- like in s
>> It probably doesn't, this was just something I typed up on the fly, so is
>> unlikely the end result would be what you see above if it was actually
>> implemented.
>>
>> The only way around that that I can think of now would be if there was
>> two functions, an impl_dictget that actually did the lookup that type could
>> use (and possibly getattr and the like) which would be called in the normal
>> dict get which would just return if the type did not define __getself__ and
>> would call it and return the result if it did.
>>
>> This is not at all dissimilar to how dict setting works now
>>
>> On Fri, Jun 21, 2019, 9:27 PM Chris Angelico wrote:
>>
>>> On Sat, Jun 22, 2019 at 11:19 AM nate lust wrote:
>>> > Typing this out though does make me think of an interesting idea. If
>>> there was something like __getself__ in addition to __setself__, you could
>>> implement things like MyInt. __getself__ would look something like:
>>> >
>>> > class MyInt:
>>> > def __init__(self, value):
>>> > self.value = value
>>> > def __getself__(self):
>>> > return self.value
>>> > def __setself__(self, value):
>>> > raise ValueError("Cant set MyInt")
>>> > x = MyInt(2)
>>> > print(x) -> 2
>>> > type(x) -> MyInt
>>> >
>>> > Now I have not really thought through how this would work, if it could
>>> work...
>>>
>>> How does print know to call getself, but type know not to?
>>>
>>> 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/3734V62OHMJN3736PKWQ7IZ533TPM23J/
>>> Code of Conduct: http://python.org/psf/codeofconduct/
>>>
>>
>
> --
> Nate Lust, PhD.
> Astrophysics Dept.
> Princeton University
> ___
> 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/TMU3MJCDVNAHMJQAJUBIHRJXXLYMWSRH/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
--
Juancarlo *Añez*
___
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/IFLFKZDDFMX4O5PD2YKPZ6OPB372MWZP/
Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Syntax for allowing extra keys when unpacking a dict as keyword arguments
On Sat, Apr 13, 2019 at 9:02 AM Chris Angelico wrote:
> Would be really nice to be able to spell this as a dict/set intersection.
>
> func(**(d & {'a', 'b', 'c'}))
>
That would be _very_ consistent with the ongoing discussions about
operators over dicts.
--
Juancarlo *Añez*
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Syntax for allowing extra keys when unpacking a dict as keyword arguments
On Fri, Apr 12, 2019 at 11:10 AM Viktor Roytman
wrote:
>
> The standard approach I have encountered in this scenario is to pass in
> the keyword arguments explicitly like so
>
> func(
> a=kwargs_dict["a"],
> b=kwargs_dict["b"],
> c=kwargs_dict["c"],
> )
>
func(**{k:v for k, v in d.items() if k in ('a','b','c'))
Or you can `def dict_filter(d, yes)` to the the above.
--
Juancarlo *Añez*
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Python list of list matrixes without NumPy
On Sat, Apr 6, 2019 at 4:11 AM Steve Barnes wrote: > > ipython > > Python 3.6.5 (v3.6.5:f59c0932b4, Mar 28 2018, 17:00:18) [MSC v.1900 64 bit > (AMD64)] > > Type 'copyright', 'credits' or 'license' for more information > > IPython 7.2.0 -- An enhanced Interactive Python. Type '?' for help. > > > > In [1]: [[False]*2]*5 > > Out[1]: > > [[False, False], > > [False, False], > > [False, False], > > [False, False], > > [False, False]] > > # Looks like exactly what was wanted > [ins] In [1]: x = [[False]*2]*5 [ins] In [2]: x Out[2]: [[False, False], [False, False], [False, False], [False, False], [False, False]] [ins] In [3]: x[1][1] = True [ins] In [4]: x Out[4]: [[False, True], [False, True], [False, True], [False, True], [False, True]] -- Juancarlo *Añez* ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Python list of list matrixes without NumPy
The semantics of list operators are congruent, but unintuitive sometimes. For example, I've fallen over this many times: >>> truth_matrix = [[False] * n ] * m It doesn't create what you'd want. The only safe way I know to creat an NxM matrix is: >>> truth_matrix = [ [False for _ in range(n) for _ in range(m)] There could be a library to deal with that common case, and those of checking if a list of lists (of lists?) is properly rectangular, square, etc., and several other common cases. It takes experience to be aware that `truth_matrix[i][j]` will change more than one "cell" if the initialization is the former. `numpy` is not part of stdlib. A standard library for list of list would be usefu, specially to newcomersl. I don't remember such being discussed lately. >>> truth_matrix = lol(n, m, init=bool) >>> other_matrix = lol(n, m, o, p, init=float) Maybe it could also be done with syntax, but I don't have any ideas in that regard (I don't think "lol()" is overloaded). Regards, -- Juancarlo *Añez* ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Why not ['a','b','c'].join(',') ?
On Sun, Mar 24, 2019 at 5:11 AM Jonathan Fine wrote: > I'm willing to provide some useful information, if you're willing to write > it up into a good blog post. > ... or a PEP for rejection. Deal! -- Juancarlo *Añez* ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Why not ['a','b','c'].join(',') ?
I know it has been discussed endlessly, so just a gentle reminder about the final arguments would be good. I think I remember it was discussed recently, mentioning that join() doesn't convert elements to strings? This came up while reading this speculative article about how programmers migrate from one programming language to the other (I call it speculative because there's no hard data, but the conclusions and comments pretty much match my experience and my observations over decades [I would add an arrow from Python3 to Rust]). https://apenwarr.ca/log/20190318 In that sense, I think it wouldn't hurt to make Python more familiar/friendly to people coming from other languages, even if it breaks "There should be one-- and preferably only one --obvious way to do it." -- Juancarlo *Añez* ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] True and False are singletons
It came to my attention that: In the original PEP True and False are said to be singletons https://www.python.org/dev/peps/pep-0285/, but it's not in the Data Model https://docs.python.org/3/reference/datamodel.html This came to my attention by code wanting to own the valid values in a dict's key: if settings[MY_KEY] is True: ... If True and False are singletons in the spec (and not only in the CPython implementation), it should be prominent and well known. Cheers, -- Juancarlo *Añez* ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] PEP 8 update on line length
On Fri, Feb 22, 2019 at 5:10 PM Greg Ewing wrote: > I would say it the other way around. Once you've reduced the complexity > of a line to something a human can handle, *most* of the time 80 chars > is enough. > +1 It has been known for a very long time. These are *old *books that talk about *refactoring* (the word wasn't used then) of complex code (assigning subexpressions to variables, or extracting code into functions, reverting conditionals, etc.), not for line length, but for understandability, yet resulting nevertheless in much shorter lines: - Software Tools (also Software Tools in Pascal), Kernighan and Plauger, 1976 https://smile.amazon.com/Software-Tools-Brian-W-Kernighan/dp/020103669X - Code Complete (also the second edition), Steve Mc Connell, 1993, https://smile.amazon.com/Software-Tools-Brian-W-Kernighan/dp/020103669X I do make an exception in that after taking 8 spaces of indentation to write the implementation of a method in Python, the sweet spot is more around 100 chars. -- Juancarlo *Añez* ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Type hints for functions with side-effects and for functions raising exceptions
On Thu, Feb 21, 2019 at 11:32 PM Chris Angelico wrote: > On Fri, Feb 22, 2019 at 2:27 PM Juancarlo Añez wrote: > > Then, if exceptions are going to be part of a type, there should be a > way to express the semantics of them (like in Eiffel), so > stack.pop();stack.push(x) doesn't have to catch StackFullException. > > > > That assumes atomicity. If you want an atomic "replace top of stack" > that can never raise StackFullException, it's probably best to express > it as stack.replacetop(x) rather than having something that might be > interrupted. > Ah! What to do with an exception in a concurrent context? Abort, or retry after a while? > People do dumb things with exceptions, yes. Why does this mean that > they are bad? I don't understand this. Exception handling (and stack > unwinding) gives an easy and clear way to refactor code without having > to daisychain error handling everywhere. How is throwing that away > going to help people write better code? > For programs that are recursive or multi-layered, exceptions are a clean and efficient way to unwind. This PEG parser generator I wrote was made possible because Python exceptions are semantically clean and very efficient: https://github.com/neogeny/TatSu/blob/master/tatsu/contexts.py > But then, Golang also decided that Unicode wasn't necessary, and we > should all deal with UTF-8 encoded byte sequences instead of text > strings, so I'm fairly sure there are no ten foot barge poles long > enough for me to touch it with. There are languages that have problems > because of history (*cough*JavaScript*cough*), but for a new language > to make multiple poor decisions just means it's one to avoid. > The quest for a programming language in which _"anyone"_ can program, _without_ making mistakes, has never ended, and probably never will. "Alexa! Please write the software for a new Internet email system that overcomes the limitations of the current one!" Sometimes staying away is not an option. -- Juancarlo *Añez* ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Type hints for functions with side-effects and for functions raising exceptions
On Thu, Feb 21, 2019 at 10:34 PM Ben Rudiak-Gould
wrote:
> > It's well documented how checked exceptions lead to bad code.
>
> Please cite a paper. I know "everyone knows" that they're bad, but
> "everyone knows" a lot of things.
>
This is one of the original interviews touching why checked exceptions were
not made part of C#:
https://www.artima.com/intv/handcuffs.html
The problem is that a code fragment should only catch exceptions that it
expects, because it won't know what to do anything else but to wrap the
exception into one of the enclosing type.
But if every type has to define a SomethingWentWrongInTypeException wrapper
exception, it's logical that all of them inherit from a standard
SomethingWentWrongException. Having done that, the type-specific generic
exceptions are of no value, because any code wanting to guard against the
unexpected will just catch SomethingWentWrongException. And that brings us
back to square one, which is letting unexpected exceptions through to
wherever a clean shutdown or restart of the subsystem can be done.
Then, if exceptions are going to be part of a type, there should be a way
to express the semantics of them (like in Eiffel), so
stack.pop();stack.push(x) doesn't have to catch StackFullException.
In the end, I think that allowing type-hints about exceptions that may be
raised is quite useful, as long as they are not checked/enforced (in the
style of Java). Many times I've missed a PyCharm hint me about the actual
exceptions a given call may actually raise.
Newer languages like Go and Swift shy away from exceptions because of the
tendency to:
try:
# something
except:
print('oops!)
--
Juancarlo *Añez*
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Type hints for functions with side-effects and for functions raising exceptions
On Thu, Feb 21, 2019 at 6:28 PM Ivan Levkivskyi wrote: > The idea about "checked exceptions" appeared several times in various > places. I used to think that this would be hard to support for any > realistic use cases. But now I think there may be a chance > to turn this into a usable feature if one frames it correctly (e.g. the > focus could be on user defined exceptions, rather than on standard ones, > since there is no way we can annotate every function in typeshed). > It's well documented how checked exceptions lead to bad code. That's why C#, which came after Java, didn't include them. Exceptions may be logically thought as of part of the type of a method, and of the type of the method's class, but that requires that the type catches every exception that may be raised from the implementation and either handles it, or translates it to one belonging to the type. It's a lot of work, it's cumbersome, and it is fragile, as the exception handling may need to change over minor implementation changes. If dependencies don't treat the exceptions that may escape from them as part of the type, then our own types will need to be changes every time a dependency changes its implementation. The strategy of catching only exceptions of interest and letting others pass produces less fragile and easier to test code. -- Juancarlo *Añez* ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] [off-topic?] Unwinding generators
This is code from the Twisted library: https://github.com/twisted/twisted/blob/trunk/src/twisted/internet/defer.py#L1542-L1614 It "unwinds" a generator to yield a result before others. I don't have hard evidence, but my experience is that that kind of manipulation leaks resources, specially if exceptions escape from the final callback. Is there a bug in exception handling in the generator logic, or is unwinding just inherently wrong? How could the needs tried to solved with unwinding be handled with async? -- Juancarlo *Añez* ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Range and slice syntax
On Sun, Nov 11, 2018 at 6:00 AM Chris Angelico wrote:
> Be careful of this last one. If you omit the step, it looks like this:
>
> {start:stop}
>
> which is a dictionary display.
>
The parenthesis could always be required for this new syntax.
In [*1*]: {'a':1}
Out[*1*]: {'a': 1}
In [*2*]: {('a':1)}
File "", line 1
{('a':1)}
^
SyntaxError: invalid syntax
--
Juancarlo *Añez*
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] loop: statement
Thanks, Steven. Those links led to the complete discussions, including this one with a "loop:" keyword. https://mail.python.org/pipermail/python-ideas/2014-June/028202.html In short "while:" won't likely ever make it, and adding new keywords to Python only happens on a _absolute-need_ basis. On Sat, Oct 27, 2018 at 8:33 PM Steven D'Aprano wrote: > On Sat, Oct 27, 2018 at 07:37:32PM -0400, Juancarlo Añez wrote: > > > A `loop:` statement to replace `while True:` has probably been discussed > at > > length more than once. > > > > Does anyone keep links to the discussions? > > Google :-) > > This might get you started: > > > https://duckduckgo.com/?q=Mikhail+loop+site%3Ahttps%3A%2F%2Fmail.python.org%2Fpipermail%2Fpython-ideas > > I think Mikhail has raised the same question on the Python-List mailing > list, but the level of noise there is probably higher. > > This thread might also be relevant: > > https://mail.python.org/pipermail/python-ideas/2017-March/045344.html > > > -- > Steve > ___ > Python-ideas mailing list > Python-ideas@python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > -- Juancarlo *Añez* ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] loop: statement
A `loop:` statement to replace `while True:` has probably been discussed at length more than once. Does anyone keep links to the discussions? TIA! -- Juancarlo *Añez* ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Moving to another forum system where moderation is possible
> I propose Python register a trial of Stack Overflow Teams. Stack Overflow Teams is essentially your own private Stack Overflow. (I will address the private part later.) Proposals would be questions and additions or criticism would be answers. You can express your support or dissent of a proposal using the voting. Flags and reviews can be used to moderate. SO is for Q&A, not for discussions. I recently had good success at the company I work for with Discourse, the sister/brother software to SO, which is designed specifically for discussions. https://www.discourse.org On Tue, Sep 18, 2018 at 11:12 AM, Oleg Broytman wrote: > On Tue, Sep 18, 2018 at 04:48:18PM +0200, Robert Vanden Eynde < > robertv...@gmail.com> wrote: > > As said 100 times in the list, email is powerful, configurable but needs > a > > lot of configuration (especially hard on mobile) and has a lot of rules > > (don't top post, reply to the list, don't html, wait, html is alright) > > whereas a web based alternative is easier to grasp (more modern) but adds > > more abstraction. > > > > I can't find the link we had explaining the difference between those two, > > but mailing list is easily searchable and archivable and readable on a > > terminal. > >May I show mine: https://phdru.name/Software/mail-vs-web.html ? > > 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 > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > -- Juancarlo *Añez* ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Alternative spelling for list.append()
>> For all practical purpose, it would be enough to define that the
>> expression:
>>
>> mylist += [item]
>>
>> gets optimized to mylist.append(item).
>>
>
> Unfortunately, that would create yet another special case of operators
> breaking the rules. Most operators invoke magic methods. This would prevent
> ``+=`` from invoking ``__iadd__`` for lists, since the right-hand side
> would need to be compiled differently. It's similar to why ``and`` and
> ``or`` keywords can't have magic methods.
>
It seems that the optimization is already in place:
import timeit
COUNT = 1
REPS = 1
def using_append():
result = []
for i in range(COUNT):
result.append(i)
return result
def using_concat():
result = []
for i in range(COUNT):
result += [i]
return result
def using_iadd():
result = []
for i in range(COUNT):
result.__iadd__([i])
return result
def main():
print(timeit.timeit('using_append()', globals=globals(), number=REPS))
print(timeit.timeit('using_concat()', globals=globals(), number=REPS))
print(timeit.timeit('using_iadd()', globals=globals(), number=REPS))
if __name__ == '__main__':
main()
--
Juancarlo *Añez*
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Alternative spelling for list.append()
> The idea is to introduce new syntax for the list.append() method. > > > Syntax: > > Variant 1. > Use special case of index, namely omitted index: > > mylist[] = item > For all practical purpose, it would be enough to define that the expression: mylist += [item] gets optimized to mylist.append(item). -- Juancarlo *Añez* ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] A PEP on introducing variables on 'if' and 'while'
> As the PEP author, that's your job.
>
I started writing the PEP, and I found an interesting example:
if not (m := re.match(r'^(\d+)-(\d+)$', identifier):
raise ValueError('f{identifier} is not a valid identifier')
print(f'first part is {m.group(1)}')
print(f'first part is {m.group(2)}')
That's fairly easy to understand, and not something that can be resolved
with `as` if it's part of the `if` and `while` statement, rather than a
different syntax for the `:=` semantics.
That one would have to be written as it is done now:
m = re.match(r'^(\d+)-(\d+)$', identifier)
if not m:
raise ValueError('f{identifier} is not a valid identifier')
print(f'first part is {m.group(1)}')
print(f'first part is {m.group(2)}')
--
Juancarlo *Añez*
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] A PEP on introducing variables on 'if' and 'while'
> The only difference is that the `except` block implicitly unbinds the > variable when the block ends. > Mmmm. Good to know, because that means that the semantics are the same, except... > > while (condition := expression) as flag: > ... > Ah! Are the parenthesis necessary there? Accepting "while/if as name" would remove much (but not all) of the > motivation for assignment expressions, while accepting assignment > expressions would make a dedicated while/if as name syntax unnecessary. > Most of the arguments in favor of ':=' have been through examples of generators in which the introduced name is used within, with the if/while case often forgotten. There can be cases in which combining both syntaxes is useful: x = None while compute(x := v for v in next_series_value(x)) as comp: ... x = comp > Like it or not, I expect that they will be seen as competing PEPs, not > independent ones. Finding a real-world example of something like the above synthetic example would be in favor of the orthogonality. -- Juancarlo *Añez* ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] A PEP on introducing variables on 'if' and 'while'
> Do you mean the context manager semantics of with statements? As in, > calling the __enter__ and __exit__ method? > No. Just the scope of the variables introduced, which is different in `with as` and `except as`. > Please make sure you are very familiar with PEP 572 before you do, and > expect to have your PEP compared to it. > My intention would be to make the to proposals orthogonal, if possible, so both/any can be accepted or rejected in their own timeline. I'm certain that both can live together. -- Juancarlo *Añez* ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] A PEP on introducing variables on 'if' and 'while'
Hello @here, Is there a guide about writing (and publishing) PEPs? I'd like to write one on `while expre as v: ...` using the context semantics of `with expr as v` (not `except E as e`). Cheers, ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Modern language design survey for "assign and compare" statements
> while ((v = get_something()) != INCONVENIENT_SENTINEL)
> do_something(v);
>
The current pattern in Python would be something like:
v = get_something()
while v != INCONVENIENT_SENTINEL:
do_something(v)
v = get_something()
With "as" allowed in "while", they pattern might be:
while get_something() as v:
if v == INCONVENIENT_SENTINEL:
break
do_something(v)
The discussion isn't over, so it could also be:
while (get_something() as v) != INCONVENIENT_SENTINEL:
do_something(v)
Cheers,
--
Juancarlo *Añez*
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Modern language design survey for "assign and compare" statements
> > print(child_pid) # child_pid is undefined
>
> Why on earth would it be undefined?
>
Indeed, users would expect the new uses of "as" to behave as the previous
ones. The problem is that "with" and "except" do things differently:
In [*1*]: *import* *os*
In [*2*]: *with* open(os.path.expanduser('~/tmp/xx')) *as* f:
...: *pass*
...:
In [*3*]: print(f)
<_io.TextIOWrapper name='/Users/apalala/tmp/xx' mode='r' encoding='UTF-8'>
In [*4*]: *try*:
...: print('ok')
...: *raise* *Exception*()
...: *except* *Exception* *as* e:
...: *pass*
...:
In [*5*]: print(e)
---
NameError Traceback (most recent call last)
in ()
> 1 print(e)
NameError: name 'e' is not defined
> Anyway, if you want to propose an alternative to PEP 572, you ought to
> write your own competing PEP.
>
I don't take that as a challenge. It would be good to have different, maybe
somewhat competing PEPs. It's been done before.
--
Juancarlo *Añez*
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Modern language design survey for "assign and compare" statements
> What would be the benefit of adding the "as child_pid" syntax? The > full assignment expression syntax completely covers all the jobs that > you can do with a capturing if statement. > > The "as" syntax over "if" and "while" may go in with all the restrictions and caveats already discussed. The discussion about the semantics of how ":=" should affect the enclosing context when used in generators, etc. may continue for as long as it must. And there are some of us who like the consistency of "us", and would shy away from ":=". For example, Should this be valid? if child_pid := os.fork(): parent(child_pid) else: child() print(child_pid) This shouldn't be: if os.fork() as child_pid: parent(child_pid) else: child() print(child_pid) # child_pid is undefined -- Juancarlo *Añez* ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Modern language design survey for "assign and compare" statements
On Sun, May 20, 2018 at 1:35 AM, Steven D'Aprano wrote: > > but maybe when languages are weird enough they all look the same :-) > > https://www.dreamsongs.com/WorseIsBetter.html Look at what happened with PERL... IMPORTANT NOTE: Enabling "as" in "if" and "while" doesn't have to be at the expense of some form of assignment expression. We've been having this discussion as if has to be either one or the other, and there's no reason we can't have both (as mentioned before, "reduce()" is live and well in the libraries, for people who need to use it). I in particular would not like it at all if something like ":=" was at the expense of "as", and I think that others on the side of expanding "if" and "while" may feel the same way. As a reminder, some of the arguments in favor of "as" are around the patterns exemplified by the "re" module; patterns which seem correct and useful, and that are used by other standard and 3rd-party modules. if os.fork() as child_pid: parent(child_pid) else: child() Cheers! -- Juancarlo *Añez* ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Modern language design survey for "assign and compare" statements
Conclusions > > > It appears assignment expressions are no longer the favored solution for > the > "assign and compare" use case. Not one of these five newer languages > supports > them fully, as the language generations from C to C# did. > > Of those that have recognized the use case to be large enough—the solution > has > been rather more limited to the "if" and "while" statements only. Several > folks here have expressed the same desire to confine AE there. Since > Python's > design goals are similar—to be safe and maintainable I'd recommend a > similar > strategy, with the addition of the list comprehension case. Going back to > the > C-style solution seems like the wrong direction. > > Since that would mean this special assignment functionality is not allowed > to > be used everywhere, it alleviates the pressure to make it fit into > with/import/except statements. Furthermore, that frees up the keyword "as" > again, which is Pythonic, short, memorable and has a history of being used > for > various assignment purposes, not to mention a prominent feature of SQL. > > In short, extend the "if/elif", "while", and comprehension to: > > if pattern.search(data) as match: > … > > while read_next_item() as value: > … > > May be best to disallow multiple assignment/conditions for now, but up for > discussion. That leaves comprehensions, which could support a EXPR as NAME > target also: > > filtered_data = [f(x) as y, x/y for x in data] > > or perhaps reuse of the if…as statement to keep it simpler: > > filtered_data = [y, x/y for x in data if f(x) as y] > > That variant might need an extra test if f(x) returns a falsey value, > perhaps > "is not None" on the end. > > Thoughts? > -Mike > Thanks for the research! Which is the niche, and how influential can it be, to have Python divert from the well learned "assignments must be statements". Cheers! -- Juancarlo *Añez* ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Inline assignments using "given" clauses
> That's an excellent point. What's "special_gcd" and how does it differ > from normal gcd? How am I supposed to grok that just from reading the > code above? > > Do I have to dig into the source of special_gcd to understand it? > > One would usually define functions like special_gcd() inline, right before it is first used. -- Juancarlo *Añez* ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Inline assignments using "given" clauses
> if (diff := x - x_base) and (g := gcd(diff, n)) > 1: > return g > > I don't see the advantage in that succinctness: g = special_gcd(x - x_base, n) if g: return g The code bases I work on constantly move towards having the next guy grok what's going on just by reading the code. It could also be: if special_gcd(x - x_base, n) as g: return g Cheers! Juancarlo *Añez* ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Inline changes to context, or PEP572
A new thread just to suggest taking the discussion about PEP572 well beyond python-ideas (PyConn is good for that). The least anyone should want is a language change that immediately gets tagged on the networks as "don't use", or "use only for...", etc. To be honest, I'll likely be on the "don't use :=, unless" band of pundits (already a filibuster). ":=" is like going back to "reduce()", which is almost defunct thanks to.. us! Cheers! -- Juancarlo *Añez* ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Inline assignments using "given" clauses
> LOOK similar, but are subtly different. The current 'with' statement > doesn't create a subscope; the only "context" it creates is regarding > the resource represented by the context manager. For instance, opening > a file in a 'with' block will close the file at the end of the block - > but you still have a (closed) file object. Using "with... as" for name > bindings wouldn't call __enter__ or __exit__, so it won't create that > kind of context; and whether it creates a subscope for the variable or > not, it's not going to match the 'with' statement. > That is all valid, but it still would be familiar, and easier to explain. Python already uses "in", which is used in other languages to introduce context. The statement structure of "with...as" seems desirable, just asking for a word that is not "with" or "given". I don't remember if "when" was already rejected. http://www.thesaurus.com/browse/with?s=t http://www.thesaurus.com/browse/given?s=t http://www.thesaurus.com/browse/considering?s=t http://www.thesaurus.com/browse/assume?s=t http://www.thesaurus.com/browse/when?s=t Cheers! -- Juancarlo *Añez* ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Inline assignments using "given" clauses
> My main point here is that "with" works as well as "given" in this form > from an English prose point of view. > +1 for "with...as", -1 for ":=" About affecting existing contexts, it seems that "with..as" would create a new context just for the expression, and the control statement it is embedded in, similar to what the current "with" statement does. These are semantics that are really easy to explain. Cheers! ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Inline assignments using "given" clauses
> > while (cmd := get_command()).token != CMD_QUIT: > > cmd.do_something() > > while get_command() as cmd: if cmd.token == CMD_QUIT: break cmd.do_something() -- Juancarlo *Añez* ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] A comprehension scope issue in PEP 572
> Implementation details - even just partial sketches - are always > "busy". Think of it this way instead: it's _currently_ the case that > listcomps & genexps run in a scope S that's the same as the scope C > that contains them, _except_ that names appearing as `for` targets are > local to S. All other names in S resolve to exactly the same scopes > they resolved to in C (local in C, global in C, nonlocal in C - > doesn't matter). > > What changes now? Nothing in that high-level description, except that > a name appearing as a binding expression target in S that's otherwise > unknown in C establishes that the name is local to C. That's nothing > essentially new, though - bindings _always_ establish scopes for > otherwise-unknown names in Python. That's a very nice (and short) explanation! Maybe my distrust is just don't like the new syntax, or that I'am biased towards using "as". -- Juancarlo *Añez* ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] A comprehension scope issue in PEP 572
So the way I envision it is that *in the absence of a nonlocal or global > declaration in the containing scope*, := inside a comprehension or genexpr > causes the compiler to assign to a local in the containing scope, which is > elevated to a cell (if it isn't already). If there is an explicit nonlocal > or global declaration in the containing scope, that is honored. > This seems to be getting awfully complicated. Proof? Try to write the docs for the proposed semantics. I don't understand why we went so astray from the original requirements, which could all be met by having `if` and `while` accept `as` to bind an expression to a variable that would be local to the structured statement. Cheers, -- Juancarlo *Añez* ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Inline assignments using "given" clauses
I think that "expr as y" was discarded too quickly. It would be a syntax completely familiar to Python programmers, and the new semantics would be obvious. That choice would also be in line with the Zen of Python. The special cases that may arise over "except" and "with" can be worked out and documented. Cheers, On Sat, May 5, 2018 at 5:22 AM, Robert Vanden Eynde wrote: > I agree it would be useful to have new keywords without being reserved, > and we could even go with mechanism like infix operators created by user. > > It would allow things like [given for x in range(5) given given = x+1] or > even [given for given in range(given) given given = given + 1] haha, but as > other pointed out, it would be called Bad practice ^^ > > By the way, I still prefer "where" to "given". > > Le sam. 5 mai 2018 à 10:52, Greg Ewing a > écrit : > >> Tim Peters wrote: >> > "async def", "async for", and "async with" statements were added >> > _without_ making "async" a new reserved word. It may require pain in >> > the parser, but it's often doable anyway. >> >> There would be less pain if the parser generator could >> deal with non-reserved keywords more directly. >> >> -- >> Greg >> ___ >> Python-ideas mailing list >> Python-ideas@python.org >> https://mail.python.org/mailman/listinfo/python-ideas >> Code of Conduct: http://python.org/psf/codeofconduct/ >> > > ___ > Python-ideas mailing list > Python-ideas@python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > > -- Juancarlo *Añez* ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Repurpose `assert' into a general-purpose check
Perhaps the OP can look into Python macro libraries to get the wanted syntax? https://github.com/lihaoyi/macropy On Tue, Jan 16, 2018 at 2:35 PM, Paul Moore wrote: > On 16 January 2018 at 17:36, Sylvain MARIE > wrote: > > (trying with direct reply this time) > > > >> Why do you do this? What's the requirement for delaying evaluation of > the condition? > > > > Thanks for challenging my poorly chosen examples :) > > > > The primary requirement is about *catching* > > unwanted/uncontrolled/heterogenous > exceptions happening in the underlying functions that are combined together > to provide the validation means, so as to provide a uniform/consistent > outcome however diverse the underlying functions are (they can return > booleans or raise exceptions, or both). > > > > In your proposal, if 'is_foo_compliant' raises an exception, it will not > be caught by 'assert_valid', therefore the ValidationError will not be > raised. So this is not what I want as an application developer. > > Ah, OK. But nothing in your proposal for a new statement suggests you > wanted that, and assert doesn't work like that, so I hadn't realised > that's what you were after. > > You could of course simply do: > > def assert_valid(expr, help_msg): > # Catch exceptions in expr() as you see fit > if not expr(): > raise ValidationError(help_msg) > > assert_valid(lambda: 0 <= surf < 1 and is_foo_compliant(surf), > help_msg="surface should be 0= > No need for a whole expression language :-) > > Paul > ___ > Python-ideas mailing list > Python-ideas@python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > -- Juancarlo *Añez* ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Data Classes in Kotlin
I thought this might be interesting input for the discussions about "data classes" in Python: https://kotlinlang.org/docs/reference/data-classes.html I think that the use of "data class" as syntax is kind of cool, but what really matters is the semantics they chose for Kotlin. -- Juancarlo *Añez* ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] About the efficiency of range()
I found this interesting: https://stackoverflow.com/a/46996392 -- Juancarlo *Añez* ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Defining an easily installable "Recommended baseline package set"
On Mon, Oct 30, 2017 at 12:29 PM, Guido van Rossum wrote: > What's your proposed process to arrive at the list of recommended > packages? And is it really just going to be a list of names, or is there > going to be some documentation (about the vetting, not about the contents > of the packages) for each name? > As I see it, the bootstrap would be a requirements.txt (requirements.pip) with the packages that more experienced developers prefer to use over stdlib, pinned to package versions known to work well with the CPython release. I think this is a great idea, specially if it's an easy opt-in. For example, sometimes I go into a programming niche for a few years, and I'd very much appreciate a curated list of packages when I move to another niche. A pay-forward kind of thing. The downside to the idea is that the list of packages will need a curator (which could be python.org). ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] PEP draft: context variables
> Interestingly, thinking about the problem in terms of exception handling > flow reminded me of the fact that having a generator-iterator yield while > inside a with statement or try/except block is already considered an > anti-pattern in many situations, precisely because it means that any > exceptions that get thrown in (including GeneratorExit) will be intercepted > when that may not be what the author really intended. > > It all works fine now: https://github.com/neogeny/TatSu/blob/master/tatsu/contexts.py So, I have a strong requirement: whatever is decided on this PEP... Please don't break it? (or make it illegal) -- Juancarlo *Añez* ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Add time.time_ns(): system clock with nanosecond resolution
It could be: time.time(ns=True) On Sun, Oct 15, 2017 at 7:44 PM, Guido van Rossum wrote: > Sorry, that's an in-joke. Koos is expressing his disappointment in the > rejection of PEP 555 in a way that's only obvious if you're Dutch. > > On Sun, Oct 15, 2017 at 3:16 PM, Steven D'Aprano > wrote: > >> On Sun, Oct 15, 2017 at 08:04:25PM +0300, Koos Zevenhoven wrote: >> > On Sun, Oct 15, 2017 at 6:58 PM, Guido van Rossum >> wrote: >> > >> > > I'd like to have time.time_ns() -- this is most parallel to >> st_mtime_ns. >> > > >> > > >> > Welcome to the list Guido! You sound like a C programmer. For many >> people, >> > that was the best language they knew of when they learned to program. >> But >> > have you ever tried Python? You should give it a try! >> >> You seem to be making a joke, but I have *no idea* what the joke is. >> >> Are you making fun of Guido's choice of preferred name? "time_ns" >> instead of "time_nanoseconds" perhaps? >> >> Other than that, I cannot imagine what the joke is about. Sorry for >> being so slow. >> >> >> -- >> Steve >> ___ >> Python-ideas mailing list >> Python-ideas@python.org >> https://mail.python.org/mailman/listinfo/python-ideas >> Code of Conduct: http://python.org/psf/codeofconduct/ >> > > > > -- > --Guido van Rossum (python.org/~guido) > > ___ > Python-ideas mailing list > Python-ideas@python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > > -- Juancarlo *Añez* ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] namedtuple literals [Was: RE a new namedtuple]
Steven,
(short of time here)
With **kwargs and a little more work, the function would check if the type
is already defined, and retur the ntuple with the correct type, not the
type.
Your sketch of a solution convinced me it can be done with a library
function; no additional syntax needed.
Cheers,
On Tue, Jul 25, 2017 at 5:08 AM, Stephen J. Turnbull <
turnbull.stephen...@u.tsukuba.ac.jp> wrote:
> C Anthony Risinger writes:
>
> > At the end of the day, I don't see a way to have both a literal and
> > something that is externally "named", because the only ways to pass the
> > name I can imagine would make it look like a value within the container
> > itself (such as using a literal string for the first item), unless even
> > more new syntax was added.
>
> OK, so I took your "a tuple is a tuple is a tuple" incorrectly. What
> you want (as I understand it now) is not what
>
> def ntuple0(attr_list):
> return namedtuple("_", attr_list)
>
> gives you, but something like what
>
> def ntuple1(attr_list)
> return namedtuple("ImplicitNamedtuple_" + "_".join(attr_list),
> attr_list)
>
> does. Then this would truly be a "duck-typed namedtuple" as Chris
> Barker proposed in response to Steven d'Aprano elsewhere in this
> thread. See also Nick's full, namedtuple-compatible, implementation.
> Of course we still have the horrible "list of strings naming
> attributes" argument, so you still want a literal if possible, but
> with a **key argument, a new builtin would do the trick for me. YMMV.
>
>
> --
> Associate Professor Division of Policy and Planning Science
> http://turnbull/sk.tsukuba.ac.jp/ Faculty of Systems and Information
> Email: turnb...@sk.tsukuba.ac.jp University of Tsukuba
> Tel: 029-853-5175 Tennodai 1-1-1, Tsukuba 305-8573 JAPAN
> _______
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
--
Juancarlo *Añez*
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] namedtuple literals [Was: RE a new namedtuple]
> So the only thing being ruled out is the dedicated syntax option, > since it doesn't let us do anything that a new builtin can't do, it's > harder to find help on (as compared to "help(ntuple)" or searching > online for "python ntuple"), and it can't be readily backported to > Python 3.6 as part of a third party library (you can't easily backport > it any further than that regardless, since you'd be missing the > order-preservation guarantee for the keyword arguments passed to the > builtin). > If an important revamp of namedtuple will happen (actually, "easy and friendly immutable structures"), I'd suggest that the new syntax is not discarded upfront, but rather be left as a final decision, after all the other forces are resolved. FWIW, there's another development thread about "easy class declarations (with typining)". From MHPOV, the threads are different enough to remain separate. Cheers! -- Juancarlo *Añez* ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] namedtuple literals [Was: RE a new namedtuple]
> Honestly I would like to declare the bare (x=1, y=0) proposal dead. Let's > encourage the use of objects rather than tuples (named or otherwise) for > most data exchanges. I know of a large codebase that uses dicts instead of > objects, and it's a mess. I expect the bare ntuple to encourage the same > chaos. > Languages since the original Pascal have had a way to define types by structure. If Python did the same, ntuples with the same structure would be typed "objects" that are not pre-declared. In Python's case, because typing of fields is not required and thus can't be used to hint the structures type, the names and order of fields could be used. Synthesizing a (reserved) type name for (x=1, y=0) should be straight forward. I short, >>> isinstance(x=None, y=None), type((x=1, y=0))) True That can be implemented with namedtuple with some ingenious mangling for the (quasi-anonymous) type name. Equivalence of types by structure is useful, and is very different from the mess that using dicts as records can produce. Cheers, -- Juancarlo *Añez* ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Arguments to exceptions
On Mon, Jul 3, 2017 at 4:59 AM, Ken Kundert wrote: > That is the problem. To write the error handler, I need the misspelled > name. > The only way to get it is to extract it from the error message. The need to > unpack information that was just packed suggests that the packing was done > too > early. That is my point. > 1. You can pass an object with all the required information and an appropriate __str__() method to the exception constructor. 2. If you own the exception hierarchy, you can modify the __str__() method of the exception class. -- Juancarlo *Añez* ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Define __fspath__() for NamedTemporaryFile and TemporaryDirectory
On Thu, Jun 8, 2017 at 9:42 AM, Antoine Pietri wrote: > My proposal is to define __fspath__() for TemporaryDirectory and > NamedTemporaryFile so that we can pass those directly to the library > functions instead of having to use the .name attribute explicitely. > +1 -- Juancarlo *Añez* ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Security: remove "." from sys.path?
On Sun, Jun 4, 2017 at 6:51 PM, Guido van Rossum wrote: > I really don't want people to start using the "from . import foo" idiom > for their first steps into programming. It seems a reasonable "defensive > programming" maneuver to put in scripts and apps made by professional > Python programmers for surprise-free wide distribution, but (like many of > those) should not be part of the learning experience. At the same time, someday you may want the support for 2.7-kind-of issues to stop. Requiring "from" (or other ways to make the source of the import unambiguous) is common in programming languages. Cheers, -- Juancarlo *Añez* ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Security: remove "." from sys.path?
I'm not comfortable with the subject title of this thread. I'm comfortable with the experiences and solutions proposed by Nick. On Sat, Jun 3, 2017 at 8:16 PM, Greg Ewing wrote: > Soni L. wrote: > >> How about `import self.thing` (where "self" implies same dir as the >> current .py >> > > That wouldn't provide quite the same functionality, since > currently a module alongside the main py file can be imported > from anywhere, including .py files inside a package. > > Also I think it would be confusing to have two very similar > but subtly different relative import mechanisms. > > -- > Greg > > ___ > Python-ideas mailing list > Python-ideas@python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > -- Juancarlo *Añez* ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Defer Statement
On Sat, Jun 3, 2017 at 6:59 AM, Daniel Bershatsky wrote: Or with usage defer keyword > > ``` > fin = open(filename) > defer fin.close() > # some stuff > IMHO, a block in which the intention of a `finally: is not well understood, needs refactoring. Some *old* code is like that, but it doesn’t mean it’s *bad*. Then, as a matter of personal preference, I’m not comfortable with that the *defer* idiom talks first about things that should be done last. It’s a debt acquired without enough syntactic evidence (Oh! Mi gosh!, There were those defers at the start of the function I just changed). >From import this: Explicit is better than implicit. -- Juancarlo *Añez* ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] π = math.pi
On Fri, Jun 2, 2017 at 7:29 PM, Guido van Rossum wrote: Are those characters not considered Unicode letters? Maybe we could add > their category to the allowed set? Speaking of which, it would be convenient to be able to build strings with non-ascii characters using their Unicode codepoint name: greek_pi = "\u:greek_small_letter_pi" Or something like that. -- Juancarlo *Añez* ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] tweaking the file system path protocol
On Sun, May 28, 2017 at 5:33 PM, Wolfgang Maier < wolfgang.ma...@biologie.uni-freiburg.de> wrote: > With __fspath__ being a method that can return whatever its author sees > fit, calling str to get a path from an arbitrary object is just as wrong as > it always was - it will work for pathlib.Path objects and might or might > not work for some other types. Importantly, this has nothing to do with > this proposal, but is in the nature of the protocol as it is defined *now*. +1 -- Juancarlo *Añez* ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Suggestion: push() method for lists
On Sun, May 21, 2017 at 10:43 AM, Paul Laos wrote: > By default push(obj) would insert an object to the end of the list, while > push(obj, index) would insert the object at index, just like pop() removes > (and returns) the object at the end of the list, and pop(index) removes > (and returns) the object at the index. The name asymmetry between .pop() and .append() has always bothered me. Cheers! -- Juancarlo *Añez* ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] JavaScript-Style Object Creation in Python (using a constructor function instead of a class to create objects)
On Wed, May 17, 2017 at 12:48 PM, Ivan Levkivskyi wrote: > class Foo(NamedTuple): > """Foo is a very important class and > you should totally use it. > """ > bar: int > baz: int = 0 > > def grand_total(self): > return self.bar + self.baz > Really?! I didn't know that idiom existed. It is enough for many use cases, and I was just about to require typing and pathlib on my 2.7-compatible projects. -- Juancarlo *Añez* ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] JavaScript-Style Object Creation in Python (using a constructor function instead of a class to create objects)
On Tue, May 16, 2017 at 5:04 PM, Guido van Rossum wrote: What features of attrs specifically solve your use cases? > (not Stephen) I hadn’t thought about this use case: In [1]: class C(): ...: x = 1 ...: ...: def __init__(self, x=None): ...: if x is not None: ...: self.x = x ...: ...: def __str__(self): ...: return 'C(%s)' % self.x ...: In [2]: c1 = C() ...: c2 = C(2) ...: In [3]: print(c1, c2) C(1) C(2) And I might use it here on. What I like about attrs is: - The class level declaration of instance attributes - That the reasonable *init*, *repr*, and *eq* are generated I don’t like the excessive wordiness in attrs, and I don’t need “the kitchen sink” be available to have instance attributes declared at the class level. A solution based on the typing module would be much better. Basically, Python is lacking a way to declare instance fields with default values away of the initializer. Several of the mainstream OO languages (Java, Swift, Go) provide for that. I haven’t thought much about this, except about if there’s indeed a need (and there is), but I can’t know if the solution if through decorators, or inheritance. -- Juancarlo *Añez* ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] PEP 526: why ClassVar instead of ClassAttr?
On Tue, May 16, 2017 at 10:10 PM, Guido van Rossum wrote: > It's "class variable" because we (at least I) also routinely use "instance > variable". It is `getattr()`, `setattr()`, and a very long etc. in Python. I agree with the OP that a sudden talk about "vars" is confusing, more so when Python doesn't have "vars", but "names" (etc.). Cheers! -- Juancarlo *Añez* ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] singledispatch for instance methods
On Sun, May 14, 2017 at 1:28 PM, Steven D’Aprano wrote: - contact Tim Mitchell and see if his offer of contributing the code > still stands; > FWIW, this is a Python implementation of a single-dispatch decorator for methods that I wrote from looking at the stdlib, and that I have used successfully in some projects: from functools import singledispatchfrom functools import update_wrapper def singledispatch_method(method): dispatcher = singledispatch(method) def wrapper(*args, **kw): return dispatcher.dispatch(args[1].__class__)(*args, **kw) wrapper.register = dispatcher.register update_wrapper(wrapper, method) return wrapper -- Juancarlo *Añez* ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Add an option for delimiters in bytes.hex()
On Tue, May 2, 2017 at 8:43 PM, Steven D'Aprano wrote:
> String methods should return strings.
>
>>> "A-B-C".split("-")
['A', 'B', 'C']
If chunk() worked for all iterables:
>>> " ".join("1234ABCDEF".chunk(4))
"1234 ABCD EF"
Cheers,
--
Juancarlo *Añez*
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Add an option for delimiters in bytes.hex()
On Mon, May 1, 2017 at 9:38 AM, Nick Coghlan wrote: > just support two > keyword arguments to hex(): "delimiter" (as you suggest) and > "chunk_size" (defaulting to 1, so you get per-byte chunking by > default) > I'd expect "chunk_size" to mean the number of hex digits (not bytes) per chunk. Cheers, -- Juancarlo *Añez* ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Augmented assignment syntax for objects.
On Thu, Apr 27, 2017 at 7:28 PM, Steven D'Aprano wrote: > > In my experience, what Python is lacking is a way to declare attributes > > outside of the constructor. Take a look at how it's done in C#, Swisft, > or > > Go. > > Since you apparently already know how they do it, how about telling us > (1) how they do it, and (2) *why* they do it? > They make attribure declarations at the class declaration scope be instance attributes. Python makes that kind of declaration class attributes (statics in some other languages). This is the spec for C#: https://goo.gl/FeBTuy The reason *why* they do it that way is because declaring instance fields/variables is much more frequent than declaring class ones. > > Object attributes outside of the constructor would solve things more > > relevant than the vertical space used when assigning constructor > parameters > > to attributes. > > Solve which things? > Instance attributes may be defined with or without default values without having to pass them as arguments to or mention them in a constructor. > > For example, multiple inheritance is well designed in > > Python, except that it often requires constructors with no parameters, > > which leads to objects with no default attributes. > > Can you elaborate? A class hierarchy in which there is multiple inheritance requires constructors with no arguments. This is typical: https://goo.gl/l54tx7 I don't know which would be the best syntax, but it would be convenient to be able to declare something like: class A: var a = 'a' And have "a" be an instance attribute. -- Juancarlo *Añez* ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Augmented assignment syntax for objects.
On Wed, Apr 26, 2017 at 6:57 PM, Mike Miller wrote: > Yes, I like it too. Removes the triple repetition, and has precedent in > the other languages. This discussion has been around how to deal with repetition in object constructors, and the proposals have been a new assignment statement (patch assignments?) or decorators to __init__ (patch init). In my experience, what Python is lacking is a way to declare attributes outside of the constructor. Take a look at how it's done in C#, Swisft, or Go. Object attributes outside of the constructor would solve things more relevant than the vertical space used when assigning constructor parameters to attributes. For example, multiple inheritance is well designed in Python, except that it often requires constructors with no parameters, which leads to objects with no default attributes. The namespace after "class" is taken by class attributes. There's no namespace for default object attributes outside __init__. Solving that would likely lead to simple and sensible solutions to the OPs query. I don't think that a solution to the OPs query should be treated as a No-No, because there's namedtuple, which is quirky, but solved lots of use cases (the same goes for Enum). IMHO, something like the attrs library solves lots of common use cases... except that tool support is poor because attrs is not part of stdlib. It is not about having to write a few more lines in an __init__ constructor. There are common and frequent use cases of "objects are mostly data" that are partially solved in Python (mostly through namedtuple?). Cheers! -- Juancarlo *Añez* ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Augmented assignment syntax for objects.
On Wed, Apr 26, 2017 at 11:17 AM, Erik wrote: > I had forgotten that decorators could take parameters. Something like that > pretty much ticks the boxes for me. > There are decorators with "include" and "included" in this SO Q&A: http://stackoverflow.com/q/3652851/545637 > I'd _prefer_ something that sits inside the method body rather than just > outside it, and I'd probably _prefer_ something that wasn't quite so > heavyweight at runtime (which may be an irrational concern on my part ;)), > The same strategies applied by the decorators may be applied by a by a function called from within __init__. > but those aren't deal breakers, depending on the project - and the vast > majority of what I do in Python is short-lived one-off projects and rapid > prototyping for later implementation in another language, so I do seem to > be fleshing out a set of classes from scratch and writing a bunch of > __init__ methods far more of the time than people with long-lived projects > would do. Perhaps that's why it irritates me more than it does some others > ;) > For the cases I've found in which classes define several attributes that are initialized in the constructor I think that a library like https://github.com/python-attrs/attrs does what's needed. The downside is that code-writing tools (like IDEs) don't understand what's going on under the hood. -- Juancarlo *Añez* ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Augmented assignment syntax for objects.
On Tue, Apr 25, 2017 at 6:09 PM, Paul Moore wrote: > (Arguing for auto_args to be in the stdlib may be a better option than > arguing for new syntax, BTW...) > Having such a decorator in the stdlib would allow IDEs and syntax highlighters to know what's going on. -- Juancarlo *Añez* ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] What about regexp string litterals : re".*" ?
On Mon, Apr 3, 2017 at 8:57 AM, Neil Girdhar wrote: > I've tried PyParsing. I haven't tried Grako. > Caveat: I'm the author of Grako. It's very easy to do complex parsing with Grako. The grammar can be embedded in a Python string, and the compiled grammar can be used for parsing without generating any Python code. Most of the unit tests under the distribution's grako/grako/test use those features. https://pypi.org/project/grako/ One of the ways in which a top-down grammar (as those accepted by Grako) can be used is to organize a series of regular expressions into a tree to handle complex cases with clarity. -- Juancarlo *Añez* ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
