Re: fs package question - cp -p semantics when copying files?
> > Is there an (unstated) reason why you're using Python and not a system > tool such as rsync? > It's part of a larger application which needs to copy files from a number of locations, not all of which are filesystems on local or remote hosts (think zip archives, s3 buckets, tar files, etc). In that application, I am using the fs package (PyFilesystem). Since it collects files from a number of locations (some static, some updated monthly, some daily), it would be handy if I could preserve file timestamps for post mortem debugging. Skip -- https://mail.python.org/mailman/listinfo/python-list
Re: fs package question - cp -p semantics when copying files?
On Wed, 3 Apr 2019 at 14:55, Skip Montanaro wrote: > It's part of a larger application which needs to copy files from a number > of locations, not all of which are filesystems on local or remote hosts > (think zip archives, s3 buckets, tar files, etc). In that application, I am > using the fs package (PyFilesystem). Since it collects files from a number > of locations (some static, some updated monthly, some daily), it would be > handy if I could preserve file timestamps for post mortem debugging. >From a brief look at the docs, there's an on_copy callback to copy_fs. Maybe you could use the getinfo/setinfo methods to copy over the timestamps and any other file metadata that you want in that callback? Paul -- https://mail.python.org/mailman/listinfo/python-list
Re: fs package question - cp -p semantics when copying files?
> From a brief look at the docs, there's an on_copy callback to copy_fs. > Maybe you could use the getinfo/setinfo methods to copy over the > timestamps and any other file metadata that you want in that callback? Yes, I had gotten to that point when I first posted to the PyFilesystem Google Group. I had tried to figure things out before posting, but hadn't deciphered the docs, source, or test functions. It seems clear I need to generate a dictionary which maps "namespaces" to particular values, but the docs are not clear on what the values are. In particular, it seems the values have different structure for different aspects of the overall set of attributes I want to modify. I'll keep horsing around with it. I just thought someone might have already deciphered this stuff. Skip -- https://mail.python.org/mailman/listinfo/python-list
Re: fs package question - cp -p semantics when copying files?
On Wed, 3 Apr 2019 at 16:06, Skip Montanaro wrote: > > > From a brief look at the docs, there's an on_copy callback to copy_fs. > > Maybe you could use the getinfo/setinfo methods to copy over the > > timestamps and any other file metadata that you want in that callback? > > Yes, I had gotten to that point when I first posted to the > PyFilesystem Google Group. I had tried to figure things out before > posting, but hadn't deciphered the docs, source, or test functions. It > seems clear I need to generate a dictionary which maps "namespaces" to > particular values, but the docs are not clear on what the values are. > In particular, it seems the values have different structure for > different aspects of the overall set of attributes I want to modify. Yeah, the getinfo/setinfo stuff confused me too. But I thought it might be worth mentioning in case you hadn't spotted it. Paul -- https://mail.python.org/mailman/listinfo/python-list
Re: Syntax for one-line "nonymous" functions in "declaration style"
On mer., Apr 3, 2019 at 6:00 PM, python-list-requ...@python.org wrote: On Wed, Apr 3, 2019 at 3:55 AM Alexey Muranov wrote: I clarified what i meant by an assignment, and i believe it to be a usual meaning. 1. `def` is not an assignment, there is no left-hand side or right-hand side. I was talking about the normal assignment by which anyone can bind any value to any variable. Actually, a 'def' statement DOES perform assignment. It does a bit more than that, but it definitely is assignment. You can easily check the CPython disassembly: A command that performs an assignment among other things is not an assignment command itself. Alexey. -- https://mail.python.org/mailman/listinfo/python-list
A request for examples of successful abstracts to scientific python conferences
Dear all, I am thinking of submitting an abstract to EuroSciPy 2019, but (although I am an academic), I am not familiar with the conventions, do's and don'ts of submissions to CS conferences, and this one in particular. Would any kind reader of this list be willing to share with me (off-list) successful abstracts submitted to other editions of this or similar conferences? Also, perhaps, general resources that I should read before responding to a computer science CFP? That would be extremely helpful. Thanks in advance. Best, Manolo Martínez Universitat de Barcelona https://manolomartinez.net -- https://mail.python.org/mailman/listinfo/python-list
Re: A request for examples of successful abstracts to scientific python conferences
On 03/04/2019 18:18, Manolo Martínez wrote: > Dear all, > > I am thinking of submitting an abstract to EuroSciPy 2019, but (although > I am an academic), I am not familiar with the conventions, do's and > don'ts of submissions to CS conferences, and this one in particular. > Would any kind reader of this list be willing to share with me > (off-list) successful abstracts submitted to other editions of this or > similar conferences? Also, perhaps, general resources that I should read > before responding to a computer science CFP? That would be extremely > helpful. You can find the program of previous editions (including of course the abstracts of all talks that were scheduled) on the EuroSciPy website. > > Thanks in advance. Best, > > Manolo Martínez > > Universitat de Barcelona > > https://manolomartinez.net > > > -- https://mail.python.org/mailman/listinfo/python-list
scalable bottleneck
In an email, I received this question as part of a newsletter. def fetch_squares ( max_root ): squares = [] for x in range ( max_root ): squares . append (x **2) return squares MAX = 5 for square in fetch_squares (MAX ): do_something_with ( square ) 1) Do you see a memory bottleneck here? If so, what is it? 2) Can you think of a way to fix the memory bottleneck? Want to know if I am trying to solve the correct bottleneck. I am thinking that the bottleneck is to create a list only to iterate the same list you created sort of doubling the time through. Is that the correct problem to solve? If it is then I thought the best way is just to supply the numbers on the fly, a generator. def supply_squares(max_root): for x in max_root: yield x MAX = 5 So then I set up a loop and do whatever is needed. At this time I am creating generator objects. But is this the correct way to go? More of a am I thinking correctly questino. item = 0 while item < MAX: print(supply_squares(item)) item += 1 Thanks Sayth -- https://mail.python.org/mailman/listinfo/python-list
Re: scalable bottleneck
On 2019-04-03 22:42, Sayth Renshaw wrote: In an email, I received this question as part of a newsletter. def fetch_squares ( max_root ): squares = [] for x in range ( max_root ): squares . append (x **2) return squares MAX = 5 for square in fetch_squares (MAX ): do_something_with ( square ) 1) Do you see a memory bottleneck here? If so, what is it? 2) Can you think of a way to fix the memory bottleneck? Want to know if I am trying to solve the correct bottleneck. I am thinking that the bottleneck is to create a list only to iterate the same list you created sort of doubling the time through. Is that the correct problem to solve? If it is then I thought the best way is just to supply the numbers on the fly, a generator. def supply_squares(max_root): for x in max_root: yield x MAX = 5 So then I set up a loop and do whatever is needed. At this time I am creating generator objects. But is this the correct way to go? More of a am I thinking correctly questino. item = 0 while item < MAX: print(supply_squares(item)) item += 1 You should create a single generator that will yield the squares. The 'for' loop should remain the same. -- https://mail.python.org/mailman/listinfo/python-list
Re: scalable bottleneck
On Thursday, 4 April 2019 10:51:35 UTC+11, Paul Rubin wrote: > Sayth Renshaw writes: > > for x in range ( max_root ): > > 1) Do you see a memory bottleneck here? If so, what is it? > > 2) Can you think of a way to fix the memory bottleneck? > > In Python 2, range(n) creates a list in memory. To make an iterator you > would use xrange instead of range. In Python 3, range(n) is an iterator. > > Either way, fetch_squares creates a list of squares and not an iterator. > > > for square in fetch_squares (MAX ): > > do_something_with ( square ) > > Here's you're creating that list and throwing it away. So you have the > right idea with: > > def supply_squares(max_root): > for x in max_root: > yield x > > But supply_squares returns a generator which means you have to iterate > through it. > > print(supply_squares(item)) > > will print something like > > > > which is what you saw. You want: > >for square in supply_squares(MAX): > print square Ah thanks for your help. Happy I identified the correct bottleneck too. Cheers Sayth -- https://mail.python.org/mailman/listinfo/python-list
Django-hotsauce release 0.9.8
Good morning, We are pleased to announce the following 6 new releases of django-hotsauce and related libraries: - libschevo 4.1 - libdurus 4.1 - libauthkit 0.5.2 - blogengine2 0.9.8 - django-hotsauce 0.9.8 - django-hotsauce-oauthclient 0.3 Download(s): https://pypi.org/project/django-hotsauce/ https://pypi.org/project/django-hotsauce-oauthclient/ https://pypi.org/project/blogengine2/ https://pypi.org/project/libauthkit/ https://pypi.org/project/libschevo/ https://pypi.org/project/libdurus/ Wiki: https://isotopesoftware.ca/wiki/DjangoHotSauce Whats new: https://isotopesoftware.ca/wiki/DjangoHotSauce/Releases/Release-0.9.8 Best regards, tk == tkad...@yandex.com | Twitter: @wise_project https://www.projectstreetwise.org Not everyone who wander are lost. -- https://mail.python.org/mailman/listinfo/python-list
formatted docstrings
I just wrote this (specifics changed for confidentiality reasons):
DEFAULT_ENVVAR = 'APP_VALUE'
def get_handle(setting=None):
f'''Get a handle.
Parameter:
* `setting`: the application setting.
Default from the {DEFAULT_ENVVAR} environment variable.
'''
if setting is None:
setting = os.environ[DEFAULT_ENVVAR]
I thought this was way cool. Until I disovered that there was no
docstring because a format string is not a string literal.
Is it unreasonable to promote bare format strings as candidates for the
docstring?
Cheers,
Cameron Simpson
--
https://mail.python.org/mailman/listinfo/python-list
Re: formatted docstrings
To answer my own question ...
On 04Apr2019 14:05, Cameron Simpson wrote:
I just wrote this (specifics changed for confidentiality reasons):
DEFAULT_ENVVAR = 'APP_VALUE'
def get_handle(setting=None):
f'''Get a handle.
Parameter:
* `setting`: the application setting.
Default from the {DEFAULT_ENVVAR} environment variable.
'''
if setting is None:
setting = os.environ[DEFAULT_ENVVAR]
I thought this was way cool. Until I disovered that there was no
docstring because a format string is not a string literal.
Is it unreasonable to promote bare format strings as candidates for the
docstring?
Sigh. Because such a string _should_ be evaluated in the runtime scope
context of the _called_ function, and it hasn't been called. The current
restriction to string literals (i.e. excluding formatted strings) has no
such ambiguity.
To make the problem with my suggestion clear, to allow a formatted
docstring like the above a function like this:
def f():
f'docstring {foo}'
foo = 9
f'docstring {foo}'
would want to evaluate the first and second f'' string values with
different scope rules, which would be bonkers.
A workaround would look like this:
def f():
f.__doc__ = f'docstring {foo}'
which is annoying, but correct.
Sorry to have bothered everyone,
Cameron Simpson
--
https://mail.python.org/mailman/listinfo/python-list
Re: formatted docstrings
On 04Apr2019 14:14, Cameron Simpson wrote:
Is it unreasonable to promote bare format strings as candidates for
the docstring?
Yes it is. But being annoyed by this I've written this decorator:
def fmtdoc(func):
''' Decorator to replace a function's docstring with that string
formatted against the function's module's __dict__.
This supports simple formatted docstrings:
ENVVAR_NAME = 'FUNC_DEFAULT'
@fmtdoc
def func():
"""Do something with os.environ[{ENVVAR_NAME}]."""
print(os.environ[ENVVAR_NAME])
This gives `func` this docstring:
Do something with os.environ[FUNC_DEFAULT].
'''
func.__doc__ = func.__doc__.format(**sys.modules[func.__module__].__dict__)
return func
I've stuffed it into my cs.deco PyPI package for reuse.
Cheers,
Cameron Simpson
The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all progress
depends on the unreasonable man.- George Bernard Shaw
--
https://mail.python.org/mailman/listinfo/python-list
Re: formatted docstrings
Cameron Simpson writes: > To answer my own question ... > > On 04Apr2019 14:05, Cameron Simpson wrote: > > Is it unreasonable to promote bare format strings as candidates for > > the docstring? > > Sigh. Because such a string _should_ be evaluated in the runtime scope > context of the _called_ function, and it hasn't been called. Another reason why docstrings should only be literals: a common use case is to evaluate the docstrings and put them into static reference documentation. If there's something about the API that will be different depending on where the API is running, but the API documentation just shows me some condition from when the documentation was built, that's a nasty surprise waiting to happen. Instead, the docstring should just explicitly describe the domain of possible values (or whatever it is that's going to change depending on the environment). -- \ “Courage is not the absence of fear, but the decision that | `\ something else is more important than fear.” —Ambrose Redmoon | _o__) | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Re: formatted docstrings
On 04Apr2019 15:40, Ben Finney wrote:
Cameron Simpson writes:
To answer my own question ...
On 04Apr2019 14:05, Cameron Simpson wrote:
> Is it unreasonable to promote bare format strings as candidates for
> the docstring?
Sigh. Because such a string _should_ be evaluated in the runtime scope
context of the _called_ function, and it hasn't been called.
Another reason why docstrings should only be literals: a common use case
is to evaluate the docstrings and put them into static reference
documentation.
Yeah, I do that myself.
If there's something about the API that will be different depending on
where the API is running, but the API documentation just shows me some
condition from when the documentation was built, that's a nasty surprise
waiting to happen. [...]
Certainly that is a concern; I've been thinking just that in the last
several minutes. But on that basis I intend to constrain my own use of
this heavily; I've no intention of embedding dynamic information in
docstrings, just "computable constants" for want of a better term.
My use case was wiring into the docstring the environment variable names
which control some default behaviour, and those names are themselves
constants(*) in the module - they may never change but the module puts
their definitions at the top of the source code:
DEFAULT_BLAH_ENVVAR = 'APP_BLAH'
Absent monkey patching, I wanted an end user to know the environment
variable name directly without performing tedious source code
inspection.
I'm certainly considering constructions like:
Default value from os.environ[DEFAULT_BLAH_ENVVAR] i.e.
${DEFAULT_BLAH_ENVVAR}.
which would turn into:
Default value from os.environ[DEFAULT_BLAH_ENVVAR] i.e.
$APP_BLAH.
though that is then harder to read, albeit more precise.
Cheers,
Cameron Simpson
* Yes I know Python doesn't have real constants, let's not bicker here.
--
https://mail.python.org/mailman/listinfo/python-list
