> On 14 Jul 2019, at 22:46, Andrew Barnert wrote:
>
>>> First, the function only gets the names, not live expressions that it can
>>> eval late, or in a modified environment, etc., so it only handles this
>>> case, not cases like df[year>1990].
>>
>> I don't understand how it's not the full
On Jul 15, 2019, at 00:27, Anders Hovmöller wrote:
>
>
>> On 14 Jul 2019, at 22:46, Andrew Barnert wrote:
>>
>> But this doesn’t in any way help with late eval.
>
> Ah. Now I'm with you. Yes this is different but it also seems strange that we
> wouldn't just use a lambda or a function for t
14.07.19 23:20, Nima Hamidi пише:
Thank you for your question! It would depend on the implementation of
DataFrame.__getitem__. Note that BoundExpression is endowed with locals and globals of
the callee. So, it does have access to x in your example. I think the way that data.table
in R handles
On Jul 15, 2019, at 01:27, Serhiy Storchaka wrote:
>
> 14.07.19 23:20, Nima Hamidi пише:
>> Thank you for your question! It would depend on the implementation of
>> DataFrame.__getitem__. Note that BoundExpression is endowed with locals and
>> globals of the callee. So, it does have access to x
On Mon, Jul 15, 2019 at 7:17 PM Andrew Barnert via Python-ideas
wrote:
>
> Consider the case where dt is a join of two tables d1 and d2. Today you can
> write dt[d1.price * d2.taxrate < x]. With the proposed new feature, you could
> presumably write dt[price * taxrate < x], and get an exception
Hi all,
What would you think if we could write our code using unicode ?
It would be especially useful for scientific programming (we could use the
greek letters), it could also be nice to use emojis for some variables. I
don't see any bad consequences (apart from people that would use misleading
ch
On 7/15/2019 7:34 AM, Adrien Ricocotam wrote:
Hi all,
What would you think if we could write our code using unicode ?
It would be especially useful for scientific programming (we could use
the greek letters), it could also be nice to use emojis for some
variables. I don't see any bad consequenc
On Mon, Jul 15, 2019 at 9:37 PM Adrien Ricocotam wrote:
>
> Hi all,
> What would you think if we could write our code using unicode ?
> It would be especially useful for scientific programming (we could use the
> greek letters), it could also be nice to use emojis for some variables. I
> don't s
Oh ok !
I tried with some unicodes (🔥) but it didn't work. So it's only a subset
as described in PEPs ?
What about extending it ?
Le lun. 15 juil. 2019 à 13:41, Chris Angelico a écrit :
> On Mon, Jul 15, 2019 at 9:37 PM Adrien Ricocotam
> wrote:
> >
> > Hi all,
> > What would you think if we co
On Jul 15, 2019, at 04:43, Adrien Ricocotam wrote:
>
> Oh ok !
> I tried with some unicodes (🔥) but it didn't work. So it's only a subset as
> described in PEPs ?
> What about extending it ?
I’m pretty sure that the docs explain that the subset of characters that Python
allows in identifiers i
On 15/07/2019 12:34, Adrien Ricocotam wrote:
it could also be nice to use emojis for some variables
For values of "nice" I personally find horrifying :-)
Seriously though, the PEP defines valid characters for names by their
unicode categories (plus a few special cases for backward
compatibil
> On 15 Jul 2019, at 10:23, Andrew Barnert wrote:
>
>> On Jul 15, 2019, at 00:27, Anders Hovmöller wrote:
>>
>>
>>> On 14 Jul 2019, at 22:46, Andrew Barnert wrote:
>>>
>>> But this doesn’t in any way help with late eval.
>>
>> Ah. Now I'm with you. Yes this is different but it also seems
On Mon, Jul 15, 2019 at 01:34:02PM +0200, Adrien Ricocotam wrote:
> Hi all,
> What would you think if we could write our code using unicode ?
> It would be especially useful for scientific programming (we could use the
> greek letters),
We've been able to do that since about 2007.
https://www.py
> In the future, before making suggestions for new features, you should do
some research into what is already possible, and whether it has already
been suggested before
I did some but couldn't find anything apart using unicode in strings. I
didn't mention in this mail but I used to in my first try
On 7/15/19 8:54 AM, Steven D'Aprano wrote:
= .(, )
I call foul. At least tentatively. For the moment.
http://www.unicode.org/reports/tr31/ and
http://www.unicode.org/reports/tr39/ specifically exclude
private use characters, like U+E24C, from identifiers.
And
On 7/15/2019 7:43 AM, Adrien Ricocotam wrote:
Oh ok !
I tried with some unicodes (🔥) but it didn't work. So it's only a
subset as described in PEPs ?
Correct.
What about extending it ?
The PEP has a rationale about why it works like it does. If you want to
extend it, you should be prepare
On Mon, 15 Jul 2019 at 14:33, Dan Sommers
<[email protected]> wrote:
>
> On 7/15/19 8:54 AM, Steven D'Aprano wrote:
> > = .(, )
>
> I call foul. At least tentatively. For the moment.
That was a demo (he used private area characters to ensure getti
Adrien - please take note that since you already wrote about
"everybody could update their environment and editors" to support unicode,
things like what you want (emojis in identifiers) can be supported
at programming editor (and plug-ins and extensions for those) level -
without impairing anyone
Hello,
It is likely not the first time such a proposal is being made but let's
see.
I would like to explicitly set variable names in list comprehensions using
a where keyword, eventually set after the if keyword:
[price for item in basket if price is not None where price := item.get(
'price')]
It's easy, just use vim! (with conceal plugin). I haven't changed anything
other than keywords and built-ins, but the plugin is happy to replace any
other sequence or pattern.
On Mon, Jul 15, 2019 at 9:26 AM Joao S. O. Bueno
wrote:
> Adrien - please take note that since you already wrote abo
This comes up pretty often. Every example can be replaced by a loop over a
single item list. It's a bit idiomatic, but not difficult. Many, as you
note, can use the new walrus operator instead.
[price for price in [item.get('price')] for item in basket if price is not
None]
On Mon, Jul 15, 201
On 15/07/2019 16:18, Fabrizio Messina wrote:
Hello,
It is likely not the first time such a proposal is being made but let's
see.
I would like to explicitly set variable names in list comprehensions using
a where keyword, eventually set after the if keyword:
This is what assignment expressions
Greetings,
Just like builtins module, would it be a good idea to have a stdlib module
so that we can know all modules in the std lib (just like builtins let us
know builtins)?
Abdur-Rahmaan Janhangeer
Mauritius
___
Python-ideas mailing list -- python-id
On Jul 15, 2019, at 11:47, Abdur-Rahmaan Janhangeer
wrote:
>
> Greetings,
>
> Just like builtins module, would it be a good idea to have a stdlib module so
> that we can know all modules in the std lib (just like builtins let us know
> builtins)?
Is it just the names that are in stdlib, or s
Hello list,
I sent an email to this list two or three months ago about the same idea.
In that discussion, there were both skepticism and support. Since I had
some time during the previous long weekend, I have made my idea more
concrete and I thought I would try with the list again, after having ru
I think this may be a worthwhile idea — after all, “namespaces are one
honking great idea”
This would be an opportunity to clearly define the “standard library” as
something other than “all the stuff that ships with cPython”
With that in mind:
> Would MicroPython include framebuf in stdlib, PyPI
On Jul 15, 2019, at 18:44, Nam Nguyen wrote:
>
> I have implemented a tiny (~200 SLOCs) package at
> https://gitlab.com/nam-nguyen/parser_compynator that demonstrates something
> like this is possible. There are several examples for you to have a feel of
> it, as well as some early benchmark n
On Tue, Jul 16, 2019 at 12:30 PM Christopher Barker wrote:
> > What about __future__?
>
> Nope: that isn’t really an import.
Actually it is, and the __future__ module is the best way to find out
what future directives there are and which versions they're needed in.
>>> import __future__
>>> __fu
> On Jul 15, 2019, at 19:29, Christopher Barker wrote:
>
> I think this may be a worthwhile idea — after all, “namespaces are one
> honking great idea”
>
> This would be an opportunity to clearly define the “standard library” as
> something other than “all the stuff that ships with cPython”
I
I think a better definition might be: "A lib to access libraries you can
use without installing 3rd party packages". That way, Unix's packages
included in the stdlib will be accessible on Unix only. As referenced
by @Christopher
Barker , a way to namespace. Like right now if you
want to know the s
On Tue, Jul 16, 2019 at 2:54 PM Andrew Barnert via Python-ideas
wrote:
>
> And if that is the rule, there’s a lot of room for bikeshedding on the edges.
> Does the stdlib then include curses because in theory it builds on any
> platform if the lib is found, even though in practice nobody builds
Just out of interest there must be something like this in venv - how else can
it decide what to include in the virtual environment as copies or links? That
would give the platform specific list.
Steve Barnes
-Original Message-
From: Chris Angelico
Sent: 16 July 2019 06:21
To: python-i
On Jul 15, 2019, at 22:45, Steve Barnes wrote:
>
> Just out of interest there must be something like this in venv - how else can
> it decide what to include in the virtual environment as copies or links? That
> would give the platform specific list.
Doesn’t it just do whatever’s in the libpyth
33 matches
Mail list logo
