[Python-ideas] Re: "Curated" package repo?

[George Fischhof]

Jonathan Crall  ezt írta (időpont: 2023. júl. 24., H,
15:29):

> If popular packages weren't favored that would be a problem. Popularity
> should be correlated with "trustworthiness" or whatever the metric this
> curated repo seeks to maximize. I think the important thing is that the
> packages are both popular and have passed some sort of vetting procedure.
>
> For instance, for a very long time Python2 was far more popular than
> Python3, but any expert in the field would encourage users to move to
> Python3 sooner rather than later. Python2 is popular, but it wouldn't have
> made the cut on some expert-curated list.
>
> So it helps in that it reranks popular packages (and also excludes some)
> for those who want to adopt a more strict security / reliability posture.
>
> By no means do I think this would replace pypi as the de-facto packaging
> repository. Its low barrier to entry is extremely important for a thriving
> community, but I also wouldn't mind having something a bit more robust.
>
> I also think this project would have to careful not to become yet another
> "awsome-python-package" collection. Those certainly have value, but based
> on the initial proposal, I'm interested in something a tad more robust.
>
>
... some old stuff cut ...

Hi Folks,

it has got to my mind that even just grouping similar / same goal packages
could help the current situation.
Unfortunately searching by name or category is not enough, and takes much
time.
By linking similar packages together would give the users the possibility
to evaluate all / several of them.

Additionally perhaps the users could give relative valuation, for example
there are A, B, C, D similar packages, users could say: I tried out A and
B, and found that A is better then B, and could have some valuation
categories: simple, easy, powerful etc. This would show for example that
package A is simple, but B is more powerful

BR,
George
___
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/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/OIX5GLWSJORZXS4DET3YJGKQR7IUFYUE/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Popular Python Package 'ctx' Hijacked to Steal AWS Keys

[George Fischhof]

Turritopsis Dohrnii Teo En Ming  ezt írta (időpont:
2022. máj. 25., Sze, 15:49):

> Subject: Popular Python Package 'ctx' Hijacked to Steal AWS Keys
>
> Good day from Singapore,
>
> Sharing this article for more awareness.
>
> Article: Popular PyPI Package 'ctx' and PHP Library 'phpass' Hijacked
> to Steal AWS Keys
> Link:
> https://thehackernews.com/2022/05/pypi-package-ctx-and-php-library-phpass.html
>
> Thank you.
>
> Regards,
>
> Mr. Turritopsis Dohrnii Teo En Ming
> Targeted Individual in Singapore
> 25 May 2022 Wed
> --
> https://mail.python.org/mailman/listinfo/python-list


Hi All,

it's got to my mind that PYPA, community, and developers should develop
some mechanism to protect against similar threats.

For example security checkers could be added to the upload flow, before a
package appears, and becomes downloadable.
Compiled parts should be allowed only in source, and security checkers
would check those too, and compile from source and publish package only
after these checks executed and did not found any harmful thing.


BR,
George
___
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/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/S7PPRPILTINMIJUQHAMVR45KJGVBDNFN/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[George Fischhof]

Steve Jorgensen  ezt írta (időpont: 2019. nov. 14., Cs,
10:59):

> Michel Desmoulin wrote:
> > +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/
> > >
>
> There have been many times now where I have been annoyed not to have
> rmtree in pathlib. I definitely would like to see that and other shutil
> capabilities added to that.
> ___
> 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/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/WI2UZQMOH5VVYYLYMGKLW3K6A4FA3UV6/
> Code of Conduct: http://python.org/psf/codeofconduct/




Hi Steve,

nowadays I have no time to create a PEP from this. Nether I had in the past
... And now it is required to have a sponsor for a PEP.
It is too much for me alone ... But of course if you start to create a PEP
I will be in

BR,
George
___
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/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/ZAQEOFRH7VAA5TIAQ7BFFEY4J56GGVBV/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Simpler syntax for async generators

[George Fischhof]

Steven D'Aprano  ezt írta (időpont: 2019. szept. 16.,
H 2:55):

> On Mon, Sep 16, 2019 at 11:36:45AM +1200, Greg Ewing wrote:
> > George Fischhof wrote:
> > >With this syntax the use / programmer do not have to write async def,
> > >nor await, because after the yield the await should come automatically.
> >
> > I don't see how you can eliminate the await in your example generator.
> > Can you show us how it would look in its entirety under your proposal?
>
> I think the proposal is for two things:
>
> 1. `async yield i` to be syntactic sugar for `yield i; await
> asyncio.sleep(delay)`.
>
> 2. The interpreter should infer that a plain `def` function is actually
> an `async def` from the presence of `async yield`, similar to the way
> the interpreter infers that a plain `def` function is actually a
> generator from the presence of a `yield`.
>
>
> # Original
> async def ticker(delay, to):
> """Yield numbers from 0 to to every delay seconds."""
> for i in range(to):
> yield i
> await asyncio.sleep(delay)
>
>
> # Re-written
> def ticker(delay, to):
> """Yield numbers from 0 to to every delay seconds."""
> for i in range(to):
> async yield i
>
>
> So you save one line and perhaps 25-30 key presses when writing the
> function, at the cost of making it much less clear what's going on when
> reading the function.
>
> How does it known how long to sleep?
>
> What if you're not using asyncio, but some other framework?
>
>
>
> --
> Steven
> ___
> 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/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/KKAAH3S4LM52NL5572LAY5QMHYUUUN7T/
> Code of Conduct: http://python.org/psf/codeofconduct/




Hi Steven,



yes exactly I would like this.



Regarding the waiting and frameworks:

The solution should be independent from waiting and frameworks:



Let's see what happens now (sync, not async)



User has a generator, he wants values.



Uses a for cycle to process all values from generator:

Asks for first value - wait for the value to be computed

Processes the value he got

Asks for next value - wait for the value to be computed

And processes again, and again





