Re: [Python-ideas] In fact, I'm a bit worry about this literal p""

[Yuval Greenfield]

On Fri, Dec 28, 2018 at 1:56 AM Ma Lin  wrote:

> Maybe this literal will encourage people to finish tasks using regex,
> even lead to abuse regex, will this change Python's style?
>
> What's worse is, people using mixed manners in the same project:
>
> one_line.split(',')
> ...
> p','.split(one_line)
>
> Maybe it will break the Python's style, reduce code readability, is this
> worth it?
>
>
The bar for introducing a new type of literal should be very high. Do
performance numbers show this change would have a large impact for a large
amount of libraries and programs?

In my opinion, only if this change would make 50% of programs run 50%
faster then it might be worth discussing. The damage to readability, burden
of changing syntax and burden of yet another language feature for newcomers
to learn is too high.

Cheers,

Yuval
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Relative Imports

[Yuval Greenfield]

On Tue, Nov 13, 2018 at 4:46 PM Chris Barker - NOAA Federal via
Python-ideas  wrote:

> Then I discovered setuptools’ develop mode (now pip editable install)
>
> It is the right way to run code in packages under development.
>

In multiple workplaces I found a folder with python utility scripts that
users can just double-click. The need for installing causes problems with
handling different versions on one machine, and the need for "__init__.py"
files makes the folders less pretty. Sure - sometimes I need to install
stuff anyway - but that's just one "install.py" double click away.

I would like to propose allowing importing of strings that would support
relative paths. For example in Danish's example:

# use this in `test_main.py`
import '../main.py' as main

Maybe the syntax can be improved, but to me this need has been aching since
I started using Python 12 years ago. I've used C, C++, and Javascript where
the whole "how do I connect these two files that are a folder apart"
problem doesn't require googling for documentation on packaging tools,
magic filenames, constraints and gotchas. The solution is always obvious
because it works just like it works in every system - with a file-relative
path.

File-relative imports is probably highest on my Python wish list. I've
drafted but not sent out a python-ideas email about it multiple times. I've
seen a lot of "sys.path" hacking that would've been solved by
file-relative-paths.

Cheers and thanks,

Yuval Greenfield
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Trigonometry in degrees

[Yuval Greenfield]

On Thu, Jun 7, 2018 at 10:38 PM Stephen J. Turnbull <
turnbull.stephen...@u.tsukuba.ac.jp> wrote:

>
> 6.123233995736766e-17
> >>>
>
> is good enough for government work, including at the local public high
> school.
>
>
There probably is room for a library like "fractions" that represents
multiples of pi or degrees precisely. I'm not sure how complicated or
valuable of an endeavor that would be. But while I agree that floating
point is good enough, we probably can do better.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Trigonometry in degrees

[Yuval Greenfield]

On Thu, Jun 7, 2018 at 1:07 PM Robert Vanden Eynde <
robertvandeney...@hotmail.com> wrote:

> I suggest adding degrees version of the trigonometric functions in the
> math module.
>
>
You can create a pypi package that suits your needs. If it becomes popular
it could considered for inclusion in the standard library.

Would that work for you?

Yuval
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Add dict.append and dict.extend

[Yuval Greenfield]

On Mon, Jun 4, 2018 at 3:58 PM George Leslie-Waksman 
wrote:

> Semantically, I'm not sure append and extend would be universally
> understood to mean don't overwrite.
>
>
The proposed meanings surprised me too. My initial instinct for
`dict.append` was that it would always succeed, much like `list.append`
always succeeds.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Please consider skipping hidden directories in os.walk, os.fwalk, etc.

[Yuval Greenfield]

On Mon, May 7, 2018 at 9:44 PM Steve Barnes  wrote:

> Since the implementation of os.walk has changed to use os.scandir which
> exposes the returned file statuses in the os.DirEntry.stat() the
> overhead should be minimal.
>
> An alternative would be to add another new function, say os.vwalk(), to
> only walk visible entries.
>

On Tue, May 8, 2018 at 12:06 AM Steven D'Aprano  wrote:

> I would write something like:
> for root, dirs, files in filter(ignorable, os.walk(some_dir)):


I agree with Steven with regards to `filter` needing to be flexible. If you
want to avoid duplicate `stat` calls, you'll probably write:

import os
import stat
def is_hidden(st):
return bool(st.st_file_attributes & stat.FILE_ATTRIBUTE_HIDDEN)
def visible_walk(path):
for entry in os.scandir(path):
if entry.is_dir():
if not is_hidden(entry.stat()):
yield from visible_walk(entry.path)
else:
if not is_hidden(entry.stat()):
yield entry.path


Then you can decide whether you want to ignore hidden files or just hidden
directories. The variations for such a need are many. So it makes sense to
leave any specific filtering need outside of the standard library. A PyPI
package with a few standard filtered walks could be a nice exploration for
this idea.

Cheers,

Yuval
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] __dir__ in which folder is this py file

[Yuval Greenfield]

Hi Ideas,

I often need to reference a script's current directory. I end up writing:

import os
SRC_DIR = os.path.dirname(__file__)


But I would prefer to have a new dunder for that. I propose: "__dir__".  I
was wondering if others would find it convenient to include such a shortcut.


Here are some examples of dirname(__file__) in prominent projects.

https://github.com/tensorflow/models/search?l=Python=dirname=
https://github.com/django/django/search?l=Python=dirname=
https://github.com/nose-devs/nose/search?l=Python=dirname=

Reasons not to add __dir__:
* There already is one way to do it and it's clear and fairly short.
* Avoid the bikeshed discussion of __dir__, __folder__, and other
candidates.

Reasons to add it:
* os.path.dirname(__file__) returns the empty string when you're in the
same directory as the script. Luckily, os.path.join understands an empty
string as a ".", but this still is suboptimal for logging where it might be
surprising to find the empty string. __dir__ could be implemented to
contain a "." in that case.
* I would save about 20 characters and a line from 50% of my python scripts.
* This is such a common construct that everyone giving it their own name
seems suboptimal for communicating. Common names include: here, path,
dirname, module_dir.

Cheers,

Yuval Greenfield

P.s. nodejs has it -
https://nodejs.org/docs/latest/api/modules.html#modules_dirname also I
apologize if this has been suggested before - my googling didn't find a
previous thread.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/