Re: [Python-ideas] Please consider adding of functions file system operations to pathlib

[Michel Desmoulin]

+1

We already merged, os.path and glob with pathlib. Let's do all os and
shutil.

It's weird enough for beginners to even sumble upon that many ways of
doing thing for FS.

Le 20/02/2018 à 23:11, George Fischhof a écrit :
> Good day all,
> 
> as a continuation of thread "OS related file operations (copy, move,
> delete, rename...) should be placed into one module" 
> 
> https://mail.python.org/pipermail/python-ideas/2017-January/044217.html
> 
> please consider making pathlib to a central file system module with
> putting file operations (copy, move, delete, rmtree etc) into pathlib.
> 
> BR,
> George
> 
> 
> ___
> 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 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] Boolean ABC similar to what's provided in the 'numbers' module

[Terry Reedy]

On 2/20/2018 12:06 PM, Guido van Rossum wrote:
Looking at https://en.wikipedia.org/wiki/Number it seems that Integer is 
"special" -- every other number type is listed as " numbers" 
(e.g. rational numbers, complex numbers) but integers are listed as 
"Integers". So let's just switch it to that, and keep Integral as an 
alias for backwards compatibility. I don't think it's a huge problem to 
fix this in 3.7b2, if someone wants to do the work.


https://bugs.python.org/issue32891

--
Terry Jan Reedy

___
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] Boolean ABC similar to what's provided in the 'numbers' module

[Greg Ewing]

On Mon, Feb 19, 2018 at 5:58 AM, Sylvain MARIE 
> wrote:


By the way, is there a reason for the name "Integral" (algebraic
theory) instead of "Integer" (computer science) ? Would it be
practically feasible to add "Integer" as an alias to "Integral" in
the numbers package ?


Possibly inspired by Haskell, which has Integral (a type class, sort of
like an abstract type) and also Integer and Int (which are concrete types).

--
Greg
___
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] Boolean ABC similar to what's provided in the 'numbers' module

[Sylvain MARIE]

https://bugs.python.org/issue32886 created.
Don't hesitate to correct if anything is wrong in the text or associated tags

Sylvain 

-Message d'origine-
De : Stephen J. Turnbull [mailto:turnbull.stephen...@u.tsukuba.ac.jp] 
Envoyé : mardi 20 février 2018 06:53
À : gu...@python.org
Cc : Sylvain MARIE ; Python-Ideas 

Objet : Re: [Python-ideas] Boolean ABC similar to what's provided in the 
'numbers' module

Guido van Rossum writes:

 > Hm, perhaps Integral is an adjective, just like Boolean?

I would guess so.  This is the same idiom we use when we call [1, 2, 3] a 
"truth-y".


__
This email has been scanned by the Symantec Email Security.cloud service.
__
___
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] Why CPython is still behind in performance for some widely used patterns ?

[Nick Coghlan]

On 21 February 2018 at 08:40, Guido van Rossum  wrote:
> On Tue, Feb 20, 2018 at 12:54 PM, Barnstone Worthy 
> wrote:
>
> I'm pretty sure that's an alias for Barry Warsaw. :-)

Different Barry :)

I've expanded the existing issue at
https://github.com/pypa/python-packaging-user-guide/issues/355 to note
that there are more options we should at least mention in the binary
extensions guide, even if we don't go into the same level of detail as
we do for cffi/Cython/SWIG.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
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] Why CPython is still behind in performance for some widely used patterns ?

[Guido van Rossum]

On Tue, Feb 20, 2018 at 12:54 PM, Barnstone Worthy 
wrote:

I'm pretty sure that's an alias for Barry Warsaw. :-)
-- 
--Guido van Rossum (python.org/~guido)
___
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] Please consider adding of functions file system operations to pathlib

[George Fischhof]

Good day all,

as a continuation of thread "OS related file operations (copy, move,
delete, rename...) should be placed into one module"

https://mail.python.org/pipermail/python-ideas/2017-January/044217.html

please consider making pathlib to a central file system module with putting
file operations (copy, move, delete, rmtree etc) into pathlib.

BR,
George
___
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] Why CPython is still behind in performance for some widely used patterns ?

[Barry]