The async version:



User has a generator, he wants values, he created an async version, because
he wants the values faster



Uses a for cycle to process all values from generator:

Asks for first value - wait for the value to be computed

Processes the value he got - in the meantime, in the background the
computation of next value is in progress

Asks for next value - it is possible that the values is already computed so
there is only maximum a smaller wait for the value

And processes again, and again





So my idea above the syntax is the following:

When one value is yielded, the async generator starts computing in the
background, it means it has to execute commands until next yield is reached
(the next yield can be same one in a cycle or even a different yield
statement .)

And stops when reaches the next yield.



When the next request comes for the next value, it gives the computed value
if it is ready, or computes until the value is ready. And gives the value
that time.





Actually I can imagine Python as being more and more async to be faster.



And therefore async could be the default working method.



Practically the user is not interested in how the value is computed, he
just wants faster programs.

The only exception when async can be bad is when the computation of next
value and processing the got value requires the same resource.



So when the default is async, the user will get faster program, by default.
And he should only sign whe he does not want async, because of same
resource usage.





BR,

__george__




>
___
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/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/3U2LE7OOMGB3W4RBZSRBIHIUIMO3TSFA/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Simpler syntax for async generators

[George Fischhof]

Christopher Barker  ezt írta (időpont: 2019. szept.
14., Szo, 21:58):

> > While I was reading the documentation of asyn generators,
>> > which shows the following example:
>> >
>> > async def ticker(delay, to):
>> > """Yield numbers from 0 to *to* every *delay* seconds."""
>> > for i in range(to):
>> > yield i
>> > await asyncio.sleep(delay)
>> >
>> > It's came to my mind that it could could be simpler.
>> >
>> > We could use just
>> > async yield
>> > and all the other stuff could be done in the background.
>>
>
> Which all other stuff? Are you saying that you wouldn't need to use "async
> def", if there was an "async yield" in the function?
>
> But that doesn't solve many problems, because you can create async
> functions that don't have a yield in them -- ie, they are async, but not
> generator functions, the two are orthogonal.
>
> -CHB
>
> --
> Christopher Barker, PhD
>
> Python Language Consulting
>   - Teaching
>   - Scientific Software Development
>   - Desktop GUI and Web Development
>   - wxPython, numpy, scipy, Cython
>



Yes, that is why I wrote simpler async generator:
With this syntax the use / programmer do not have to write async def, nor
await, because after the yield the await should come automatically.
I got my value, then do my job with the value, in the background the next
value is prepared, and next time, when I need the next value, it will be
prepared, or there will be a wait until it is prepared.

So async yield would mean: give me the value, and start creating the next
one, I will come back.

__george__
___
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/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/JYXFWNFODFA26Q6HD3BLKVJ76ISS3VGC/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Simpler syntax for async generators

[George Fischhof]

Hi All,

While I was reading the documentation of asyn generators,
which shows the following example:


async def ticker(delay, to):
"""Yield numbers from 0 to *to* every *delay* seconds."""
for i in range(to):
yield i
await asyncio.sleep(delay)



It's came to my mind that it could could be simpler.

We could use just
async yield

and all the other stuff could be done in the background.

Like if we use the yield in function, that function becomes a generator

example:

def my_async_generator():
for i in range(5):

async yield  i


What do you think about this? Would this be feasible?


BR,

__george__
___
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/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/SRWW6U3N3SHNJFLMTX3A4ZRFQGUNKQR6/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[George Fischhof]

2018-05-06 15:28 GMT+02:00 Cody Piersall :

> With PEP 562, the name __dir__ is off limits for this.
>
> Cody
>
> On Sun, May 6, 2018, 1:54 AM Yuval Greenfield 
> wrote:
>
>> 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/
>>
>
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
>

Hi,

I would give +1 for __dirname__

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] Rewriting file - pythonic way

[George Fischhof]

Hi,

some similar thing already exist in standard:
https://docs.python.org/3/library/fileinput.html

fileinput(... inplace=True...)

BR,
George

2018-04-15 10:57 GMT+02:00 Alexey Shrub :

> Hi all,
>
> I am new in python (i am moving from Perl world), but I always love Python
> for hight level, beatuful and clean syntax.
> Now I have question/idea about working with files.
> On mine opinion it very popular use case:
> 1. Open file (for read and write)
> 2. Read data from file
> 3. Modify data.
> 4. Rewrite file by modified data.
>
> But now it is looks not so pythonic:
>
> with open(filename, 'r+') as file:
>data = file.read()
>data = data.replace('old', 'new')
>file.seek(0)
>file.write(data)
>file.truncate()
>
> or something like this
>
> with open(filename) as file:
>data = file.read()
> data = data.replace('old', 'new')
> with open(filename) as file:
>file.write(data)
>
> I think best way is something like this
>
> with open(filename, 'r+') as file:
>data = file.read()
>data = data.replace('old', 'new')
>file.rewrite(data)
>
> but for this io.BufferedIOBase must contain rewrite method
>
> what you think about this?
>
>
>
> ___
> 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] New PEP proposal -- Pathlib Module ShouldContain All File Operations -- version 2

[George Fischhof]

Hi folks,

according to comments it seems, it would better to propose a new module.
I start to work out a new proposal.

I created a BitBucket repo to be able to work together with folks who want
help ;-)
the repo address is:

https://bitbucket.org/GeorgeFischhof/pep_for_filesystem_operations.git


-- o --

shutil and path object relation: the documentation laks the information.
For functions of os module it is written that functions updated in 3.6 and
from that point they can use pathlib objects.
I will check the status. (if the work together I will submit an issue
report to update the documentation accordingly)



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] New PEP proposal -- Pathlib Module Should Contain All File Operations

[George Fischhof]

Hi Jason,

the status of os and shutil became this because of C functions in
implementation (I got something similar answer before)
...

