Everyone,
If you've commented and you're worried you haven't been heard, please add
your issue *concisely* to this new thread. Note that the following issues
are already open and will be responded to separately; please don't bother
commenting on these until we've done so:
- Alternative spellings for '|'
- Whether to add an 'else' clause (and how to indent it)
- A different token for wildcards instead of '_'
- What to do about the footgun of 'case foo' vs. 'case .foo'
(Note that the last two could be combined, e.g. '?foo' or 'foo?' to mark a
variable binding and '?' for a wildcard.)
--
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*
<http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-…>
I have problem with the location of hexadecimal memory address in custom
reprs.
<threading.BoundedSemaphore: 2/3 at 0x7ff4c26b3eb0>
vs
<threading.BoundedSemaphore at 0x7ff4c26b3eb0: 2/3>
The long hexadecimal number makes the repr longer and distracts
attention from other useful information. We could get rid of it, but it
is useful if we want to distinguish objects of the same type. Although
it is hard to distinguish long hexadecimal numbers which differ only by
few digits in the middle.
What if use serial numbers to differentiate instances?
<threading.BoundedSemaphore #5: 2/3>
where the serial number starts with 1 and increased for every new
instance of that type.
The advantages are:
* Shorter repr.
* Easier to distinguish different objects.
* The serial number is unique for the life of program and cannot be
reused (in contrary to id/memory address).
The disadvantages are:
* Increased object size and creation time.
I do not propose to use serial numbers for all objects, because it would
increase the size of objects and the fixed-size integer can be
overflowed for some short-living objects created in mass (like numbers,
strings, tuples). But only for some custom objects implemented in
Python, for which size and creation time are not critical. I want to
start with synchronization objects in threading and multiprocessing
which did not have custom reprs, than change reprs of locks and asyncio
objects.
Is it worth to do?
> On 25 Jul 2020, at 03:44, Rob Cliffe <rob.cliffe(a)btinternet.com> wrote:
>
> Without arguing for or against allowing a capture variable, IMO rather
> than syntax like
> match <expr> into <var>:
> it would be far better (and not require a new keyword) to write this as
> with <var> as match <expr>:
>
> On 24/06/2020 20:38, Guido van Rossum wrote:
>> Everyone,
>>
>> If you've commented and you're worried you haven't been heard, please=20
>> add your issue *concisely* to this new thread. Note that the following=20
>> issues are already open and will be responded to separately; please=20
>> don't bother commenting on these until we've done so:
>>
>> - Alternative spellings for '|'
>> - Whether to add an 'else' clause (and how to indent it)
>> - A different token for wildcards instead of '_'
>> - What to do about the footgun of 'case foo' vs. 'case .foo'
>>
>> (Note that the last two could be combined, e.g. '?foo' or 'foo?' to=20
>> mark a variable binding and '?' for a wildcard.)
>>
We already have 'with' for contexts.
We already have patterns with 'as':
- except expression "as" identifier ":"
- "import" module "as" identifier
- "with" expression "as" target
So I think this would be quite confusing.
> On 25 Jul 2020, at 03:44, Rob Cliffe <rob.cliffe(a)btinternet.com> wrote:
>
> Without arguing for or against allowing a capture variable, IMO rather
> than syntax like
> match <expr> into <var>:
> it would be far better (and not require a new keyword) to write this as
> with <var> as match <expr>:
>
> On 24/06/2020 20:38, Guido van Rossum wrote:
>> Everyone,
>>
>> If you've commented and you're worried you haven't been heard, please=20
>> add your issue *concisely* to this new thread. Note that the following=20
>> issues are already open and will be responded to separately; please=20
>> don't bother commenting on these until we've done so:
>>
>> - Alternative spellings for '|'
>> - Whether to add an 'else' clause (and how to indent it)
>> - A different token for wildcards instead of '_'
>> - What to do about the footgun of 'case foo' vs. 'case .foo'
>>
>> (Note that the last two could be combined, e.g. '?foo' or 'foo?' to=20
>> mark a variable binding and '?' for a wildcard.)
>>
We already have 'with' for contexts.
We already have patterns with 'as':
- except expression "as" identifier ":"
- "import" module "as" identifier
- "with" expression "as" target
So I think this would be quite confusing.
Hi, all
There is a request to run python in a Linux-based embedded resource constrained system with sqlite3 support.
So many features are not required, like posixmodule, signalmodule, hashtable ...
But seems there are some dependencies among the Modules/Parser/Python/Objects/Programs...
Is there a way to tailor CPython 3 to a minimal set with sqlite3 (the less syscalls the better) ?
Is it possible to do that?
Thank you.
Hi,
A few weeks ago, I suggested adding mimetypes.mimesniff on stdlib.
(https://bugs.python.org/issue40841,
https://github.com/python/cpython/pull/20720)
Detecting MIME types well is an important feature and we already have
mimetypes detection library but AFAIK it is not good enough.
Note that some of our stdlib module already use the sniffing algorithm
(e.g imghdr)
The question is how exactly the mime sniffing should be done in terms
of file formats and algorithm. Luckily, WHATWG published the standard
for mime sniffing, and I think we should follow it.
(https://mimesniff.spec.whatwg.org/)
So I created the issue on the bpo and implemented it.
I 'd like to listen to all your opinions :)
--
Software Development Engineer at Kakao corp.
Tel: +82 10-3353-9127
Email: donghee.na92(a)gmail.com | denny.i(a)kakaocorp.com
Linkedin: https://www.linkedin.com/in/dong-hee-na-2b713b49/
Hi all,
I was hoping to get some feedback on a proposed refactoring of the
datetime module that should dramatically improve import performance.
The datetime module is implemented more or less in full both in pure
Python and in C; the way that this is currently achieved
<https://github.com/python/cpython/blob/5a2bac7fe0e7a2b67fd57c7a9176a50feed0…>
is that the pure Python implementation is defined in datetime.py, and
the C implementation is in _datetime, and /after/ the full Python
version is defined, the C version is star-imported and thus any symbols
defined in both versions are taken from the C version; if the C version
is used, any private symbols used only in the pure Python implementation
are manually deleted (see the end of the file
<https://github.com/python/cpython/blob/5a2bac7fe0e7a2b67fd57c7a9176a50feed0…>).
This adds a lot of unnecessary overhead, both to define a bunch of
unused classes and functions and to import modules that are required for
the pure Python implementation but not for the C implementation. In the
issue he created about this <https://bugs.python.org/issue40799>, Victor
Stinner demonstrated that moving the pure Python implementation to its
own module would speed up the import of datetime by a factor of 4.
I think that we should indeed move the pure Python implementation into
its own module, despite the fact that this is almost guaranteed to break
some people either relying on implementation details or doing something
funky with the import system — I don't think it should break anyone
relying on the guaranteed public interface. The issue at hand is that we
have two options available for the refactoring: either move the pure
Python implementation to its own private top-level module (single file)
such as `_pydatetime`, or make `datetime` a folder with an `__init__.py`
and move the pure Python implementation to `datetime._pydatetime` or
something of that nature.
The decimal and zoneinfo modules both have this same issue; the decimal
module uses the first strategy with _pydecimal and decimal, the zoneinfo
module uses a folder with a zoneinfo._zoneinfo submodule. Assuming we go
forward with this, we need to decide which strategy to adopt for datetime.
In favor of using a datetime/ folder, I'd say it's cleaner to put the
pure Python implementation of datetime under the datetime namespace, and
also it gives us more freedom to play with the module's structure in the
future, since we could have lazily-imported sub-components, or we could
implement some logic common to both implementations in Python and import
it from a `datetime._common` module without requiring the C version to
import the entire Python version, similar to the way zoneinfo has the
zoneinfo._common
<https://github.com/python/cpython/blob/master/Lib/zoneinfo/_common.py>
module.
The downside of the folder method is that it complicates the way
datetime is imported — /especially/ if we add additional structure to
the module, or add any logic into the __init__.py. Two single-file
modules side-by-side, one imported by the other doesn't change anything
about the nature of how the datetime module is imported, and is much
less likely to break anything.
Anyone have thoughts or strong preferences here? Anyone have use cases
where one or the other approaches is likely to cause a bunch of undue
hardship? I'd like to avoid moving this more than once.
Best,
Paul
P.S. Victor's PR moving this code to _pydatetime
<https://github.com/python/cpython/pull/20472> is currently done in such
a way that the ability to backport changes from post-refactoring to
pre-refactoring branches is preserved; I have not checked but I /think/
we should be able to do the same thing with the other strategy as well.
Recently, a series of discussions on this mailing list resulted in behavior that did not live up to the standards of the Python Community. The PSF Board of Directors, Python Steering Council, and the PSF Conduct Working Group would like to remind this community that our shared goal is to advance the Python language while simultaneously building a diverse, inclusive, and welcoming Python community. While the community has made progress in recent years, this discussion made it clear to many of us that we still have room to grow.
At the request of the PSF Board, the Steering Council, and members of the community, the PSF Conduct WG met to discuss these recent events and recommend action. As a result, warnings will be given to several members of the Python Community, and the Steering Council will be taking further action.
Especially during passionate discussions like these, we'd like to ask that all Pythonistas focus on being welcoming and respectful, and that we all try to act in the best spirit of the Python Community.
Thank you,
Python Steering Council
PSF Board of Directors
PSF Conduct WG