> On 20 Feb 2018, at 13:12, Nick Coghlan  wrote:
> 
>> On 20 February 2018 at 16:17, Antoine Pitrou  wrote:
>> On Mon, 19 Feb 2018 20:15:27 +0100
>> Stefan Behnel  wrote:
>>> Nick Coghlan schrieb am 02.02.2018 um 06:47:
 to make the various extension module authoring tools
 easier to discover, rather than having folks assuming that handcrafted
 calls directly into the CPython C API is their only option.
>>> 
>>> Or even a competitive option. Tools like Cython or pybind11 go to great
>>> length to shave off every bit of overhead from C-API calls, commonly
>>> replacing high-level C-API functionality with macros and direct access to
>>> data structures. The C/C++ code that they generate is so complex and tuned
>>> that it would be infeasible to write and maintain something like that by
>>> hand, but it can perfectly be generated, and it usually performs visibly
>>> better than most hand-written modules, definitely much better than anything
>>> a non-expert could write.
>>> 
>>> Basically, by not learning the C-API you can benefit from all that highly
>>> tuned and specialised code written by C-API experts that the documentation
>>> doesn't even tell you about.
>> 
>> Doesn't the documentation ever mention Cython? It probably should (no
>> idea about pybind11, which I've never played with). Perhaps you can
>> open an issue about that?
> 
> We mention them in the Extending & Embedding guide, and link out to
> the page on packaging.python.org that describes them in more detail:
> https://docs.python.org/3/extending/index.html#recommended-third-party-tools

Can you add PyCXX to the list please?

Barry

> 
> Cheers,
> Nick.
> 
> P.S. There are also a number of open issues at
> https://github.com/pypa/python-packaging-user-guide/issues regarding
> additional projects that should be mentioned in
> https://packaging.python.org/guides/packaging-binary-extensions/
> 
> -- 
> Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
> ___
> 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 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] importlib: making FileFinder easier to extend

[Brett Cannon]

Basically what you're after is a way to extend the default finder with a
new file type. Historically you didn't want this because of the performance
hit of the extra stat call to check that new file extension (this has been
greatly alleviated in Python 3 through the caching of directory contents).
But I would still argue that you don't necessarily want this for e.g. the
stdlib or any other random project which might just happen to have a file
with the same file extension as the one you want to have special support
for.

I also don't think we want a class attribute to contains the default
loaders since not everyone will want those default semantics in all cases
either. Since we're diving into deep levels of customization I would askew
anything that makes assumptions for what you want.

I think the best we could consider is making
importlib.machinery._get_supported_loaders() a public API. That way you can
easily construct a finder with the default loaders plus your custom ones.
After that you can then provide a custom sys.path_hooks entry that
recognizes the directories which contain your custom file type.

If that seems reasonable then feel free to open an enhancement request at
bugs.python.org to discuss the API and then we can discuss how to implement
a PR for it.

On Wed, 7 Feb 2018 at 07:04 Erik Bray  wrote:

