On 14 April 2018 at 13:28, Ken Hilton wrote:
> Hi all,
>
> First of all, please excuse me if I'm presenting this idea in the wrong way
> or at the wrong time - I'm new to this mailing list and haven't seen anyone
> propose a new idea on it yet, so I don't know the customs.
>
> I have an idea for i
I'm fairly certain similar changes have been discussed in the past. Someone
else can probably find / link / rehash the reasons why imports deliberately
use dot notation instead of path?
I can think of a few:
1) Portability. dotted imports looked up from sys.path are platform-portable
# $HOME/\th
Hi all,
First of all, please excuse me if I'm presenting this idea in the wrong way
or at the wrong time - I'm new to this mailing list and haven't seen anyone
propose a new idea on it yet, so I don't know the customs.
I have an idea for importing files with arbitrary names. Currently, the
"offic
2018-04-11 2:03 GMT+02:00 Steven D'Aprano :
[snip]
> I shouldn't think that the number of files on disk is very important,
> now that they're hidden away in the __pycache__ directory where they can
> be ignored by humans. Even venerable old FAT32 has a limit of 65,534
> files in a single folder,
On Sat, Apr 14, 2018 at 7:33 AM, Kirill Balunov wrote:
>
>
> 2018-04-13 23:31 GMT+03:00 Chris Angelico :
>>
>>
>> > # but these are subtly different and will be a trap for the unwary
>> > with expression as name: # name is set to __enter__()
>> > with (expression as name): # name is
2018-04-13 23:31 GMT+03:00 Chris Angelico :
>
> > # but these are subtly different and will be a trap for the unwary
> > with expression as name: # name is set to __enter__()
> > with (expression as name): # name is not set to __enter__()
>
> And that's a good reason to reject the la
On Sat, Apr 14, 2018 at 2:43 AM, Steven D'Aprano wrote:
> On Fri, Apr 13, 2018 at 05:04:00PM +0200, Jacco van Dorp wrote:
>
>> > I'm saying, don't even try to distinguish between the forms with or
>> > without parens. If we add parens:
>> >
>> > with (expr as name):
>> >
>> > it may or may not
On Sat, Apr 14, 2018 at 12:50 AM, Steven D'Aprano wrote:
> On Fri, Apr 13, 2018 at 02:30:24PM +0100, Paul Moore wrote:
>> On 13 April 2018 at 14:18, Steven D'Aprano wrote:
>> > On Fri, Apr 13, 2018 at 09:56:35PM +1000, Chris Angelico wrote:
>>
>> >> 2) Forbid any use of "(expr as name)" in the he
On Fri, Apr 13, 2018 at 11:30 PM, Peter O'Connor
wrote:
> Well this may be crazy sounding, but we could allow left or right assignment
> with
>
> name := expr
> expr =: name
>
> Although it would seem to violate the "only one obvious way" maxim, at least
> it avoids this overloaded meaning with th
On Fri, Apr 13, 2018 at 11:18 PM, Steven D'Aprano wrote:
> On Fri, Apr 13, 2018 at 09:56:35PM +1000, Chris Angelico wrote:
>
>
>> How many times have people asked for "with (expr as name):" to
>> be supported, allowing the statement to spread over multiple lines?
>> With this syntax, it would sudd
On 2018-04-13 16:13, Guido van Rossum wrote:
Regarding the precedence of :=, at this point the only acceptable
outcome for me is one where at the statement level, := and = can be used
interchangeably and will have the same meaning (except probably we
wouldn't allow combining both in a chained a
On Sat, Apr 14, 2018 at 1:44 AM, Steven D'Aprano wrote:
> On Fri, Apr 13, 2018 at 10:35:59PM +1000, Chris Angelico wrote:
>> Yet Python has an if/else operator that, in contrast to C-inspired
>> languages, violates that rule. So it's not a showstopper. :)
>
> A ternary operator can't put *all* thr
On Sat, Apr 14, 2018 at 12:36 AM, Nick Coghlan wrote:
> On 13 April 2018 at 22:35, Chris Angelico wrote:
>> On Fri, Apr 13, 2018 at 10:22 PM, Steven D'Aprano
>> wrote:
>>> On Wed, Apr 11, 2018 at 11:50:44PM +1000, Chris Angelico wrote:
>>>
> Previously, there was an alternative _operator f
On Fri, Apr 13, 2018 at 05:04:00PM +0200, Jacco van Dorp wrote:
> > I'm saying, don't even try to distinguish between the forms with or
> > without parens. If we add parens:
> >
> > with (expr as name):
> >
> > it may or may not be allowed some time in the future (since it isn't
> > allowed no
On 2018-04-13 08:44, Steven D'Aprano wrote:
So my position is:
- "as" is more Pythonic and looks nicer;
Yes, perhaps if typing annotations had not chosen the colon but used a
whitespace delimiter instead, adding a few more colons to the source would not
be an issue.
But in combination, it
I usually go with + only to find out that dict was something special
here. ;-)
Then, I use .update only to find out, that it's in-place and I need to
join more than two.
Then, I use some sort of dict comprehension or the dict constructor etc.
Naively, I would say + is what comes to mind easily.
[Chris]
> ...
> So I don't see much value in a "->" operator, except for the
> mere fact that it's different (and thus won't conflict in
> except/with); and the bulk of name bindings in Python put
> the name first.
It does give a natural solution to one of the problematic examples,
because as a ve
On Fri, Apr 13, 2018 at 7:36 AM, Nick Coghlan wrote:
> On 13 April 2018 at 22:35, Chris Angelico wrote:
> > The 'as' syntax already has that going for it. What's the advantage of
> > the arrow over the two front-runners, ':=' and 'as'?
>
> I stumbled across
> https://www.hillelwayne.com/post/equ
On Fri, Apr 13, 2018 at 10:35:59PM +1000, Chris Angelico wrote:
> > On the contrary, it puts the expression first, where it belongs
> > *semi-wink*.
>
> The 'as' syntax already has that going for it. What's the advantage of
> the arrow over the two front-runners, ':=' and 'as'?
Personally, I lik
On 13 April 2018 at 16:13, Guido van Rossum wrote:
> Regarding the precedence of :=, at this point the only acceptable outcome
> for me is one where at the statement level, := and = can be used
> interchangeably and will have the same meaning (except probably we wouldn't
> allow combining both in
Regarding the precedence of :=, at this point the only acceptable outcome
for me is one where at the statement level, := and = can be used
interchangeably and will have the same meaning (except probably we wouldn't
allow combining both in a chained assignment). Because then we can say "and
you can
Oh, I get it now, thanks!
On Fri, Apr 13, 2018 at 2:11 AM, Serhiy Storchaka
wrote:
> 12.04.18 22:42, Andrés Delfino пише:
>
>> I think the update method can (and personally, should) stay unchanged:
>>
>> spam.update(dict(x, y))
>>
>> seems succinct and elegant enough, with the proposed construct
> I'm saying, don't even try to distinguish between the forms with or
> without parens. If we add parens:
>
> with (expr as name):
>
> it may or may not be allowed some time in the future (since it isn't
> allowed now, but there are many requests for it) but if it is allowed,
> it will still me
On Fri, Apr 13, 2018 at 02:30:24PM +0100, Paul Moore wrote:
> On 13 April 2018 at 14:18, Steven D'Aprano wrote:
> > On Fri, Apr 13, 2018 at 09:56:35PM +1000, Chris Angelico wrote:
>
> >> 2) Forbid any use of "(expr as name)" in the header of a 'with' statement
> >
> > You can't forbid it, because
On 13 April 2018 at 22:35, Chris Angelico wrote:
> On Fri, Apr 13, 2018 at 10:22 PM, Steven D'Aprano wrote:
>> On Wed, Apr 11, 2018 at 11:50:44PM +1000, Chris Angelico wrote:
>>
>>> > Previously, there was an alternative _operator form_ `->` proposed by
>>> > Steven D'Aprano. This option is no
On 13 April 2018 at 16:47, Chris Angelico wrote:
> Consider:
>
> pos = -1
> while pos := buffer.find(search_term, pos + 1) >= 0:
> ...
>
> Once find() returns -1, the loop terminates. Should this need to be
> parenthesized?
I've certainly been assuming that cases like that would need to be wr
On 04/13/2018 05:02 AM, Jacco van Dorp wrote:
I must admit I like putting the expression first, though. Even if it's
just to make it harder to mix it up with normal assignment. Perhaps =>
could be used - it's a new token, unlike -> which is used to annotate
return values, it's not legal syntax n
Well this may be crazy sounding, but we could allow left or right
assignment with
name := expr
expr =: name
Although it would seem to violate the "only one obvious way" maxim, at
least it avoids this overloaded meaning with the "as" of "except" and "with"
On Fri, Apr 13, 2018 at 9:29 AM, Ethan
On 13 April 2018 at 14:18, Steven D'Aprano wrote:
> On Fri, Apr 13, 2018 at 09:56:35PM +1000, Chris Angelico wrote:
>> 2) Forbid any use of "(expr as name)" in the header of a 'with' statement
>
> You can't forbid it, because it is currently allowed syntax
It's not currently allowed:
>>> with (
On 04/13/2018 06:18 AM, Steven D'Aprano wrote:
On Fri, Apr 13, 2018 at 09:56:35PM +1000, Chris Angelico wrote:
If we agree that the benefit of putting the expression first is
sufficiently large, or that the general Pythonic look of "expr as name"
is sufficiently desirable (it just looks and re
On Fri, Apr 13, 2018 at 09:56:35PM +1000, Chris Angelico wrote:
> How many times have people asked for "with (expr as name):" to
> be supported, allowing the statement to spread over multiple lines?
> With this syntax, it would suddenly be permitted - with dangerously
> similar semantics.
I see
I have prepared a PEP for better support of PEP 489 multiphase
initialization. It makes it possible for extension types, their methods
to be more specific, to access the state of the module they are defined in.
conversation -
https://mail.python.org/pipermail/import-sig/2015-July/001022.html
PEP
On Fri, Apr 13, 2018 at 10:22 PM, Steven D'Aprano wrote:
> On Wed, Apr 11, 2018 at 11:50:44PM +1000, Chris Angelico wrote:
>
>> > Previously, there was an alternative _operator form_ `->` proposed by
>> > Steven D'Aprano. This option is no longer considered? I see several
>> > advantages with th
On Wed, Apr 11, 2018 at 11:50:44PM +1000, Chris Angelico wrote:
> > Previously, there was an alternative _operator form_ `->` proposed by
> > Steven D'Aprano. This option is no longer considered? I see several
> > advantages with this variant:
> > 1. It does not use `:` symbol which is very visu
Before, I briefly mentioned the idea if this could be unified with
except/with's "as". To the casual observer, they're really similar.
However, their semantics would be totally different, and people don't
seem to like a unification attempt.
A huge argument against "as" would be to prevent confusi
On Fri, Apr 13, 2018 at 9:04 PM, Steven D'Aprano wrote:
> On Wed, Apr 11, 2018 at 03:32:04PM +1000, Chris Angelico wrote:
>
>> In any context where arbitrary Python expressions can be used, a **named
>> expression** can appear. This can be parenthesized for clarity, and is of
>> the form ``(target
On Wed, Apr 11, 2018 at 03:32:04PM +1000, Chris Angelico wrote:
> In any context where arbitrary Python expressions can be used, a **named
> expression** can appear. This can be parenthesized for clarity, and is of
> the form ``(target := expr)`` where ``expr`` is any valid Python expression,
> an
On Fri, Apr 13, 2018 at 9:17 PM, Steven D'Aprano wrote:
> On Thu, Apr 12, 2018 at 07:28:28AM +1000, Chris Angelico wrote:
>
>> Fair enough. Also adding that chained assignment expressions should
>> generally be avoided.
>
> So long as its not a blanket prohibition, I'm good with that.
>
> Also, so
On Thu, Apr 12, 2018 at 07:28:28AM +1000, Chris Angelico wrote:
> Fair enough. Also adding that chained assignment expressions should
> generally be avoided.
So long as its not a blanket prohibition, I'm good with that.
Also, something like this:
spam := 2*(eggs := expression) + 1
should n
On Thu, Apr 12, 2018 at 12:28:23AM +1000, Chris Angelico wrote:
> On Thu, Apr 12, 2018 at 12:11 AM, Paul Moore wrote:
> > On 11 April 2018 at 14:54, Chris Angelico wrote:
> >> Sure, if you're just assigning zero to everything. But you could do
> >> that with a statement. What about this:
> >>
> >
40 matches
Mail list logo
