On Tue, May 14, 2019 at 6:19 AM Steven D'Aprano wrote:
> The problem is a lack of a symlink function that safely overwrites an
> existing file or symlink. We're just bike-shedding over its spelling
> and where it lives:
>
> - modify os.symlink and give it a "force" parameter
> - add a new functio
On Tue, May 14, 2019 at 4:34 AM Steven D'Aprano wrote:
> You "see ... no obvious difference" between two functions that live in
> completely different modules?
>
>
>
> The bottom line is that it is completely normal and not uncommon for
> functions to be distinguished by the namespace they are fo
On 5/14/19, Serge Matveenko wrote:
>
> My point was that in case of `os.symlink` vs `shutil.symlink` it is
> not obvious how they are different even taking into account their
> namespaces.
I prefer to reserve POSIX system call names if possible, unless it's a
generic name such as "open" or "close
On 14/5/19 10:53 am, Brett Cannon wrote:
Bugs about the website should be reported to
https://github.com/python/pythondotorg .
Thanks, reported at: https://github.com/python/pythondotorg/issues/1435
--
Tom Hale
___
Python-ideas mailing list
Python-id
When I signed up, I got an email with subject:
Welcome to the "Python-ideas" mailing list
It included the text:
==
You must know your password to change your options (including changing
the password, itself) or to unsubscr
How do I search this list's archives?
I can't see any search functionality at:
https://mail.python.org/pipermail/python-ideas/
Using the other archive recommended recently:
https://code.activestate.com/search/lists/?sa=Search&list=python-ideas#q=mailman%20password
Gives me:
The Google Web Se
On 14/5/19 4:46 pm, Tom Hale wrote:
How do I search this list's archives?
Inspiration struck:
Google for:
site:https://mail.python.org/pipermail/python-ideas/ search terms
--
Tom Hale
___
Python-ideas mailing list
[email protected]
https://ma
On Tue, May 14, 2019 at 04:46:48PM +0700, Tom Hale wrote:
> How do I search this list's archives?
With Google:
site:mail.python.org the_search_term
Google nearly always has better results than the search features of
individual websites.
Stefan Krah
__
On 14/05/2019 05:50, Anders Hovmöller wrote:
On 14 May 2019, at 04:24, Steven D'Aprano wrote:
*wink*. Function names are mnemonics, not documentation.
Certainly not with that attitude. But it easily could be. Maybe you would be
fine with a language where all function names are just hex va
On 5/14/19 5:35 AM, Tom Hale wrote:
> When I signed up, I got an email with subject:
>
> Welcome to the "Python-ideas" mailing list
>
> It included the text:
>
> ==
>
> You must know your password to change your options (includ
13.05.19 12:38, Tom Hale пише:
As suggested by Toshio Kuratomi at https://bugs.python.org/issue36656, I
am raising this here for inclusion in the shutil module.
Mimicking POSIX, os.symlink() will raise FileExistsError if the link
name to be created already exists.
A common use case is overwr
On 5/14/19 6:55 AM, Rhodri James wrote:
> On 14/05/2019 05:50, Anders Hovmöller wrote:
>>
>>
>>> On 14 May 2019, at 04:24, Steven D'Aprano wrote:
>>>
>>> *wink*. Function names are mnemonics, not documentation.
>>
>> Certainly not with that attitude. But it easily could be. Maybe you
>> would be f
On Tue, May 14, 2019 at 10:37:57AM +0300, Serge Matveenko wrote:
> My point was that in case of `os.symlink` vs `shutil.symlink` it is
> not obvious how they are different even taking into account their
> namespaces.
Okay, but that's not what you said. I can't respond to what you meant to
say in
> On 14 May 2019, at 14:13, Steven D'Aprano wrote:
>
>> On Tue, May 14, 2019 at 10:37:57AM +0300, Serge Matveenko wrote:
>>
>> My point was that in case of `os.symlink` vs `shutil.symlink` it is
>> not obvious how they are different even taking into account their
>> namespaces.
>
> Okay, but
On Tue, May 14, 2019 at 10:26:28AM +0300, Serge Matveenko wrote:
> How about introducing `force=False` argument to
> `pathlib.Path.symlink_to` method?
> It looks like a good place for this as `pathlib` is actually the place
> where higher-level things to operate on paths live already
I don't thi
On Tue, May 14, 2019 at 02:43:03PM +0300, Serhiy Storchaka wrote:
> Sorry, but I do not understand what problem do you try to solve. If
> somebody can create a file named link_name between unlink and symlink,
> he can also remove and create a file named link_name after symlink.
I don't think th
On 5/14/19, Steven D'Aprano wrote:
>
> On posix systems, you should be able to use chattr +i to make the file
> immutable, so that the attacker cannot remove or replace it.
Minor point of clarification. File attributes, and APIs to access
them, are not in the POSIX standard. chattr is a Linux com
Currently if one wants to provide positional arguments after keyword
arguments, it's not possible, one must begin with positional arguments [1]
or use keyword arguments [2] :
```
def f(x, *, long_name='foo'): return ...
f(2, long_name='bar') # [1]
f(long_name='bar', x=2) # [2]
```
The problem
> On 15 May 2019, at 03:07, Robert Vanden Eynde wrote:
>
> Currently if one wants to provide positional arguments after keyword
> arguments, it's not possible, one must begin with positional arguments [1] or
> use keyword arguments [2] :
I'm my opinion the goal should be that there is no su
Le mer. 15 mai 2019 à 07:37, Anders Hovmöller a
écrit :
>
>
> > On 15 May 2019, at 03:07, Robert Vanden Eynde
> wrote:
> >
> > Currently if one wants to provide positional arguments after keyword
> arguments, it's not possible, one must begin with positional arguments [1]
> or use keyword argume
On Wed, May 15, 2019 at 1:37 AM Anders Hovmöller wrote:
>
> > On 15 May 2019, at 03:07, Robert Vanden Eynde wrote:
> >
> > Currently if one wants to provide positional arguments after keyword
> > arguments, it's not possible, one must begin with positional arguments [1]
> > or use keyword argum
21 matches
Mail list logo
