> On 24 Jun 2021, at 10:28, micro codery wrote:
>
> As pointed out already, f-strings and format are subtly different (not
> counting that one can eval and the other cannot). Besides quoting, the
> f-sting mini language has diverged from format's
spam="Spam"
f"{spam=}"
> "spam='Spam'"
h covers that use case and is more flexible than
> f-strings (it supports positional arguments, as well as *args and
> **kwargs).
>
> I think keeping f-strings simple is a better idea.
>
> Best,
>
> Luciano
>
> On Thu, Jun 24, 2021 at 1:30 PM Eric Nieuwland
I didn’t make myself clear, sorry.
The code example was just to give an initial what I was suggesting.
The errors you show demonstrate the example is incomplete.
I’d like them to work.
> On 24 Jun 2021, at 18:37, Martin (gzlist) wrote:
>
> On Thu, 24 Jun 2021 at 17:25, Eric Nieuwla
In a recent discussion with a colleague we wondered if it would be possible to
postpone the evaluation of an f-string so we could use it like a regular string
and .format() or ‘%’.
I found
https://stackoverflow.com/questions/42497625/how-to-postpone-defer-the-evaluation-of-f-strings
and tweake
To add to the suggestions already given in this thread I dug into code I wrote
some time ago.
Offered as an inspiration.
=== missing.py ===
from typing import Any
def MISSING(klass: Any) -> Any:
"""
create a sentinel to indicate a missing instance of a class
:param klass: the class
To add to the suggestions already given in this thread I dug into code I wrote
some time ago.
Offered as an inspiration.
=== missing.py ===
from typing import Any
def MISSING(klass: Any) -> Any:
"""
create a sentinel to indicate a missing instance of a class
:param klass: the clas
Hi all,
Some days back Mark Shannon posted his view/proposal pattern matching on github.
While reading it I realised an intermediate step between matching and variable
assignment might do away with part of the discussion.
I wrote it in an issue with the view/proposal
(https://github.com/markshan
On 5 Sep 2020 Ram Rachum wrote:
>
> Hi everyone,
>
> Sorry if this was proposed already. I looked here
> https://www.python.org/dev/peps/pep-0622/#alternatives-for-constant-value-pattern,
> search for "idea to make lookup semantics the default". I saw that a few
> symbols like $ and ? were pro
> On 4 Aug 2020, at 14:38, Koos Zevenhoven wrote:
>
> Hi everyone,
>
> [ … analysis of design goals and possible solutions, including … ]
>
> Point3D(x=pi, y=SIX, z=value)
It suddenly struck me that
Point3D(x=pi, y=SIX, z into value)
would quite accurately describe what is being esta
On 24/06/2020 20:38, Guido van Rossum wrote:
> Everyone,
>
> If you've commented and you're worried you haven't been heard, please=20
> add your issue *concisely* to this new thread. Note that the following=20
> issues are already open and will be responded to separately; please=20
> don't bother
> On 25 Jul 2020, at 03:44, Rob Cliffe wrote:
>
> Without arguing for or against allowing a capture variable, IMO rather
> than syntax like
>match into :
> it would be far better (and not require a new keyword) to write this as
>with as match :
>
> On 24/06/2020 20:38, Guido van Ro
On 24/06/2020 20:38, Guido van Rossum wrote:
> Everyone,
>
> If you've commented and you're worried you haven't been heard, please=20
> add your issue *concisely* to this new thread. Note that the following=20
> issues are already open and will be responded to separately; please=20
> don't bother
> On 25 Jul 2020, at 03:44, Rob Cliffe wrote:
>
> Without arguing for or against allowing a capture variable, IMO rather
> than syntax like
> match into :
> it would be far better (and not require a new keyword) to write this as
> with as match :
>
> On 24/06/2020 20:38, Guido van
> From: Baptiste Carvello
> Subject: [Python-Dev] Re: PEP 622 constant value syntax idea
>
> What about simply "is", which is already a keyword?
>
> AFAIK "is" has no meaning as a prefix operator as of now, so hopefully
> it would not make the grammar ambiguous (how can one check that for sure?
Rhodri James wrote:
> Eric Nieuwland wrote:
>
>> Just after I hit ‘send’ it dawned on me it might be preferable to make that
>>
>> match poly:
>> p0 = Point(x0, y0)
>> p1 = Point(x1, y1)
>> p2 = Point(x2, y2)
>> case Polygon(p0, p
Greg Ewing wrote:
> Eric Nieuwland wrote:
>
>> ...
>> match poly:
>> p0 = Point(x0, y0)
>> p1 = Point(x1, y1)
>> p2 = Point(x2, y2)
>> case Polygon(p0, p1, p2):
>> …
>>
>
> Interesting idea, but what ha
On 11 Jul 2020, at 21:03, Eric Nieuwland wrote:
> What I meant to say is that as I read the current PEP text there would be a
> confusing difference between
>
> match poly:
> case Polygon(Point(x0, y0), Point(x1, y1), Point(x2, y2)):
>
> On 10 Jul 2020, at 18:28, Jim Baker wrote:
>
> On Fri, Jul 10, 2020, 9:16 AM Eric Nieuwland wrote:
>
>> On 10 Jul 2020, at 01:51, Jim Baker wrote:
>> ...
>> Explicit namespacing (if a constant) or using a guard (if a variable) seems
>> to be the r
> On 10 Jul 2020, at 01:51, Jim Baker wrote:
>
>
> On Thu, Jul 9, 2020 at 1:42 PM Eric Nieuwland <mailto:eric.nieuwl...@gmail.com>> wrote:
> Much of the discussion seems to focus on how to distinguish between a
> variable as a provider of a value and a variab
> On 10 Jul 2020, Stefano Borini wrote:
>
> Just my 2 cents, I find it kind of annoying that the whole structure
> requires two levels of indentation to actually reach the operational
> code.
> This would be a first in python.
>
> I would prefer an option akin to if elif elif else where each bl
Much of the discussion seems to focus on how to distinguish between a variable
as a provider of a value and a variable as receiver of a matched value.
In normal Python syntax a variable in an expression provides a value, please
let’s keep that unchanged.
So it seems to me we should explicitly m
I wrote:
>
> Guido van Rossum wrote:
>
>> Eric Nieuwland wrote:
>>
>>> I have some doubt about the keyword: ‘match' seems to be at odds with
>>> 'for', 'while', 'with', 'if' as it is more of an action.
Guido van Rossum wrote:
> Eric Nieuwland wrote:
>
>> I have some doubt about the keyword: ‘match' seems to be at odds with
>> 'for', 'while', 'with', 'if' as it is more of an action.
>> It's more like 'try' but
Great PEP!
I have some doubt about the keyword: ‘match’ seems to be at odds with ‘for’,
‘while’, ‘with’, ‘if’ as it is more of an action.
It’s more like ‘try’ but that statement has a completely different structure.
Not a native speaker I don’t have a reasonable alternative, though.
Travis Oliphant wrote:
> PEP: ###
> Title: Allowing any object to be used for slicing
> [...]
> Rationale
>
>Currently integers and long integers play a special role in slice
>notation in that they are the only objects allowed in slice
>syntax. In other words, if X is an object implem
On 5 feb 2006, at 18:43, Guido van Rossum wrote:
> After so many attempts to come up with an alternative for lambda,
> perhaps we should admit defeat. I've not had the time to follow the
> most recent rounds, but I propose that we keep lambda, so as to stop
> wasting everybody's talent and time on
Nick Coghlan wrote:
>> I believe that usage of a keyword with the name of a Greek letter also
>> contributes to people considering something broken.
>
> Aye, I agree there are serious problems with the current syntax. All
> I'm
> trying to say above is that I don't believe the functionality itself
Martin v. Löwis wrote:
> I believe that usage of a keyword with the name of a Greek letter also
> contributes to people considering something broken.
QOTW! ;-)
--eric
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/li
Nick Coghlan wrote:
> That's like saying "it's not the same because '(x*x def (x)' creates a
> function while '(x*x for x in seq)' creates a generator-iterator".
> Well,
> naturally - if the expression didn't do something different, what
> would be the
> point in having it?
;-)
Naturally. I just
On 4 feb 2006, at 3:18, Nick Coghlan wrote:
> All I'm suggesting is that a similarly inspired syntax is worth
> considering when it comes to deferred expressions:
>
>def f(x):
> return x*x
>
> => f = (x*x def (x))
It's not the same, as x remains free whereas in g = [x*x for x in seq]
x i
On 1 feb 2006, at 19:14, BJörn Lindqvist wrote:
> I've submitted an updated version of the PEP. The only major change is
> that instead of the method atime and property getatime() there is now
> only one method named atime(). Also some information about the string
> inheritance problem in Open Iss
Good stuff. Some suggestions:
> def joinpath(self, *args): ...
I suggest append() or extend() as join*() sort of suggest join() as
provided by strings, which does something quite different
> def splitall(self): ...
and this may renamed split(), as it is quite similar to split() a
I wrote:
> all() can be terminated at the first false element. For very long
> sequences this has important performance benefits. Besides, it makes
> all(seq,pred) the equivalent of pred(seq[0]) and pred(seq[1]) and
> pred(seq[2]) and ...
then, Martin v. Löwis wrote:
>
> And so does the version w
Alex Martelli wrote:
> On Dec 27, 2005, at 12:45 PM, Valentino Volonghi aka Dialtone wrote:
> ...
>> any(iterable, test=bool) and all(iterable, test=bool)
> ...
>> any(some_objects, test=operator.attrgetter('some_attribute'))
>
> Why would that be better than
> any(o.some_attribute for o in
Michael Chermside wrote:
> Guido writes:
>> I find "AttributeError: __exit__" just as informative.
>
> Eric Nieuwland responds:
>> I see. Then why don't we unify *Error into Error?
>> Just read the message and know what it means.
>> And we could th
Guido van Rossum wrote:
> [Eric "are all your pets called Eric?" Nieuwland]
>>>> Hmmm... Would it be reasonable to introduce a ProtocolError
>>>> exception?
>
> [Guido]
>>> And which perceived problem would that solve?
>
> [Eric]
>&g
Guido van Rossum wrote:
> On 10/25/05, Eric Nieuwland <[EMAIL PROTECTED]> wrote:
>> Hmmm... Would it be reasonable to introduce a ProtocolError exception?
>
> And which perceived problem would that solve? The problem of Nick &
> Guido disagreeing in public?
;-)
Guido van Rossum wrote:
> It is true though that AttributeError is somewhat special. There are
> lots of places (perhaps too many?) where an operation is defined using
> something like "if the object has attribute __foo__, use it, otherwise
> use some other approach". Some operations explicitly ch
Nick Coghlan wrote:
> Eric Nieuwland wrote:
>> What happens to
>>
>> with 40*13+2 as X:
>> print X
>
> It would fail with a TypeError because the relevant slot in the type
> object
> was NULL - the TypeError checks aren't shown for simpli
Nick Coghlan wrote:
> 1. Amend the statement specification such that:
>
>with EXPR as VAR:
>BLOCK
>
> is translated as:
>
>abc = (EXPR).__with__()
>exc = (None, None, None)
>VAR = abc.__enter__()
>try:
>try:
>BLOCK
>
Raymond Hettinger wrote:
>> I think it's convenient but also rather odd that split() with a static
>> string argument was moved from module string to a method in class str,
>> while split() with a regexp has remained in module re.
>
> I don't see what you find odd. With str and unicode objects bei
On 30 aug 2005, at 17:40, Antoine Pitrou wrote:
>> Neat!
>> +1 on regexps as an argument to partition().
>
> It sounds better to have a separate function and call it re.partition,
> doesn't it ?
> By the way, re.partition() is *really* useful compared to re.split()
> because with the latter you don
Pierre Barbier de Reuille wrote:
> Or you want to have some "partition" method which accept regular
> expressions:
>
> head, sep, tail = some_str.partition(re.compile(sep+'.'*offset))
Neat!
+1 on regexps as an argument to partition().
--eric
___
Python
I have some use cases with:
cut_at = some_str.find(sep)
head, tail = some_str[:cut_at], some_str[cut_at:]
and:
cut_at = some_str.find(sep)
head, tail = some_str[:cut_at], some_str[cut_at+offset:] # offset !=
len(sep)
So if partition() [or whatever it'll be called]
trolFlowException class, right
next to Exception and TerminatingException:
BaseException
+TerminatingException
+ ...
+ Exception
+ ...
+ ControlFlowException
+ GeneratorExit
+ StopIteration
Is my logic f
Raymond Hettinger wrote:
> With 343 accepted, we can now add __enter__() and __exit__() methods to
> objects.
>
> What term should describe those objects in the documentation?
Witty objects?
___
Python-Dev mailing list
Python-Dev@python.org
http://mail
Guido van Rossum wrote:
> On 6/14/05, Eric Nieuwland <[EMAIL PROTECTED]> wrote:
>> From Programming Languages 101 I remember this construct in Algol 68.
>> It was then claimed to be *the* universal loop construct. If that is
>> true __and__ it is easy to implemen
Nick Coghlan wrote:
> With PEP 315, a do-while loop would look like:
>
>do:
>
>while :
>pass
>
> But then, I'm reasonably happy with the 'break out of an infinite
> loop' approach, so *shrug*.
From Programming Languages 101 I remember this construct in Algol 68.
It was th
Skip Montanaro wrote:
> The main technical challenge seems to be
> backward compatibility. You need to support both flat ("import
> urllib") and
> packaged namespaces ("from www import urllib"), possibly within the
> same
> application. That is, postulating a www package, if I execute
>
> i
On 2 jun 2005, at 22:12, Phillip J. Eby wrote:
> At 10:04 PM 6/2/2005 +0200, Eric Nieuwland wrote:
>> I was thinking about 'try EXPR [as VAR]:' as a 'try' that handles
>> uncaught exceptions by forwarding it to EXPR's __exit__ method. No
>> confu
Phillip J. Eby wrote:
> At 10:00 PM 6/1/2005 +0200, Eric Nieuwland wrote:
>> Phillip J. Eby wrote:
>> > -1, too confusing.
>>
>> A matter of taste, I guess. IMHO 'with' secretly handling exceptions
>> is
>> confusing.
>
> It doesn't s
Phillip J. Eby wrote:
> At 08:46 PM 6/1/2005 +0200, Eric Nieuwland wrote:
>> If I look at the translation it an augmented 'try'.
>> with EXPR as VAR:
>> BLOCK1
>> except EXCEPTION:
>> BLOCK2
>> coul
Eric Nieuwland wrote:
> If I look at the translation it an augmented 'try'.
> with EXPR as VAR:
> BLOCK1
> except EXCEPTION:
> BLOCK2
Oops, that should read:
try EXPR as VAR:
BLOCK1
except EXCEPTIO
Nice going! But ...
Could we extend the 'try' syntax for this instead of introducing
'with'? If I look at the translation it an augmented 'try'.
with EXPR as VAR:
BLOCK1
except EXCEPTION:
BLOCK2
could then be translated to
abc = EXPR
Guido van Rossum wrote:
> Consider
>
> try:
> BLOCK
> except EXCEPTION, VAR:
> HANDLER
>
> I'd like to see this translated into
>
> try:
> BLOCK
> except EXCEPTION, VAR:
> __context = VAR
> try:
> HANDLER
> except Exception
Shane Hathaway wrote:
> Here is example A, a non-looping block statement using "try":
>
> text = 'diamond'
> for fn in filenames:
> try opening(fn) as f:
> if text in f.read():
> print 'I found the text in %s' % fn
> break
That's a pretty
Guido van Rossum wrote:
> class locking:
> def __init__(self, lock): self.lock = lock
> def __enter__(self): self.lock.acquire()
> def __exit__(self, *args): self.lock.release()
>
> class opening:
> def __init__(self, filename): self.filename = filename
> def __enter__(self): se
Greg Ewing wrote:
> Ron Adam wrote:
>> There seems to be some confusion as to weather or
>> not 'for's will do finalizing. So I was trying to stress I think
>> regular 'for' loops should not finalize. They should probably give an
>> error if an object with an try-finally in them or an __exit__ met
Josiah Carlson wrote:
> The argument over whether blocks should loop, I believe has been had;
> they should. The various use cases involve multi-part transactions and
> such.
Then it is not so much looping but more pushing forward the state of
the state of the block's life-cycle?
This might by a
Josiah Carlson wrote:
> Eric Nieuwland <[EMAIL PROTECTED]> wrote:
>> I suggested to create AN ITERATOR FOR THE LIST and destroy that at the
>> end. The list itself remains untouched.
>
> My mistake, I did not understand your use of pronouns.
And, rereading my post, I
Josiah Carlson wrote:
> Eric Nieuwland <[EMAIL PROTECTED]> wrote:
>> I don't know. Using 'del' in that place seems ackward to me.
>> Why not use the following rule:
>> for [VAR in] EXPR:
>> SUITE
>> If EXPR is an iterator,
Nick Coghlan wrote:
> [...]
> The whole PEP draft can be found here:
> http://members.iinet.net.au/~ncoghlan/public/pep-3XX.html
> [...]
> Used as follows::
>
> for del auto_retry(3, IOError):
> f = urllib.urlopen("http://python.org/";)
> print f.read()
I don't
Guido van Rossum wrote:
> try_stmt: 'try' ':' suite
> (
> except_clause ':' suite)+
> ['else' ':' suite] ['finally' ':' suite]
> |
> 'finally' ':' suite
> )
>
> There is no real complexity in this grammar, it's unam
Reinhold Birkenfeld wrote:
> Changes to the grammar
>
> The grammar for the try statement, which is currently
>
> try_stmt: ('try' ':' suite (except_clause ':' suite)+
>['else' ':' suite] | 'try' ':' suite 'finally' ':'
> suite)
>
> would have to become
>
>
Ronald Oussoren wrote:
> What's bothering me about the proposed semantics is that block
> statement behaves like a loop while most use cases do no looping
> whatsoever.
> Furthermore the it doesn't feel like loop either. In all three
> examples on this page I'd assume
> that the break would break
Reinhold Birkenfeld wrote:
Shane Hathaway wrote:
PEP 340 seems to punish people for avoiding the parentheses:
transaction = begin_transaction()
transaction:
db.execute('insert 3 into mytable')
transaction:
db.execute('insert 4 into mytable')
I expect that only '3' would be inserted in mytable.
Guido van Rossum wrote:
> [Skip Montanaro]
>> To the casual observer, this
>> looks like "break" should break out of the loop:
>>
>> while True:
>> block synchronized(v1):
>> ...
>> if v1.field:
>> break
>> time.sleep(1)
>
> Without 'block
I've been away for a while and just read through the PEP 340 discussion
with growing amazement.
Pierre Barbier de Reuille wrote:
> As far as I understand it,
> iterator-for-blocks and iterator-for-loops are two different beasts.
Right!
> To try being as clear as possible, I would say the iterato
Guido van Rossum wrote:
tri = self.subcalculation("The quick brown fox jumps over the lazy
dog")
self.disentangle(0x40, tri, self.indent+1)
IMO this is clearer, and even shorter!
But it clutters the namespace with objects you don't need. So the
complete equivalent would be more close to:
tri =
On 26 mrt 2005, at 21:36, Josiah Carlson wrote:
Eric Nieuwland <[EMAIL PROTECTED]> wrote:
Given the ideas so far, would it possible to:
def meta(cls):
...
@meta
class X(...):
...
It is not implemented in Python 2.4. From what I understand, making it
happen in Python 2.5 wou
Given the ideas so far, would it possible to:
def meta(cls):
...
@meta
class X(...):
...
??
--eric
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/ma
Donovan Baarda wrote:
The fact that partial reads/writes are possible without non-blocking
mode changes things a fair bit. Also, the lack of fnctl support in
Windows needs to be taken into account too.
... [ snip ] ...
The lack of support on win32 for non-blocking mode, combined with the
reduced ne
Nicholas Jacobson wrote:
IIRC, Guido once mentioned that he regretted not
setting function docstrings to come before the
function declaration line, instead of after.
[ examples deleted ]
I think that commenting the function before its
declaration, at the same tabbed point, increases the
code's read
Martin v. Löwis wrote:
That's not the full syntax. The full syntax is
[ for in ]
where
can be an arbitrary expression: and, or, lambda, +, -, ...
can be a list of expression, except for boolean and
relational expressions (but I think this is further constrained
semantically)
list a list
Guido van Rossum wrote:
I think the conclusion should be that sum() is sufficiently
constrained by backwards compatibility to make "fixing" it impossible
before 3.0. But in 3.0 I'd like to fix it so that the 2nd argument is
only used for empty lists.
Which is not unlike the get() method of dicts. S
Gareth McCaughan wrote:
I'd like it, and my reason isn't "just to save typing".
There are two reasons.
1 Some bit of my brain is convinced that [x in stuff if condition]
is the Right Syntax and keeps making me type it even though
I know it doesn't work.
2 Seeing [x for x in stuff if con
Greg Ewing wrote:
Guido van Rossum wrote:
- the identity (defaulting to 0) if the sequence is empty
- the first and only element if the sequence only has one element
- (...(((A + B) + C) + D) + ...) if the sequence has more than one
element
While this might be reasonable if the identity
argument i
Neat! But please add something to the __doc__ so we can also see it was
changed. E.g.
self.__doc__ = other.__doc__ + os.linesep + "*** deprecated ***"
On 12 mrt 2005, at 5:25, Nick Coghlan wrote:
I like "update_meta"
Patch against current CVS added to SF with the behaviour:
def update_meta(sel
I think the discussion should separate numeric calculation and truth
value calculation.
Numeric calculation need to run through all elements, with the order
possibly important.
Truth value calculation (as per any() and all()) may terminate before
all elements have been seen.
Finally, any(), all(
Martin v. Löwis wrote:
Eric Nieuwland wrote:
Would it be an idea to submit a PEP for extending the 'import'
keyword?
No. Normally, packages should aim for backwards compatibility, so that
applications would only want to specify a minimum version, such as
import xml
assert xml.ve
Hi all,
On 27 dec 2004, at 19:27, Chris Barker wrote:
Robin has added versioning to the latest wxPython, and I. for one am
ecstatic. It works great for me. I am generally using 2.5.3, but have
2.4.2 installed, and a number of my apps depend on it (on Linux
anyway, it's pretty useless on OS-X)
81 matches
Mail list logo