> Hello,
>
> Brief problem statement: Let's say I have a custom file type (say,
> with extension .foo) and these .foo files are included in a package
> (along with other Python modules with standard extensions like .py and
> .so), and I want to make these .foo files importable like any other
> module.
>
> On its face, importlib.machinery.FileFinder makes this easy.  I make a
> loader for my custom file type (say, FooSourceLoader), and I can use
> the FileFinder.path_hook helper like:
>
> sys.path_hooks.insert(0, FileFinder.path_hook((FooSourceLoader, ['.foo'])))
> sys.path_importer_cache.clear()
>
> Great--now I can import my .foo modules like any other Python module.
> However, any standard Python modules now cannot be imported.  The way
> PathFinder sys.meta_path hook works, sys.path_hooks entries are
> first-come-first-serve, and furthermore FileFinder.path_hook is very
> promiscuous--it will take over module loading for *any* directory on
> sys.path, regardless what the file extensions are in that directory.
> So although this mechanism is provided by the stdlib, it can't really
> be used for this purpose without breaking imports of normal modules
> (and maybe it's not intended for that purpose, but the documentation
> is unclear).
>
> There are a number of different ways one could get around this.  One
> might be to pass FileFinder.path_hook loaders/extension pairs for all
> the basic file types known by the Python interpreter.  Unfortunately
> there's no great way to get that information.  *I* know that I want to
> support .py, .pyc, .so etc. files, and I know which loaders to use for
> them.  But that's really information that should belong to the Python
> interpreter, and not something that should be reverse-engineered.  In
> fact, there is such a mapping provided by
> importlib.machinery._get_supported_file_loaders(), but this is not a
> publicly documented function.
>
> One could probably think of other workarounds.  For example you could
> implement a custom sys.meta_path hook.  But I think it shouldn't be
> necessary to go to higher levels of abstraction in order to do
> this--the default sys.path handler should be able to handle this use
> case.
>
> In order to support adding support for new file types to
> sys.path_hooks, I ended up implementing the following hack:
>
> #
> import os
> import sys
>
> from importlib.abc import PathEntryFinder
>
>
> @PathEntryFinder.register
> class MetaFileFinder:
> """
> A 'middleware', if you will, between the PathFinder sys.meta_path hook,
> and sys.path_hooks hooks--particularly FileFinder.
>
> The hook returned by FileFinder.path_hook is rather 'promiscuous' in
> that
> it will handle *any* directory.  So if one wants to insert another
> FileFinder.path_hook into sys.path_hooks, that will totally take over
> importing for any directory, and previous path hooks will be ignored.
>
> This class provides its own sys.path_hooks hook as follows: If inserted
> on sys.path_hooks (it should be inserted early so that it can supersede
> anything else).  Its find_spec method then calls each hook on
> sys.path_hooks after itself and, for each hook that can handle the
> given
> sys.path entry, it calls the hook to create a finder, and calls that
> finder's find_spec.  So each sys.path_hooks entry is tried until a
> spec is
> found or all finders are exhausted.
> """
>
> def __init__(self, path):
> if not os.path.isdir(path):
> raise ImportError('only directories are supported', path=path)
>
>  

Re: [Python-ideas] Boolean ABC similar to what's provided in the 'numbers' module

[Guido van Rossum]

Looking at https://en.wikipedia.org/wiki/Number it seems that Integer is
"special" -- every other number type is listed as " numbers"
(e.g. rational numbers, complex numbers) but integers are listed as
"Integers". So let's just switch it to that, and keep Integral as an alias
for backwards compatibility. I don't think it's a huge problem to fix this
in 3.7b2, if someone wants to do the work.

On Mon, Feb 19, 2018 at 9:53 PM, Stephen J. Turnbull <
turnbull.stephen...@u.tsukuba.ac.jp> wrote:

> Guido van Rossum writes:
>
>  > Hm, perhaps Integral is an adjective, just like Boolean?
>
> I would guess so.  This is the same idiom we use when we call
> [1, 2, 3] a "truth-y".
>
>


-- 
--Guido van Rossum (python.org/~guido)
___
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] Why CPython is still behind in performance for some widely used patterns ?

[Nick Coghlan]

On 20 February 2018 at 16:17, Antoine Pitrou  wrote:
> On Mon, 19 Feb 2018 20:15:27 +0100
> Stefan Behnel  wrote:
>> Nick Coghlan schrieb am 02.02.2018 um 06:47:
>> > to make the various extension module authoring tools
>> > easier to discover, rather than having folks assuming that handcrafted
>> > calls directly into the CPython C API is their only option.
>>
>> Or even a competitive option. Tools like Cython or pybind11 go to great
>> length to shave off every bit of overhead from C-API calls, commonly
>> replacing high-level C-API functionality with macros and direct access to
>> data structures. The C/C++ code that they generate is so complex and tuned
>> that it would be infeasible to write and maintain something like that by
>> hand, but it can perfectly be generated, and it usually performs visibly
>> better than most hand-written modules, definitely much better than anything
>> a non-expert could write.
>>
>> Basically, by not learning the C-API you can benefit from all that highly
>> tuned and specialised code written by C-API experts that the documentation
>> doesn't even tell you about.
>
> Doesn't the documentation ever mention Cython? It probably should (no
> idea about pybind11, which I've never played with). Perhaps you can
> open an issue about that?

We mention them in the Extending & Embedding guide, and link out to
the page on packaging.python.org that describes them in more detail:
https://docs.python.org/3/extending/index.html#recommended-third-party-tools

Cheers,
Nick.

P.S. There are also a number of open issues at
https://github.com/pypa/python-packaging-user-guide/issues regarding
additional projects that should be mentioned in
https://packaging.python.org/guides/packaging-binary-extensions/

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/