What do you think, what would be a good way to solve this
- add stuff from os to shutil
- add stuff from os and shutil to pathlib
- create a new module on top of os, shutil and pathlib (we could name it
for example filelib

George

2018-03-18 19:43 GMT+01:00 Jason Maldonis :

> Surely shutil is a *high* level modules.
>> os is a low level module that shutil builds on.
>> Adding the missing pieces to shutil would make it the place to go to do
>> file operations.
>> Pity its not called filelib.
>>
>
> Gotcha, thank you! shutil being a high level library complicates things...
> So we have two "high-level" libraries (pathlib and shutil) and both of them
> provide different pieces of useful functionality. Maybe I am starting to
> see why this is complicated. Thanks for reading my above reply and taking
> the time to respond.
>
> ___
> 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] New PEP proposal -- Pathlib Module Should Contain All File Operations

[George Fischhof]

Hi Folks,

it seems for me that the welcoming of this proposal is rather positive than
not.

Of course several details could be put into it, but I think it would better
to let the developers decide the details, because they know the environment
and the possibilities.

The name of the functions and the method they solve the problem (for
example rmdir(tree=True9 instead of removedirs()) is all the same.

The (main) goal would be that file and directory operations reside in one
module. And currently the pathlib seems to be the best candidate.
(we could put then into a very new module, but it would be just another
duplicataion)


So what do You think, this proposal IS PEPable or should I do something
with this to achieve the PEPable state?


BR,
George

2018-03-18 9:05 GMT+01:00 Nick Coghlan <ncogh...@gmail.com>:

> On 16 March 2018 at 03:15, Chris Angelico <ros...@gmail.com> wrote:
>
>> On Fri, Mar 16, 2018 at 12:38 AM, George Fischhof <geo...@fischhof.hu>
>> wrote:
>> >
>> >
>> > " if new file functions are added, they will go only in pathlib,
>> >   which makes pathlib effectively mandatory;"
>> > Yes but I think this part of the evolution: slowly everyone will shift
>> to
>> > pathlib,
>> > and being mandatory is true for the current status as well: if you need
>> a
>> > function, you need the module.
>> > Right now if you wan to execute some file operations, you need os plus
>> > shutil, because the half of the
>> > functions are in one of them, the other half is in the other module
>>
>> The os module is cheap; pathlib has a definite cost. If every file
>> operation goes through pathlib
>
>
> Keep in mind that the `os` layer will never go away: `pathlib` still needs
> a lower level API to call to *do the work* of actually interacting with the
> underlying operating system APIs (e.g. this is why we added os.scandir).
>
> A similar situation applies when it comes to glob, fnmatch, etc.
>
> Even `shutil` will likely retain its place as a lower level procedural API
> behind pathlib's object-oriented facade, since raw strings are still
> frequently going to be easier to work with when mixing and matching Python
> code and native operating system shell code.
>
> 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/
>
>
___
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] New PEP proposal -- Pathlib Module Should Contain All File Operations

[George Fischhof]

2018-03-18 9:05 GMT+01:00 Nick Coghlan <ncogh...@gmail.com>:

> On 16 March 2018 at 03:15, Chris Angelico <ros...@gmail.com> wrote:
>
>> On Fri, Mar 16, 2018 at 12:38 AM, George Fischhof <geo...@fischhof.hu>
>> wrote:
>> >
>> >
>> > " if new file functions are added, they will go only in pathlib,
>> >   which makes pathlib effectively mandatory;"
>> > Yes but I think this part of the evolution: slowly everyone will shift
>> to
>> > pathlib,
>> > and being mandatory is true for the current status as well: if you need
>> a
>> > function, you need the module.
>> > Right now if you wan to execute some file operations, you need os plus
>> > shutil, because the half of the
>> > functions are in one of them, the other half is in the other module
>>
>> The os module is cheap; pathlib has a definite cost. If every file
>> operation goes through pathlib
>
>
> Keep in mind that the `os` layer will never go away: `pathlib` still needs
> a lower level API to call to *do the work* of actually interacting with the
> underlying operating system APIs (e.g. this is why we added os.scandir).
>
> A similar situation applies when it comes to glob, fnmatch, etc.
>
> Even `shutil` will likely retain its place as a lower level procedural API
> behind pathlib's object-oriented facade, since raw strings are still
> frequently going to be easier to work with when mixing and matching Python
> code and native operating system shell code.
>
> 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/
>
>

:-)
+ 1

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] New PEP proposal -- Pathlib Module Should Contain All File Operations

[George Fischhof]

2018-03-18 5:41 GMT+01:00 Nathaniel Smith :

> On Sat, Mar 17, 2018 at 10:15 AM, Stephen J. Turnbull
>  wrote:
> > (5) perform operations on several objects denoted by Paths at once
> > (copy and its multiple operand variants),
>
> Sure it does: Path.rename and Path.replace. I know why rename and copy
> have historically been in separate modules, but the distinction is
> pretty arcane and matters a lot more to implementers than it does to
> users.
>
> Similarly, it's hard to explain why we have Path.mkdir but not
> Path.makedirs -- and these have historically both lived in the 'os'
> module, so we can't blame it on Path being a mirror of os.path. It's
> also not obvious why we should have Path.rmdir, but not Path.rmtree.
>
> My understanding is that the point of Path is to be a convenient,
> pleasant-to-use mechanism for accessing common filesystem operations.
> And it does a pretty excellent job of that. But it seems obvious to me
> that it's still missing a number of fairly basic operations that
> people need all the time. I don't think the PEP is there yet, and we
> can quibble over the details -- just copying over all the historical
> decisions in shutil isn't obviously the right move (maybe it should be
> Path.mkdir(include_parents=True) and Path.unlink(recursive=True)
> instead of Path.makedirs and Path.rmtree?), but there's definitely
> room for improvement.
>
> -n
>
> --
> Nathaniel J. Smith -- https://vorpus.org
>


