> 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'"
ers 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 Nieuwlan
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
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
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
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
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
> 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
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
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
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
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
> 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
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
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.
>>> It's more like 'try' but that st
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 that statement has a completely different
>> struc
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 implementing
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 an
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 wanted
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
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
is
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 is
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
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 with
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 then drop the burden of exception classes and only use
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]
It was meant to be a bit more informative about what is wrong.
ProtocolError
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 check
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?
;-)
No, that will go on in other fields, I
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
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 simplicity's sake.
This behaviour isn't really any different
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 being
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-Dev
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't which
to Exception and TerminatingException:
BaseException
+TerminatingException
+ ...
+ Exception
+ ...
+ ControlFlowException
+ GeneratorExit
+ StopIteration
Is my logic flawed (again ;-)?
--eric
Eric Nieuwland
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
Nick Coghlan wrote:
With PEP 315, a do-while loop would look like:
do:
body
while cond:
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
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 implement, I'd say +INF for PEP 315.
It's true
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
import
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 secretly handle them; it simply gets access to them, which
is an entirely
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
confusion with me.
No doubt. However, it's not obvious
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
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 EXCEPTION:
BLOCK2
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
could then be translated to
-1, too confusing.
A matter of taste
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, __error:
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 way to
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): self.f =
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__ method.
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, no finalisation is done.
If EXPR is not an iterator, it is created
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
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 know.
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 unambiguous,
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 out
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 =
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:
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 would
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
Martin v. Löwis wrote:
That's not the full syntax. The full syntax is
[ test for exprlist in testlist list-iter-opt ]
where
test can be an arbitrary expression: and, or, lambda, +, -, ...
exprlist can be a list of expression, except for boolean and
relational expressions (but I think this is
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(self,
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
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. So
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.version_info (0,8,2
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)
71 matches
Mail list logo
