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 + l
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,
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.
F
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 `array.array("i"
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 pe
> 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 out
> 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 in
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 au
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/
Messa
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 withou
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
> T
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 th
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 st
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 an
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 modul
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 level
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 l
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 LO
-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 wa
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 ques
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 cod
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 maili
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
https://mail.python
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 autom
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 deb
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 expre
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 gener
> 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 miss
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 m
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 langua
> 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 migh
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 Py
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 n
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 precisel
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 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 arra
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
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
th
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 DB-AP
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 Sc
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
and
> 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 compreh
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 -- pyth
-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 me
> 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 without
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 doi
46 matches
Mail list logo