:-)
+ 1

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] New PEP proposal -- Pathlib Module Should Contain All File Operations -- version 2

[George Fischhof]

2018. márc. 17. 21:34 ezt írta ("Barry" <ba...@barrys-emacs.org>):



On 17 Mar 2018, at 10:42, George Fischhof <geo...@fischhof.hu> wrote:

Hi folks,

I added the list of functions to the proposal, here is the new version.

George




PEP: 
Title: Pathlib Module Should Contain All File Operations
Author: George Fischhof 
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 15-Mar-2018
Python-Version: 3.8
Post-History: 12-Mar-2018, 17-Mar-2018


Abstract


This PEP proposes pathlib module to be a centralized place for all
file-system related operations.


Rationale
=

Right now we have several modules that contain functions related
to file-system operations mainly the os, pathlib and shutil.
For beginners it is quite hard to remember where can he / she find
a function (copy resides in shutil, but the remove function can be
found in the os module.  (And sometimes developers with moderate
experience have to check the documentation as well.)

After the release of version 3.6 several methods became aware of
path-like object.  There are only a few ones which does not support
the path-like object.  After making these methods path-like object
aware, these functions could be added to pathlib.

With functions in pathlib the developers should not have to think
on which method (function) can be found in which module.

Makes the life easier.


Implementation
==

For compatibility reasons the pathlib should contain wrappers to
the original functions.  The original functions should remain
at their original place.  (Or if pathlib contains the function, the
original modules should have a wrapper to it.)


List of mentioned functions
===

* os.link => path.hardlink_to
  (should be named similarly to path.softlink_to)

* os.mkfifo

* os.readlink

* os.remove

* os.removedirs
  (shutil.rmtree has the same functionalaty)


I think you will find these to are a lot different.



>From high level, it is only question of implementation: the main goal is to
remove a chain of directories



* os.truncate

* shutil.copyfileobj


This function does not take paths as arguments. I guess it does not belong
here.



No path, it is true (right now), but it has sense to have this function
among the others.



* shutil.copyfile

* shutil.copymode

* shutil.copystat

* shutil.copy

* shutil.copy2

* shutil.copytree with shutil.ignore_patterns

* shutil.move

* shutil.disk_usage

* shutil.chown


Is yout plan to also expose all the constants need to use chmod etc from
pathlib?


Of course, because this PEP is about conveniece and easyness.



All functions from os module accept path-like objects,
and none of the shutil functions.


Should shutils be improved to accept path-like first?


Maybe. The PEP should show the goal. This is just a task among others to
achieve the goal. But it can be done simultanuosly.

George


Barry



Copyright
=

This document has been placed in the public domain.



..
   Local Variables:
   mode: indented-text
   indent-tabs-mode: nil
   sentence-end-double-space: t
   fill-column: 70
   coding: utf-8
   End:




___
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/

[Python-ideas] New PEP proposal -- Pathlib Module Should Contain All File Operations -- version 2

[George Fischhof]

Hi folks,

I added the list of functions to the proposal, here is the new version.

George




PEP: 
Title: Pathlib Module Should Contain All File Operations
Author: George Fischhof 
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 15-Mar-2018
Python-Version: 3.8
Post-History: 12-Mar-2018, 17-Mar-2018


Abstract


This PEP proposes pathlib module to be a centralized place for all
file-system related operations.


Rationale
=

Right now we have several modules that contain functions related
to file-system operations mainly the os, pathlib and shutil.
For beginners it is quite hard to remember where can he / she find
a function (copy resides in shutil, but the remove function can be
found in the os module.  (And sometimes developers with moderate
experience have to check the documentation as well.)

After the release of version 3.6 several methods became aware of
path-like object.  There are only a few ones which does not support
the path-like object.  After making these methods path-like object
aware, these functions could be added to pathlib.

With functions in pathlib the developers should not have to think
on which method (function) can be found in which module.

Makes the life easier.


Implementation
==

For compatibility reasons the pathlib should contain wrappers to
the original functions.  The original functions should remain
at their original place.  (Or if pathlib contains the function, the
original modules should have a wrapper to it.)


List of mentioned functions
===

* os.link => path.hardlink_to
  (should be named similarly to path.softlink_to)

* os.mkfifo

* os.readlink

* os.remove

* os.removedirs
  (shutil.rmtree has the same functionalaty)

* os.truncate

* shutil.copyfileobj

* shutil.copyfile

* shutil.copymode

* shutil.copystat

* shutil.copy

* shutil.copy2

* shutil.copytree with shutil.ignore_patterns

* shutil.move

* shutil.disk_usage

* shutil.chown

All functions from os module accept path-like objects,
and none of the shutil functions.


Copyright
=

This document has been placed in the public domain.



..
   Local Variables:
   mode: indented-text
   indent-tabs-mode: nil
   sentence-end-double-space: t
   fill-column: 70
   coding: utf-8
   End:
___
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] New PEP proposal -- Pathlib Module Should Contain All File Operations

[George Fischhof]

2018-03-17 7:18 GMT+01:00 Stephen J. Turnbull <
turnbull.stephen...@u.tsukuba.ac.jp>:

> Joonas Liik writes:
>
>  > then it might be an acceptable compromise to have yet another...
>
> "There should be one-- and preferably only one -- obvious way to do it."
>
> The obvious way is to use the existing stdlib modules.  So
>
>  > package that just imports os, pathlib, shutil etc and re-exports
>  > all relevant functions.
>
> Anybody wanting this can easily do a better job than the stdlib ever
> can do -- by writing a package including all the modules they
> frequently use and only re-exporting those names that they use,
> perhaps with shorter or personally mnemonic aliases (Windows vs. Unix
> nomenclature for many shell utilities, for example -- but watch those
> builtins like "dir"!)
>
> Of course, this is horrible programming practice, making for burdens
> on reviewers and maintainers.  I see the convenience for writing
> one-off scripts and perhaps a personal library, but I don't see it as
> a core function of the language and its standard library.  So, -1 in
> the stdlib, and +0 for a base module on PyPI that demonstrates the
> principle and individual users could modify to personal taste.
>
> Steve
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>




Hi Steve,

as I wrote previuosly pathlib already contains 17 functions from os and
shutil.
It seems that the original idea was something like for my idea. Just it not
finished yet,
With adding the remaining functions it would become  a nice and whole thing

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] New PEP proposal -- Pathlib Module Should Contain All File Operations

