Re: [Python-ideas] Idea: msgfmt.py and pygettext..py should be -m executable modules

[Petr Viktorin]

On Mon, Jul 23, 2018 at 2:16 PM, Miro Hrončok  wrote:
> Currently, the documentation (as well as plenty of other places on the
> Internet, such as Stack Overflow answers) mentions msgfmt.py and
> pygettext.py.
>
> See https://docs.python.org/3/library/gettext.html
>
>> (Python also includes pure-Python versions of these programs, called
>> pygettext.py and msgfmt.py; some Python distributions will install
>> them for you. pygettext.py is similar to xgettext, but only
>> understands Python source code and cannot handle other programming
>> languages such as C or C++. pygettext.py supports a command-line
>> interface similar to xgettext; for details on its use, run
>> pygettext.py --help. msgfmt.py is binary compatible with GNU msgfmt.
>> With these two programs, you may not need the GNU gettext package to
>> internationalize your Python applications.)
>
> The problematic part is: "some Python distributions will install them for
> you"
>
> As a Python distributor, I may ask myself a question: Where do I install
> those?
>
> As a Python user, I may ask: Where did the distributors put them, and did
> they?
>
> So I suggest we make those modules instead and we document how to use them.

Not completely "instead" perhaps; the original Tools/i18n/*.py scripts
can be changed to just import the new module and call it.

> It might be:
>
>   $ python3 -m gettext

+1

> And:
>
>   $ python3 -m gettext.msgfmt

+1
Note that this means gettext will need to become a package.

> And (provided as a shortcut):
>
>   $ python3 -m msgfmt

-1. This would mean adding a new top-level module to the standard
library. Let's not pollute that namespace just to provide a shortcut.

>
> I feel that using -m is the general direction Python is going, considering
> this message:
>
>   $ pyvenv ...
>   WARNING: the pyenv script is deprecated in favour of `python3.7 -m venv`
>
> It also gives the user a choice for Python version on a system with multiple
> Python versions installed as the user could do:
>
>   $ python3.6 -m gettext
>
> Or
>
>   $ python3.7 -m gettext
>
> While with e.g. /usr/bin/pygettext.py this adds unnecessary burden on the
> distributor to package /usr/bin/pygettext-3.7.py etc...

Yes – pygettext depends on the Python version, so being able to do
this sounds very useful. Less so for msgfmt of course.

I'm adding Barry Warsaw, who originally wrote pygettext and AFAIK
still does i18n in Python.
Barry, does this sound reasonable to you?
___
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] Was `os.errno` undocumented?

[Petr Viktorin]

(Apologies if you received an empty/unfinished e-mail here earlier; I 
hit Send by mistake.)


On 05/29/18 13:57, Steven D'Aprano wrote:

On Tue, May 29, 2018 at 12:06:42PM +0200, Petr Viktorin wrote:

Hello,
Python 3.7 removes the undocumented internal import `os.errno`.
We consider that a an implementation detail, which can be changed
*without notice* even in a bugfix release. Projects that depend on it
are incorrect and should be fixed.


PEP 8 makes it clear that imports are implementation details unless
explicitly documented otherwise:

 Imported names should always be considered an implementation detail.
 Other modules must not rely on indirect access to such imported names
 unless they are an explicitly documented part of the containing
 module's API, such as os.path or a package's __init__ module that
 exposes functionality from submodules.


This decision dates back to 2013:

https://mail.python.org/pipermail/python-dev/2013-July/127284.html

so it has been around for a while, long enough that linters ought to be
enforcing it, and people ought to know about it. If not, that's a
failure of the linter and/or the coder.



On bpo-33666, there's a debate on whether the removal should be
mentioned in release notes, on the grounds that it broke some projects,
is used in quire a few tutorials/books/examples, and it's been working
since Python 2.5 or so.


I don't see why there should be a debate about mentioning it in the
release notes. There's no harm in adding a few lines:

"os.errno is a non-public implementation detail, as described in PEP 8,
and has been removed. Import the errno module instead."

Being an implementation detail, we aren't *required* to do so, but given
that (so you say) a few tutorials etc use it, I think it is the kind
thing to do.




But here's the thing: the more I think about this, the less I consider
`os.errno` as "undocumented". Here's what I consider a reasonable path a
programmer might go through:

[...]

All of this is reasonable, and I'm sympathetic, *except* that it is
officially documented policy that imports are implementation details
unless otherwise stated.


I agree that it's technically well within our rights to remove it 
without notice.
But ... PEP8? A style guide defines what is a CPython implementation 
detail? That's not a place to point to while saying "told you so!" -- 
perhaps "sorry for the inconvenience" would be more appropriate :)



If os.errno was gone and there was no easy fix, I think we could be
merciful and rethink the decision. But there is an easy fix: import
errno directly instead.

And maybe this will encourage linters to flag this risky usage, if they
aren't already doing so.


How do linters find out what's an internal import, and what's correct 
usage (like os.path)?



As you can see, the built-in documentation does not contain *any*
warnings against using `os.errno`.


It doesn't need to.

And of course, help(os.errno) *cannot* warn about os.errno, since it
only receives the errno module as argument, not the expression you used
to pass it.


Indeed. That's unfortunate, but it is a reason for us to be careful, or 
perhaps find/document a better policy for handling these.


I'm not looking for evidence to justify the changes; I'm looking for 
ways to be more friendly to our users -- most of whom have not read all 
of the docs.

___
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] Was `os.errno` undocumented?

[Petr Viktorin]

On 05/29/18 13:57, Steven D'Aprano wrote:

On Tue, May 29, 2018 at 12:06:42PM +0200, Petr Viktorin wrote:

Hello,
Python 3.7 removes the undocumented internal import `os.errno`.
We consider that a an implementation detail, which can be changed
*without notice* even in a bugfix release. Projects that depend on it
are incorrect and should be fixed.


PEP 8 makes it clear that imports are implementation details unless
explicitly documented otherwise:

 Imported names should always be considered an implementation detail.
 Other modules must not rely on indirect access to such imported names
 unless they are an explicitly documented part of the containing
 module's API, such as os.path or a package's __init__ module that
 exposes functionality from submodules.


This decision dates back to 2013:

https://mail.python.org/pipermail/python-dev/2013-July/127284.html

so it has been around for a while, long enough that linters ought to be
enforcing it, and people ought to know about it. If not, that's a
failure of the linter and/or the coder.





On bpo-33666, there's a debate on whether the removal should be
mentioned in release notes, on the grounds that it broke some projects,
is used in quire a few tutorials/books/examples, and it's been working
since Python 2.5 or so.


I don't see why there should be a debate about mentioning it in the
release notes. There's no harm in adding a few lines:

"os.errno is a non-public implementation detail, as described in PEP 8,
and has been removed. Import the errno module instead."

Being an implementation detail, we aren't *required* to do so, but given
that (so you say) a few tutorials etc use it, I think it is the kind
thing to do.




But here's the thing: the more I think about this, the less I consider
`os.errno` as "undocumented". Here's what I consider a reasonable path a
programmer might go through:

[...]

All of this is reasonable, and I'm sympathetic, *except* that it is
officially documented policy that imports are implementation details
unless otherwise stated.

If os.errno was gone and there was no easy fix, I think we could be
merciful and rethink the decision. But there is an easy fix: import
errno directly instead.

And maybe this will encourage linters to flag this risky usage, if they
aren't already doing so.



As you can see, the built-in documentation does not contain *any*
warnings against using `os.errno`.


It doesn't need to.

And of course, help(os.errno) *cannot* warn about os.errno, since it
only receives the errno module as argument, not the expression you used
to pass it.



___
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] Allow mutable builtin types (optionally)

[Petr Viktorin]

On 05/07/18 11:37, Eloi Gaudry wrote:

Hi,

I'd like to bring back this discussion (from 2005, by Greg):
https://bugs.python.org/issue1229239

Briefly, non-heap types cannot have their
attributes changed by Python code. This makes sense for python builtin
types, but not for the types defined in extension/modules.

As we have been using this patch for the very same reasons and for more
than 10 years, I think it might make sense to reconsider the discussion
that Greg started.

The main question at that time was "why not using a heap type instead
?" (because heap-type do not have this limitation).

But I think that the right question could have been "why imposing such
a restriction on non-heap types as defined in (non Python core)
extensions ?".

I mean, to my knowledge, there is no reason why a type should be
allocated on the heap (https://docs.python.org/2/c-api/typeobj.html) to
be able to change its attributes at Python level.


One reason is sub-interpreter support: you can have multiple 
interpreters per process, and those shouldn't influence each other.

(see https://docs.python.org/3/c-api/init.html#sub-interpreter-support)

With heap types, each sub-interpreter can have its own copy of the type 
object. But with builtins, changes done in one interpreter would be 
visible in all the others.




I'm not saying that all non-heap types should be able to do so, just
that it would make sense to allow this behavior, as an option (bit
flag).

At the implementation level, the changes needed are really limited
(about a few lines):
- Include/object.h
- Objects/typeobject.c:

Eloi

___
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] collections.Counter should implement __mul__, __rmul__

[Petr Viktorin]

On 04/18/18 17:33, Raymond Hettinger wrote:




On Apr 16, 2018, at 5:43 PM, Tim Peters  wrote:

BTW, if _`Counter * scalar` is added, we should think more about
oddball cases.  While everyone knows what _they_ mean by "scalar",
Python doesn't.


I've started working on an implementation and several choices arise:

1) Reject scalar with a TypeError if scalar is a Counter
2) Reject scalar with a TypeError if scalar is a Mapping
3) Reject scalar with a TypeError if scalar is a Collection
4) Reject scalar with a TypeError if scalar is Sized (has a __len__ method).


Why is Iterable (__iter__) not on the list?

(Apologies if I missed this somewhere in the conversation.)



I lean toward rejecting all things Sized because _everyone_ knows that scalars 
aren't sized ;-)


Raymond


___
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] Move optional data out of pyc files

[Petr Viktorin]

On 04/11/18 08:06, Steven D'Aprano wrote:

On Wed, Apr 11, 2018 at 02:21:17PM +1000, Chris Angelico wrote:

[...]

Yes, it will double the number of files. Actually quadruple it, if the
annotations and line numbers are in separate files too. But if most of
those extra files never need to be opened, then there's no cost to them.
And whatever extra cost there is, is amortized over the lifetime of the
interpreter.


Yes, if they are actually not needed. My question was about whether
that is truly valid.


We're never really going to know the affect on performance without
implementing and benchmarking the code. It might turn out that, to our
surprise, three quarters of the std lib relies on loading docstrings
during startup. But I doubt it.



Consider a very common use-case: an OS-provided
Python interpreter whose files are all owned by 'root'. Those will be
distributed with .pyc files for performance, but you don't want to
deprive the users of help() and anything else that needs docstrings
etc. So... are the docstrings lazily loaded or eagerly loaded?


What relevance is that they're owned by root?



If eagerly, you've doubled the number of file-open calls to initialize
the interpreter.


I do not understand why you think this is even an option. Has Serhiy
said something that I missed that makes this seem to be on the table?
That's not a rhetorical question -- I may have missed something. But I'm
sure he understands that doubling or quadrupling the number of file
operations during startup is not an optimization.



(Or quadrupled, if you need annotations and line
numbers and they're all separate.) If lazily, things are a lot more
complicated than the original description suggested, and there'd need
to be some semantic changes here.


What semantic change do you expect?

There's an implementation change, of course, but that's Serhiy's problem
to deal with and I'm sure that he has considered that. There should be
no semantic change. When you access obj.__doc__, then and only then are
the compiled docstrings for that module read from the disk.

I don't know the current implementation of .pyc files, but I like
Antoine's suggestion of laying it out in four separate areas (plus
header), each one marshalled:

 code
 docstrings
 annotations
 line numbers

Aside from code, which is mandatory, the three other sections could be
None to represent "not available", as is the case when you pass -00 to
the interpreter, or they could be some other sentinel that means "load
lazily from the appropriate file", or they could be the marshalled data
directly in place to support byte-code only libraries.

As for the in-memory data structures of objects themselves, I imagine
something like the __doc__ and __annotation__ slots pointing to a table
of strings, which is not initialised until you attempt to read from the
table. Or something -- don't pay too much attention to my wild guesses.


A __doc__ sentinel could even say something like "bytes 350--420 in the 
original .py file, as UTF-8".




The bottom line is, is there some reason *aside from performance* to
avoid this? Because if the performance is worse, I'm sure Serhiy will be
the first to dump this idea.



___
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] Move optional data out of pyc files

[Petr Viktorin]

On 04/11/18 06:21, Chris Angelico wrote:

On Wed, Apr 11, 2018 at 1:02 PM, Steven D'Aprano  wrote:

On Wed, Apr 11, 2018 at 10:08:58AM +1000, Chris Angelico wrote:


File system limits aren't usually an issue; as you say, even FAT32 can
store a metric ton of files in a single directory. I'm more interested
in how long it takes to open a file, and whether doubling that time
will have a measurable impact on Python startup time. Part of that
cost can be reduced by using openat(), on platforms that support it,
but even with a directory handle, there's still a definite non-zero
cost to opening and reading an additional file.


Yes, it will double the number of files. Actually quadruple it, if the
annotations and line numbers are in separate files too. But if most of
those extra files never need to be opened, then there's no cost to them.
And whatever extra cost there is, is amortized over the lifetime of the
interpreter.


Yes, if they are actually not needed. My question was about whether
that is truly valid. Consider a very common use-case: an OS-provided
Python interpreter whose files are all owned by 'root'. Those will be
distributed with .pyc files for performance, but you don't want to
deprive the users of help() and anything else that needs docstrings
etc.


Currently in Fedora, we ship *both* optimized and non-optimized pycs to 
make sure both -O and non--O will work nicely without root privilieges. 
So splitting the docstrings into a separate file would be, for us, a 
benefit in terms of file size.




So... are the docstrings lazily loaded or eagerly loaded? If
eagerly, you've doubled the number of file-open calls to initialize
the interpreter. (Or quadrupled, if you need annotations and line
numbers and they're all separate.) If lazily, things are a lot more
complicated than the original description suggested, and there'd need
to be some semantic changes here.


Serhiy is experienced enough that I think we should assume he's not
going to push this optimization into production unless it actually does
reduce startup time. He has proven himself enough that we should assume
competence rather than incompetence :-)


Oh, I'm definitely assuming that he knows what he's doing :-) Doesn't
mean I can't ask the question though.

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

[Petr Viktorin]

On 03/19/18 09:17, Stephen J. Turnbull wrote:

Nathaniel Smith writes:
  > Similarly, it's hard to explain why we have Path.mkdir but not
  > Path.makedirs

So what?  Let's fix that.  As you propose:

  > (maybe it should be Path.mkdir(include_parents=True)
> is fine, although that default seems a little risky vs. typos.  I know
I have confused myself with mkdir -p that way a few (though very few)
times.  Perhaps Guido would prefer Path.makedirs for this functionality.


This is already there as Path.mkdir(parents=True).

___
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] Official site-packages/test directory

[Petr Viktorin]

FWIW, I've had very good experience with putting tests for package `foo` 
in a directory/package called `test_foo`.


This combines the best of both worlds -- it can be easily separated for 
distribution (like `tests`), and it doesn't cause name conflicts (like 
`foo.tests`).



On 01/19/2018 05:23 PM, Paul Moore wrote:

Another common approach is to not ship tests as part of your (runtime)
package at all - they are in the sdist but not the wheels nor are they
deployed with "setup.py install". In my experience, this is the usual
approach projects take if they don't have the tests in the package
directory. (I don't think I've *ever* seen a project try to install
tests except by including them in the package directory...)

Paul

On 19 January 2018 at 16:10, Guido van Rossum  wrote:

IIUC another common layout is to have folders named test or tests inside
each package. This would avoid requiring any changes to the site-packages
layout.

On Fri, Jan 19, 2018 at 6:27 AM, Stefan Krah  wrote:



Hello,

I wonder if we could get an official site-packages/test directory.
Currently
it seems to be problematic to distribute tests if they are outside the
package
directory.  Here is a nice overview of the two main layout possibilities:


http://pytest.readthedocs.io/en/reorganize-docs/new-docs/user/directory_structure.html


I like the outside-the-package approach, mostly for reasons described very
eloquently here:


http://python-notes.curiousefficiency.org/en/latest/python_concepts/import_traps.html


CPython itself of course also uses Lib/foo.py and Lib/test/test_foo.py, so
it
would make sense to have site-packages/foo.py and
site-packages/test/test_foo.py.

For me, this is the natural layout.

___
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] Repurpose `assert' into a general-purpose check

[Petr Viktorin]

On 11/29/2017 08:31 PM, Barry Warsaw wrote:


Nathan Schneider wrote:


I think it would be interesting to investigate how assert statements are
used in the wild. I can think of three kinds of uses:


assert statements are also a form of executable documentation.  It says
something like "I think the internal state of my code must be this way,
otherwise I don't really understand what I wrote".

Now, maybe you could argue that such use should be enabled
unconditionally, but I disagree since usually your understanding of the
state of your code is correct, so the additional checks are unnecessary,
and people *do* use -O and -OO in practice.  And these days it's even
more practical to do so, given the `opt-*` level of pyc tagging:

% python3 -c "import foo"
% python3 -O -c "import foo"
% python3 -OO -c "import foo"
% ls foo/__pycache__/
__init__.cpython-36.opt-1.pyc   __init__.cpython-36.pyc
__init__.cpython-36.opt-2.pyc

I also wonder how this would interact with pytest's um, 'hijacking' of
the assert statement.


Pytest compiles from source, and uses its own cache tags which look like 
".cpython-36-PYTEST.pyc".


https://github.com/pytest-dev/pytest/blob/master/_pytest/assertion/rewrite.py


___
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] venv *is* provided in the standard Python install on Debian/Ubuntu

[Petr Viktorin]

On 11/13/2017 11:05 AM, Antoine Pitrou wrote:

On Mon, 13 Nov 2017 12:32:06 +1000
Nick Coghlan  wrote:

On 13 November 2017 at 04:38, Antoine Pitrou  wrote:

On Sun, 12 Nov 2017 12:20:45 +
Paul Moore  wrote:
  

Well, not exactly. Do you do python -m venv, or py -x.x -m venv or
pythonx -m venv ? Wait, it's not installed by default on debian.


Seriously? Debian don't provide venv in the standard Python install?
That's just broken.


Frankly, I don't know where the current discussion comes from, but on
two recent Debian and Ubuntu setups, I get:

$ dpkg -S /usr/lib/python3.5/venv/__init__.py
libpython3.5-stdlib:amd64: /usr/lib/python3.5/venv/__init__.py


The discussion comes from the fact that even though the code is
present it doesn't actually work:

[...]

Wow.  I had forgotten Debian could be such a user-hostile
distribution.  I'm not sure what the reason would be to use it as a
basis for a training course in Python programming, then (other than the
teacher having their own ideological preferences).


For us, it's the *student's* preference. I believe it's better to let 
students use the machine and environment they're used to, even if it 
means extra trouble for the instructors.
So, we get a healthy mix of Windows, Mac, Debian, Fedora, and sometimes 
some surprises.


___
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-ideas Digest, Vol 131, Issue 106

[Petr Viktorin]

On 10/31/2017 09:54 AM, Koos Zevenhoven wrote:
On Tue, Oct 31, 2017 at 10:01 AM, Chris Angelico >wrote:


On Tue, Oct 31, 2017 at 6:46 PM, Steven D'Aprano
> wrote:
> On Tue, Oct 31, 2017 at 06:02:34PM +1100, Chris Angelico wrote:
>> One small change: If you use next(i) instead of i.next(), your code
>> should work on both Py2 and Py3. But other than that, I think it's
>> exactly the same as most people would expect of this function.
>
> Not me. As far as I can tell, that's semantically equivalent to:
>
> def single(i):
>     result, = i
>     return result
>
> apart from slightly different error messages.

I saw the original code as being like the itertools explanatory
functions - you wouldn't actually USE those functions, but they tell
you what's going on when you use the simpler, faster, more compact
form.


​I wonder if that's more easily understood if you write it along these 
line(s):


   (the_bob,) = ​(name for name in ('bob','fred') if name=='bob')


There are (unfortunately) several ways to do it. I prefer one that 
avoids a trailing comma:


[the_bob] = ​(name for name in ('bob','fred') if name=='bob')

___
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] Exposing CPython's subinterpreter C-API in the stdlib.

[Petr Viktorin]

On 05/25/2017 09:01 PM, Eric Snow wrote:

On Thu, May 25, 2017 at 11:19 AM, Nathaniel Smith  wrote:

My impression is that the code to support them inside CPython is fine, but
they're broken and not very useful in the sense that lots of C extensions
don't really support them, so in practice you can't reliably use them to run
arbitrary code. Numpy for example definitely has lots of
subinterpreter-related bugs, and when they get reported we close them as
WONTFIX.

Based on conversations at last year's pycon, my impression is that numpy
probably *could* support subinterpreters (i.e. the required apis exist), but
none of us really understand the details, it's the kind of problem that
requires a careful whole-codebase audit, and a naive approach might make
numpy's code slower and more complicated for everyone. (For example, there
are lots of places where numpy keeps a little global cache that I guess
should instead be per-subinterpreter caches, which would mean adding an
extra lookup operation to fast paths.)


Thanks for pointing this out.  You've clearly described probably the
biggest challenge for folks that try to use subinterpreters.  PEP 384
was meant to help with this, but seems to have fallen short.  PEP 489
can help identify modules that profess subinterpreter support, as well
as facilitating future extension module helpers to deal with global
state.  However, I agree that *right now* getting extension modules to
reliably work with subinterpreters is not easy enough.  Furthermore,
that won't change unless there is sufficient benefit tied to
subinterpreters, as you point out below.


PEP 489 was a first step; the work is not finished. The next step is 
solving a major reason people are using global state in extension 
modules: per-module state isn't accessible from all the places it should 
be, namely in methods of classes. In other words, I don't think Python 
is ready for big projects like Numpy to start properly supporting 
subinterpreters.


The work on fixing this has stalled, but it looks like I'll be getting 
back on track.
Discussions about this are on the import-sig list, reach out there if 
you'd like to help.

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

[Petr Viktorin]

On 01/25/2017 04:04 PM, Todd wrote:

On Wed, Jan 25, 2017 at 12:25 AM, Stephen J. Turnbull
> wrote:

I'm just going to let fly with the +1s and -1s, don't take them too
seriously, they're basically impressionistic (I'm not a huge user of
pathlib yet).

Todd writes:

 > So although the names are tentative, perhaps there could be a
"fullsuffix"
 > property to return the extensions as a single string,

-0  '.'.join(p.suffixes) vs. p.fullsuffix?  TOOWTDI says no.  I
also don't really see the use case.


The whole point of pathlib is to provide convenience functions for
common path-related operations.  It is full of methods and properties
that could be implemented other ways.

Dealing with multi-part extensions, at least for me, is extremely
common.  A ".tar.gz" file is not the same as a ".tar.bz2" or a
".svg.gz".  When I want to find a ".tar.gz" file, having to deal with
the ".tar" and ".gz" parts separately is nothing but a nuisance.  If I
want to find and extract ".rar" files, I don't want ".part1.rar" files,
".part2.rar" files, and so on.  So for me dealing with the extension as
a single unit, rather than individual parts, is the most common  approach.


But what if the .tar.gz file is called "spam-4.2.5-final.tar.gz"?
Existing tools like glob and endswith() can deal with the ".tar.gz" 
extension reliably, but "fullsuffix" would, arguably, not give the 
answers you want.


Perhaps more specialized tools would be useful, though, for example:
repacked_path = original_path.replace_suffix(".tar.gz", ".zip")

___
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] globals should accept parenteses for extending beyond 1 line

[Petr Viktorin]

On 01/23/2017 10:22 PM, João Matos wrote:

Hello,

I understand.
Python sources are very large. Any pointers to which file defines the
global statement syntax?


Consider joining the core-mentorship list for questions like these:
https://mail.python.org/mailman/listinfo/core-mentorship

Anyway, Python's grammar is defined in the file Grammar/Grammar, and 
there's a mini-HOWTO at the top of that file. Good luck!


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