Comprehension are very much based on the idea of *declarative* data
collections. That's their entire reason for being. In general, one expects
comprehension to be side-effect free and just build a collection according
to declared rules. Obviously I know many ways to smuggle in side effects,
but
> The weird block structures inside comprehension reads terribly even in the
> trivial case shown
David, it's fine if you have that opinion, but you're replying specifically to
my post where I asked someone to elaborate on that kind of opinion, so it
bothers me that you just restated it
-100. The weird block structures inside comprehension reads terribly even
in the trivial case shown, and looks worse the more structures are inside
it. We have functions. They are great. Let's use those.
On Sat, Feb 22, 2020, 2:01 AM Alex Hall wrote:
> > You might be able to avoid calling the
Andrew, you raise a good point that I hadn't considered. I think you're right
that yield inside an expression shouldn't be allowed, to avoid confusion. If we
found a good reason to allow it we could change it later.
___
Python-ideas mailing list --
> You might be able to avoid calling the method twice using the walrus
operator.
I specifically discussed the walrus operator solution, but both you and Dominik
Vilsmeier seem to have missed that.
> I'd use the list constructor with a
> named function anyway, rather than inlining it in a
On Feb 21, 2020, at 19:22, David Mertz wrote:
>
> Of course, those functions *could* do something more than identity if they
> wanted to.
And the nice thing is that if you only later need to make it do something,
there’s no refactoring needed—just `SQL=lru_cache(conn.compile)` or whatever
On Fri, Feb 21, 2020 at 10:19:37PM -0500, David Mertz wrote:
> On Fri, Feb 21, 2020 at 9:26 PM Steven D'Aprano wrote:
>
> > > And what's so special about SQL over, say, regular expressions, XML,
> > > JSON, YAML, Markdown, ReST, LaTeX, etc? I might want to use the s''
> > > prefix for embedded
OMG, please no! Please, for all that is decent, do not use an ORM in any
code I will ever need to look at!
The SQL injection attack is just silly if you don't run arbitrary strings.
Don't ever do that. But running a query that is hard coded as text, with
just a few parameters filled in (the
I'm not against your proposal at this point, but I think you can
already do the first example:
clean = [line.strip() for line in lines if line.strip()]
You might be able to avoid calling the method twice using the walrus
operator. For any operation more complex than that (ie, more complex
On Sat, Feb 22, 2020 at 2:38 PM Bruce Leban wrote:
>
> First, as to SQL specifically, writing literal SQL in code is a bad idea.
> It's easy to have bugs, especially sql injection. You should use an ORM at
> the very least a SQL builder. Instead of:
>
> sf"select * from sometable where name
On Fri, Feb 21, 2020 at 02:42:16PM +0200, Serhiy Storchaka wrote:
> 21.02.20 10:36, Steven D'Aprano пише:
> >On my machine, at least, constructing a bytes object first followed by
> >an array is significantly faster than the alternative:
> >
> >[steve@ando cpython]$ ./python -m timeit -s "from
On Fri, Feb 21, 2020 at 5:53 AM wrote:
> The idea is to add a new string prefix 's' for SQL string. This string
> doesn't do anything in Python, unlike b"" or f"" strings, but interactive
> Python shells like IPython or Jupyter can parse the following characters as
> SQL syntax instead of Python
On Fri, Feb 21, 2020 at 9:26 PM Steven D'Aprano wrote:
> > And what's so special about SQL over, say, regular expressions, XML,
> > JSON, YAML, Markdown, ReST, LaTeX, etc? I might want to use the s''
> > prefix for embedded Scheme code rather than SQL.
>
> Um, regular expressions are not
On Sat, Feb 22, 2020 at 11:58:58AM +1100, Steven D'Aprano wrote:
> And what's so special about SQL over, say, regular expressions, XML,
> JSON, YAML, Markdown, ReST, LaTeX, etc? I might want to use the s''
> prefix for embedded Scheme code rather than SQL.
*cough*
Um, regular expressions are
On Sat, Feb 22, 2020 at 12:54 AM wrote:
>
> The idea is to add a new string prefix 's' for SQL string. This string
> doesn't do anything in Python, unlike b"" or f"" strings, but interactive
> Python shells like IPython or Jupyter can parse the following characters as
> SQL syntax instead of
> On Feb 21, 2020, at 15:34, Greg Ewing wrote:
>
> On 22/02/20 11:45 am, Andrew Barnert via Python-ideas wrote:
>> there’s no reason you can’t write `[(yield None) for _ in range(3)]` to
>> gather the first three values sent into your generator
>
> Currently this doesn't quite do what you
On Fri, Feb 21, 2020 at 04:26:01AM -, minecraft2...@gmail.com wrote:
> The idea is to add a new string prefix 's' for SQL string. This string
> doesn't do anything in Python
That ought to rule it out then. Why are we adding syntax to the language
that doesn't get used anywhere in the
On Sat, Feb 22, 2020 at 10:32 AM Greg Ewing wrote:
>
> On 22/02/20 11:45 am, Andrew Barnert via Python-ideas wrote:
> > there’s no reason you can’t write `[(yield None) for _ in range(3)]` to
> > gather the first three values sent into your generator
>
> Currently this doesn't quite do what you
> Currently this doesn't quite do what you might expect.
> It doesn't make the enclosing function into a generator,
> it make the list comprehension itself a generator:
>
> >>> def f():
> ... return [(yield x) for x in range(10)]
> ...
> >>> g = f()
> >>> g
> . at 0x6b396c>
> >>>
>
>
Am I
On 22/02/20 11:45 am, Andrew Barnert via Python-ideas wrote:
there’s no reason you can’t write `[(yield None) for _ in range(3)]` to gather
the first three values sent into your generator
Currently this doesn't quite do what you might expect.
It doesn't make the enclosing function into a
On Feb 20, 2020, at 23:56, Alex Hall wrote:
>
> This is a proposal for a new syntax where a comprehension is written as the
> appropriate brackets containing a loop which can contain arbitrary statements.
What happens if there’s a yield expression (that isn’t just ignored and used as
an
Last resort logger works only if no handlers are set.
NullHandler for example is used on most libraries in order to prevent
setting up the logging system, but it can cause errors not to show.
Also, LastResort is set for the "Warning" level. -L will give you
the flexibility you need in order to
Ok... Though some kind of logging configuration, even a default one, is always
present. For example, when logging.info() module method --or some one similar--
is called for the first time, it creates a basic logger with a last resort
handler if none exists --at least up to my knowledge. So
So, are you suggesting that -L must create a basic logger with the given
logging level? Is it right? It can work...
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
Thanks Ricky :)
Technically, if yield is always required, it would have to look like this:
[
for row in matrix:
yield [
for cell in row:
yield f(cell)
]
]
___
Python-ideas
I'll lend a supportive voice here: I like the proposal and would probably
make use of this kind of syntax quite a bit, but I think the requirement of
yield is definitely a necessity. Too much ambiguity without it.
And adding the yield, IMO, doesn't clutter things up too badly. Using one
of the
OK, I think the verdict is in and I will not try to debate it.
> Does opening a [{( and having any : statements inside
> just imply one more indentation level? Or can the statements inside
> be validly less indented than the line containing the = [...
> opening bracket?
I think this is a fun
-L will act as logging.basicConfig(level=level), but on a temporary
basis, much like -W sets warning's filters.
If you don't setup logging, or don't want to (cause you're checking some
library functions), this will be super handy.
If you do setup logging, it has the same caveats as setting the
This idea by jdveiga seems like a good one. It doesn't require any change
in Python, although conceivably an informational PEP could make some
specific convention a recommendation.
The thing is, SQL isn't THAT special. I use SQL a lot myself, so would
benefit from such support. But there are
On Fri, Feb 21, 2020 at 12:43 AM Steven D'Aprano
wrote:
> On Thu, Feb 20, 2020 at 02:19:13PM -0800, Stephan Hoyer wrote:
>
> > > > Strong +1 for an array.zeros() constructor, and/or a lower level
> > > array.empty() which doesn't pre-fill values.
> > >
> > > So it'd be a shorthand for something
On 2020-02-21 08:45, jdve...@gmail.com wrote:
Nice idea... in principle.
But, what if my program has several loggers with several handlers each having
its own logging info level? Would the Python's interpreter CLI argument (or the
ENV variable) override all loggers and handlers logging
On Feb 21, 2020, at 05:54, minecraft2...@gmail.com wrote:
>
> lUnfortunately when I try to type s"select * from table" it gave me syntax
> error instead, so I think this need to be implemented in Python language
> itself instead of module
Well, it can be implemented with a module if your
Nice idea... in principle.
But, what if my program has several loggers with several handlers each having
its own logging info level? Would the Python's interpreter CLI argument (or the
ENV variable) override all loggers and handlers logging levels? Why should CLI
/ ENV override those loggers
May I suggest mark string with comments instead of populating the interpreter
with lost of "string" templates?
Something like
"SELECT * FROM table" # string: sql
Or
"spam ham eggs # template: html
IDEs can read this comment and highlight (and do some other static checks) on
the commented
I am disliking this proposal at all, more from a gut-feel than anything.
But then I just did `import this` and pasted bellow the
parts I think this violates.
While we all have to keep in mind that the "zen of Python" are
more guidelines than absolute standards, they still are
_good_ guidelines
Like PEP-501 https://www.python.org/dev/peps/pep-0501/ ?
Le ven. 21 févr. 2020 à 15:28, Jonathan Fine a écrit :
>
> Hi
> I like the problem, but not the solution suggested.
> --
> Jonathan
> ___
> Python-ideas mailing list -- python-ideas@python.org
>
This syntax basically allows to put any code from functions into comprehensions. This enables people to write fewer functions at the cost of more complex comprehensions. But functions are a good idea indeed:* They have a name and from that name it should be clear what that function does
Hi
I like the problem, but not the solution suggested.
--
Jonathan
___
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/
The idea is to add a new string prefix 's' for SQL string. This string doesn't
do anything in Python, unlike b"" or f"" strings, but interactive Python shells
like IPython or Jupyter can parse the following characters as SQL syntax
instead of Python syntax and give SQL syntax highlighting and
> Yes but then it's the same as defining a generator-function.
List comprehensions are already the same as other things, but they're nice
anyway. `lambda` is the same as defining a function, but it's nice too.
Syntactic sugar is helpful sometimes. I think this:
clean = [
for line
> Would you feel better if `yield` was always required?
Yes but then it's the same as defining a generator-function.
> For almost all the examples I've provided a corresponding equivalent in the
> current syntax, so are you saying that you're still confused now or that you
> can't figure it
21.02.20 10:36, Steven D'Aprano пише:
On my machine, at least, constructing a bytes object first followed by
an array is significantly faster than the alternative:
[steve@ando cpython]$ ./python -m timeit -s "from array import array"
"array('i', bytes(50))"
100 loops, best of 5: 1.71 msec
On Feb 21, 2020, at 00:46, Steven D'Aprano wrote:
>
>
> Got some actual measurements to demonstrate that initialising the array
> is a bottleneck? Especially for something as small as 64, it seems
> unlikely. If it were 64MB, that might be another story.
>
> What's wrong with
Antoine Rozo wrote:
> I think this syntax is very hard to read because the
> yielding-expression can be anywhere in the block and there is nothing
> to identify it.
Would you feel better if `yield` was always required?
> Even in your examples I can't figure out which expression will be
> used.
On Thu, Feb 20, 2020 at 02:19:13PM -0800, Stephan Hoyer wrote:
> > > Strong +1 for an array.zeros() constructor, and/or a lower level
> > array.empty() which doesn't pre-fill values.
> >
> > So it'd be a shorthand for something like this?
> >
> > >>> array.array("i", bytes(64))
> > array('i', [0,
Hi,
I think this syntax is very hard to read because the
yielding-expression can be anywhere in the block and there is nothing
to identify it.
Even in your examples I can't figure out which expression will be
used. What if I call a function somewhere in the block?
Can't you just use generators +
46 matches
Mail list logo