[George Fischhof]

2018-03-13 13:17 GMT+01:00 Steven D'Aprano <st...@pearwood.info>:

> On Mon, Mar 12, 2018 at 09:57:32PM +0100, George Fischhof wrote:
>
> > Right now we have several modules that contain functions related
> > to file-system operations mainly the os, pathlib and shutil.
> > For beginners it is quite hard to remember where can he / she find
> > a function (copy resides in shutil, but the remove function can be
> > found in the os module.  (And sometimes developers with moderate
> > experience have to check the documentation as well.)
>
> This is certainly a problem. Not a big problem, but it is an annoyance.
>
>
> > With functions in pathlib the developers should not have to think
> > on which method (function) can be found in which module.
> >
> > Makes the life easier.
>
> I don't know that this will be true. It makes one problem better: you no
> longer have to remember which module the function is in. But it makes
> other things worse:
>
> - code and/or API duplication: for backwards compatibility, every
>   existing function must be in two places, the original and in
>   pathlib;
>
> - if new file functions are added, they will go only in pathlib,
>   which makes pathlib effectively mandatory;
>
> - the pathlib API becomes even more complicated: not only have you
>   got all the methods of pathlib objects, but you have all the shutil
>   and os functions as well.
>
>
> I think this is a good place for an experiment. You could write a
> function which monkey-patches pathlib:
>
> from pathlib import Path
> import os
> import shutil
>
> def monkeypatch():
> Path.remove = os.remove
> # etc.
>
> Then we can see how many functions are involved, how large this makes
> the Path object, and try it out and see whether it is better.
>
>
>
> --
> Steve
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>



Duplication: it is true, but it is true for several other modules as well.
I checked the pathlib module: right now more than 50% of the functions are
duplicate
- mainly from os - so it seems that pathlib already started to develop this
way ;-)


" if new file functions are added, they will go only in pathlib,
  which makes pathlib effectively mandatory;"
Yes but I think this part of the evolution: slowly everyone will shift to
pathlib,
and being mandatory is true for the current status as well: if you need a
function, you need the module.
Right now if you wan to execute some file operations, you need os plus
shutil, because the half of the
functions are in one of them, the other half is in the other module


I collected the functions that sould be put into pathlib:

- os.remove

- os.removedirs (shutil.rmtree has the same functionalaty)

- os.truncate

- shutil.copyfileobj

- shutil.copyfile

- shutil.copymode

- shutil.copystat

- shutil.copy

- shutil.copy2

- shutil.copytree with shutil.ignore_patterns

- shutil.move

- shutil.disk_usage

- shutil.chown

- os.link => path.hardlink_to

- os.mkfifo

- os.readlink


Sum: 16 functuins
And  all functions from os module accept path-like objects, and none of the
shutil functions.
Pathlib already contains 17 functions from os an shutil modules.


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] New PEP proposal -- Pathlib Module Should Contain All File Operations

[George Fischhof]

2018-03-12 22:16 GMT+01:00 Paul Moore <p.f.mo...@gmail.com>:

> On 12 March 2018 at 20:57, George Fischhof <geo...@fischhof.hu> wrote:
> > Good day all,
> >
> > as it seemed to be a good idea, I wrote a PEP proposal for pathlib to
> > contain file operations.
> >
> > Here is the draft. What do you think about this?
>
> I don't know for certain what I think I feel about the idea - in
> general, it seems plausible. But I think you'll need to get down to
> specifics in the PEP, exactly what functions do you suggest get added
> to pathlib?
>
> Paul
>


Basically  file and directory operations: copy, rename, move, delete. With
all variants.
I will collect them, and put intot PEP

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] New PEP proposal -- Pathlib Module Should Contain All File Operations

[George Fischhof]

Good day all,

as it seemed to be a good idea, I wrote a PEP proposal for pathlib to
contain file operations.

Here is the draft. What do you think about this?

BR,
George

---


PEP: 
Title: Pathlib Module Should Contain All File Operations
Author: George Fischhof 
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 15-Mar-2018
Python-Version: 3.8
Post-History:


Abstract


This PEP proposes pathlib module to be a centralized place for all
file-system related operations.


Rationale
=

Right now we have several modules that contain functions related
to file-system operations mainly the os, pathlib and shutil.
For beginners it is quite hard to remember where can he / she find
a function (copy resides in shutil, but the remove function can be
found in the os module.  (And sometimes developers with moderate
experience have to check the documentation as well.)

After the release of version 3.6 several methods became aware of
path-like object.  There are only a few ones which does not support
the path-like object.  After making these methods path-like object
aware, these functions could be added to pathlib.

With functions in pathlib the developers should not have to think
on which method (function) can be found in which module.

Makes the life easier.


Implementation
==

For compatibility reasons the pathlib should contain wrappers to
the original functions.  The original functions should remain
at their original place.  (Or if pathlib contains the function, the
original modules should have a wrapper to it.)



Copyright
=

This document has been placed in the public domain.


..
   Local Variables:
   mode: indented-text
   indent-tabs-mode: nil
   sentence-end-double-space: t
   fill-column: 70
   coding: utf-8
   End:
___
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] pathlib.Path should handle Pythonpath or package root

[George Fischhof]

Sorry it was misunderstandable.
I do not want to touch the import.

I just would like to access the package root (of my current script).
Practically in a Path object if the package resides in the file system.
Parent is not enough, because the place of actual running script can vary.

BR,
George



2017-07-19 3:51 GMT+02:00 Nick Coghlan <ncogh...@gmail.com>:

> On 19 July 2017 at 06:40, George Fischhof <geo...@fischhof.hu> wrote:
> > I think yes ;-)
> > I would like to use (or I think it would be good to use) something like
> > pathlib.Path(package_root)
> > so I could use
> >
> > importlib.import_module(pathlib.Path(package_root) / plugins /
> plugin_name)
>
> No, as that's fundamentally incompatible with how Python's import
> system works - the filesystem is *a* way of representing package
> namespacing, but far from the only way. Managing the import state also
> has nothing whatsoever to do with pathlib.
>
> That said, the idea of better encapsulating the import state so we can
> more readily have constrained "import engines" *is* a reasonable one,
> it just runs into significant practical problems related to the
> handling of transitive imports in both Python modules and (especially)
> extension modules.
>
> The last serious attempt at pursuing something like that is documented
> in PEP 406, "Improved Encapsulation of Import State":
> https://www.python.org/dev/peps/pep-0406/
>
> Unfortunately, the main outcome of Greg Slodkowicz's GSoC work on the
> idea was to conclude that that particular approach wasn't viable due
> to the fact that import system plugins at that time were pretty much
> required to directly manipulate global state, which ran directly
> counter to the goal of encapsulation.
>
> However, we also haven't had anyone seriously revisit the idea since
> the updated import plugin API was defined in PEP 451 - that
> deliberately moved a lot of the global state management out of the
> plugins and into the import system, so it should be more amenable to
> an "import engine" style approach to state encapsulation.
>
> 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] tempfile.TemporaryDirectory() should be able to create temporary directory at a given arbitrary place

[George Fischhof]

2017-07-18 14:06 GMT+02:00 Serhiy Storchaka <storch...@gmail.com>:

> 18.07.17 14:55, George Fischhof пише:
>
>> I used tempfile.TemporaryDirectory(). On first usage it was good, but on
>> second one there was a need to create tempopray directory and files in it a
>> given place. (It needed for a test).
>>
>> And I found that TemporaryDirectory() is not able to do this. So my idea
>> is to implement this behaviour with an addittional path parameter in it.
>>
>
> You can pass the dir argument to TemporaryDirectory().
>
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>


Hi Serhiy,

thank you very much. ;-) I was lost in documentation... and did not find
this.

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] pathlib.Path should handle Pythonpath or package root

[George Fischhof]

Hi there,

I created a program which uses plugins (import them). I started to test it,
and found that I need two types of paths: one for file system and another
one which is package relative.

So I thing this is a good idea, to enhance pathlib to handle package roots.

(I know about sys.path, environment variables, importlib etc, but I think
it should be in 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] tempfile.TemporaryDirectory() should be able to create temporary directory at a given arbitrary place

[George Fischhof]

Hi there,

I used tempfile.TemporaryDirectory(). On first usage it was good, but on
second one there was a need to create tempopray directory and files in it a
given place. (It needed for a test).

And I found that TemporaryDirectory() is not able to do this. So my idea is
to implement this behaviour with an addittional path parameter in it.


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] socket module: plain stuples vs named tuples

[George Fischhof]

+1 ;-)

for example to get IP address of all interfaces we have to use the third
(indexed as 2) member of "something" it is much more beatiful to get
ip_address:

*import *socket
*for *ip *in *socket.gethostbyname_ex(socket.gethostname())[2]:
print(ip)

BR,
George


2017-06-13 22:13 GMT+02:00 Thomas Güttler :

> AFAIK the socket module returns plain tuples in Python3:
>
>   https://docs.python.org/3/library/socket.html
>
> Why not use named tuples?
>
> Regards,
>   Thomas Güttler
>
> --
> I am looking for feedback for my personal programming guidelines:
> https://github.com/guettli/programming-guidelines
> ___
> 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] Add shutil.ignore_patterns() to shutil.rmtree()

[George Fischhof]

2017. máj. 5. du. 7:02 ezt írta ("Oleg Broytman" <p...@phdru.name>):

On Fri, May 05, 2017 at 04:50:07PM +0200, George Fischhof <
geo...@fischhof.hu> wrote:
> yes, something like that ... ;-) but I use windows, and I want the feature
> in Python, with a simple and elegant way (1-2 commands)
>
> 2017-05-05 16:14 GMT+02:00 Oleg Broytman <p...@phdru.name>:
>
> > On Fri, May 05, 2017 at 03:55:37PM +0200, George Fischhof <
> > geo...@fischhof.hu> wrote:
> > > Actually it would be good if copytree() would be able to overwrite
files
> > > and directories.
> >
> >Seems you want rsync, no?

   I can understand the need but I don't think such a library/script
should be in stdlib.

Oleg.
--
 Oleg Broytmanhttp://phdru.name/p...@phdru.name
   Programmers don't die, they just GOSUB without RETURN.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/



But if shutil.copytree would be able to overwrite, it would be good, and
simetimes enough. And I think it is not too difficult to implement ;-)
___
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 shutil.ignore_patterns() to shutil.rmtree()

[George Fischhof]

yes, something like that ... ;-) but I use windows, and I want the feature
in Python, with a simple and elegant way (1-2 commands)

2017-05-05 16:14 GMT+02:00 Oleg Broytman <p...@phdru.name>:

> On Fri, May 05, 2017 at 03:55:37PM +0200, George Fischhof <
> geo...@fischhof.hu> wrote:
> > Actually it would be good if copytree() would be able to overwrite files
> > and directories.
>
>Seems you want rsync, no?
>
> > George
>
> Oleg.
> --
>  Oleg Broytmanhttp://phdru.name/p...@phdru.name
>Programmers don't die, they just GOSUB without RETURN.
> ___
> 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] Add shutil.ignore_patterns() to shutil.rmtree()

[George Fischhof]

2017-05-05 13:02 GMT+02:00 Oleg Broytman <p...@phdru.name>:

> Hi!
>
> On Fri, May 05, 2017 at 09:58:15AM +0200, George Fischhof <
> geo...@fischhof.hu> wrote:
> > Hi Folks,
> >
> > I have a task to synchronize folders but some files should be remained
> > untouched.
>
>Synchronize folders using rmtree()? I don't get it.
>
> > I think this is a very common task.
>
>I think it is not that common.
>
> > I found that shutil.copytree() has ignore_patterns() but rmtree() has
> not.
> >
> > So here comes my idea: add ignore_patterns() to rmtree() it is a good
>
>rmtree() is like ``rm -r``, not like ``find . -name *.pyc -delete``.
>
> > feature and makes the functions symmetric.
>
>Why impose artificial symmetry?
>
> > BR,
> > George
>
> Oleg.
> --
>  Oleg Broytmanhttp://phdru.name/p...@phdru.name
>Programmers don't die, they just GOSUB without RETURN.
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>



Actually it would be good if copytree() would be able to overwrite files
and directories.

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] Add shutil.ignore_patterns() to shutil.rmtree()

[George Fischhof]

2017-05-05 11:52 GMT+02:00 Serhiy Storchaka <storch...@gmail.com>:

> On 05.05.17 10:58, George Fischhof wrote:
>
>> I have a task to synchronize folders but some files should be remained
>> untouched.
>> I think this is a very common task.
>>
>> I found that shutil.copytree() has ignore_patterns() but rmtree() has not.
>>
>> So here comes my idea: add ignore_patterns() to rmtree() it is a good
>> feature and makes the functions symmetric.
>>
>
> You can't remove a tree when remain its branches. Thus rmtree() with
> ignore_patterns will always fail.
>
> For your particular case I suggest to use os.walk(). You can implement
> arbitrary application specific conditions.
>
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>



If the remaining equals to ignore_pattern plus the container folders, then
it is succesful ;-) In my opinion
___
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] Add shutil.ignore_patterns() to shutil.rmtree()

[George Fischhof]

Hi Folks,

I have a task to synchronize folders but some files should be remained
untouched.
I think this is a very common task.

I found that shutil.copytree() has ignore_patterns() but rmtree() has not.

So here comes my idea: add ignore_patterns() to rmtree() it is a good
feature and makes the functions symmetric.

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] Augmented assignment syntax for objects.

[George Fischhof]

2017. ápr. 25. de. 10:04 ezt írta ("Paul Moore" ):

On 25 April 2017 at 03:53, Steven D'Aprano  wrote:
> On Tue, Apr 25, 2017 at 02:08:05AM +0100, Erik wrote:
>
>> I often find myself writing __init__ methods of the form:
>>
>> def __init__(self, foo, bar, baz, spam, ham):
>>   self.foo = foo
>>   self.bar = bar
>>   self.baz = baz
>>   self.spam = spam
>>   self.ham = ham
>>
>> This seems a little wordy and uses a lot of vertical space on the
>> screen.
>
> It does, and while both are annoying, in the grand scheme of things
> they're a very minor annoyance. After all, this is typically only an
> issue once per class, and not even every class, and vertical space is
> quite cheap. In general, the barrier for accepting new syntax is quite
> high, and "minor annoyance" generally doesn't reach it.

I suspect that with a suitably creative use of inspect.signature() you
could write a decorator for this:

@auto_attrs
def __init__(self, a, b, c):
# Remaining init code, called with self.a, self.b and self.c set

I don't have time to experiment right now, but will try to find time
later. If nothing else, such a decorator would be a good prototype for
the proposed functionality, and may well be sufficient for the likely
use cases without needing a syntax change.

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



Hi, such a decorator would be very grateful ;-) in the standard as for
example I use class parameters this way too in more than 90% of the cases.

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] Third party module in standard library

[George Fischhof]

Hi Guys,

I would like to ask You:
What is the process to propose a module to be part of the standard library?

I would like to propose the following modules:
requests
https://pypi.python.org/pypi/requests

and
xmltodict
https://pypi.python.org/pypi/xmltodict

Both of them makes the life easier, and more simple ;-)
Of course there are several similar libraries -- I know -- and actually
several good modules could be part of standard library. ...

Kind regards,
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] Python package index: query and rating

[George Fischhof]

2017-02-15 12:35 GMT+01:00 Paul Moore :

> On 15 February 2017 at 11:07, Steven D'Aprano  wrote:
> >> I have two ides to improve the package index:
> >
> > Thank you for your ideas, but I don't think this is the right place for
> > suggesting improvements to PyPI. You could try looking through the list
> > of other Python mailing lists:
> >
> > https://mail.python.org/mailman/listinfo
> >
> > Or perhaps somebody else will suggest a better place to raise these
> > issues.
>
> Hi George,
> The PyPI codebase is pretty old and difficult to maintain, so there is
> currently a project under way to replace it with a new implementation.
> The project is hosted at https://github.com/pypa/warehouse and if
> you're interested in getting involved that's probably the best
> starting point for you. With regard to your two specific points:
>
> > 1. Query like in a webshop: checkboxes should use to select from
> attributes
>
> The PyPI search interface is known to be pretty limited. I don't know
> what changes have been put into the warehouse interface so far, but
> I'd suggest checking out the state of their search, and if you still
> feel there's scope for improvements, I'm sure they would be interested
> in suggestions/contributions.
>
> > 2. It would would be good to implement some user rating mechanism like
> in the webshops or software stores.
>
> This has been debated, both here and (I believe) on other lists in the
> past. The general consensus is that it's not immediately obvious that
> this would be beneficial. I'd suggest you do some searches to dig up
> the history of this suggestion (sorry, I don't have any direct links)
> and see if you feel there's something that has been missed - if so,
> again the best place to propose this would be with the Warehouse guys.
>
> Paul
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>


Hi Paul, Steven,

Thank You for your answer, i will check the warehouse :-)

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] Python package index: query and rating

[George Fischhof]

Hi There,

I several times found that it is quite difficult to find an appropriate
library in package index.

I have two ides to improve the package index:

1.)
Query like in a webshop: checkboxes should use to select from attributes.
(topic, environment, category etc) It would br good to put a "do not want"
column as well.

For example right now I would like to search for a cryptographic library
and I have the following page
https://pypi.python.org/pypi?:action=browse=401

It contains 424 libraries.
I would like to select for example desktop, security, sofware development
from topic, and do NOT want any framwork reated libraries (django, flask
etc)


2.)
It would would be good to implement some user rating mechanism like in the
webshops or software stores. It would make the choice easier.


Best regards,
George Fischhof
___
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] OS related file operations (copy, move, delete, rename...) should be placed into one module

[George Fischhof]

2017-01-12 20:11 GMT+01:00 Todd :

> On Thu, Jan 12, 2017 at 11:17 AM, Chris Barker - NOAA Federal <
> chris.bar...@noaa.gov> wrote:
>
>> I agree that this has been a bit of a wart for a long time.
>>
>> While the old “let’s treat strings as paths” modules are split up like
>> you said, pathlib can do what they do and more: https://docs.python.org/
>> 3/library/pathlib.html
>>
>>
>> Exactly -- this is The Solution. It combines paths themselves with things
>> you are likely to do with paths.
>>
>> It may well lack some nice features. If so, suggestions for that would be
>> the way to go.
>>
>
> Can such suggestions go here or should someone start a new 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/
>


Hi Guys,

I just would like to ask You whehet there is a step forward in this topic?

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] Settable defaulting to decimal instead of float

[George Fischhof]

2017-01-12 13:13 GMT+01:00 Stephan Houben :

> Something like:
>
> from __syntax__ import decimal_literal
>
> which would feed the rest of the file through the "decimal_literal"
> transpiler.
> (and not influence anything in other files).
>
> Not sure if you would want to support multiple transpilers per file.
>
> Note that Racket has something similar with their initial "#lang ..."
> directive.
> That only allows a single "language". Possibly wisely so.
>
> Stephan
>
>
> 2017-01-12 12:59 GMT+01:00 אלעזר :
>
>> I think such proposals are special cases of a general theme: a compiler
>> pragma, similar to "from __future__", to make Python support
>> domain-specific syntax in the current file. Whether it's decimal literals
>> or matrix/vector literals etc.
>>
>> I think it will be nice to make some tool, external to Python, that will
>> allow defining such "sibling languages" (transpiled into Python) easily and
>> uniformly.
>>
>> Elazar
>>
>> בתאריך יום ה׳, 12 בינו' 2017, 13:21, מאת Paul Moore ‏> >:
>>
>>> On 12 January 2017 at 10:28, Victor Stinner 
>>> wrote:
>>> > George requested this feature on the bug tracker:
>>> > http://bugs.python.org/issue29223
>>> >
>>> > George was asked to start a discusson on this list. I posted the
>>> > following comment before closing the issue:
>>> >
>>> > You are not the first one to propose the idea.
>>>
>>> OK, but without additional detail (for example, how would the proposed
>>> flag work, if the main module imports module A, then would float
>>> literals in A be decimal or binary? Both could be what the user wants)
>>> it's hard to comment. And as you say, most of this has been discussed
>>> before, so I'd like to see references back to the previous discussions
>>> in any proposal, with explanations of how the new proposal addresses
>>> the objections raised previously.
>>>
>>> Paul
>>
>>

Most of the time one of my students talks to me about decimal vs
> binary, they're thinking that a decimal literal (or converting the
> default non-integer literal to be decimal) is a panacea to the "0.1 +
> 0.2 != 0.3" problem. Perhaps the real solution is a written-up
> explanation of why binary floating point is actually a good thing, and
> not just a backward-compatibility requirement?
>
> ChrisA




from __future__  import use_decimal_instead_of_float
or any other import would be very good.
The most important thing in my point of view is that I do not want to
convert every variable every time to decimal.
Accuracy is important for me (yes, 0.1 + 0.2 should equal to 0.3 , no more,
no less ;-) )

And if it is mentioned, I would like to ask why binary floating point is
"better". It is faster, I agree, but why "better"?

Actually I create test automation (I am a senior QA eng), the fastest test
case runs for about 1-2 minutes. I do not know the exact time difference
between binary and decimal arithmetic, but I do not care with this. My test
would run some microseconds faster. It does not matter at a minute range.

In the tests I calculate with numbers with 4 decimal digits, and I need
exact match. ;-)

Actually I have a new colleague, they did image analysis, and the
calculated much calculations, and they used a library (not python) that is
accurate as well. Becasue accuracy was more important for them as well.

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] Settable defaulting to decimal instead of float

[George Fischhof]

Hi There,

Settable defaulting to decimal instead of float

It would be good to be able to use decimal automatically instead of float
if there is a setting. For example an environment variable or a flag file.

Where and when accuracy is more important than speed, the user could set
this flag, and calculate with decimal numbers as learned in the school.

I think several people would use this function

Best regards,
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] OS related file operations (copy, move, delete, rename...) should be placed into one module

[George Fischhof]

Hi There,

OS related file operations (copy, move, delete, rename...) should be placed
into one module...
As it quite confusing that they are in two moduls (os and shutil).

I have read that one is higher level than other, but actually to use them I
have to think which function can be found in which module.

It is confuse for beginners, and makes the usage more complex instead of
make it more simple (as Zen of Python says ;-) )

An alias could good, not to cause incompatibility.

Best regards,
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/