Gallian Colombeau wrote on 8/27/18 06:49:
As I understand, for a package to allow being extended in this way, it
must be a namespace package and not contain a marker file. As a matter
of fact, no sub-package until the top level package can have a marker file:
No, that's not true.
However, wh
Guido van Rossum wrote on 7/6/18 08:31:
Thanks for an interesting discussion. I would also urge people to limit the
use of such sentinels for cases where it is *really* important to
distinguish between, say, f(None) and f(). In most cases using def
f(arg=None) is fine, and often it is even a virt
On May 15, 2018, at 14:03, Rob Speer wrote:
> Consider a mini-Web-server written in Python (there are, of course, lots of
> these) that needs to serve static files. Users of the Web server will expect
> to be able to place these static files somewhere relative to the directory
> their code is
Yuval Greenfield wrote:
I often need to reference a script's current directory. I end up writing:
import os
SRC_DIR = os.path.dirname(__file__)
The question I have is, why do you want to reference the script's
current directory?
If the answer is to access other files in that directory, the
Antoine Pitrou wrote:
> Moore's Law doesn't really apply to semiconductors anymore either, and
> transistor size scaling is increasingly looking like it's reaching its
> end.
You forget about the quantum computing AI blockchain in the cloud.
OTOH, I still haven't perfected my clone army yet.
-Bar
Just to add another perspective, I find many "performance" problems in
the real world can often be attributed to factors other than the raw
speed of the CPython interpreter. Yes, I'd love it if the interpreter
were faster, but in my experience a lot of other things dominate. At
least they do prov
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.
That's what I do for all my personal code. Yes, it means the test
directories are shipped with the sdist, but re
Steve Barnes wrote:
> Currently invoking `python -c "some;separated;set of commands;"` will,
> if you need to use any library functions, require one or more import
> somelib; sections in the execution string. This results in rather
> complex "one liners".
>
> On the other hand `python -m someli
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 wa
Serhiy Storchaka wrote:
> In 3.7 I have removed an old-deprecated plistlib.Dict. [1] Actually it
> already was deprecated when the plistlib module was added to the regular
> stdlib in Python 2.6.
>
> Raymond noticed that that capability seemed nice to have.
So nice in fact that I'm sure I've reim
David Mertz wrote:
> https://www.python.org/dev/peps/pep-0416/
PEP 351 (also rejected) is related to this.
-Barry
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python
On Nov 29, 2017, at 12:40, David Mertz wrote:
> I think some syntax could be possible to only "catch" some exceptions and let
> others propagate. Maybe:
>
>val = name.strip()[4:].upper() except (AttributeError, KeyError): -1
>
> I don't really like throwing a colon in an expression though
Chris Barker wrote:
> but whatever -- multiple line pragmas are fine, too -- I'm hoping putting
> this much crap in your code will be rare :-)
For sure. It's not uncommon for you to need two pragmas, e.g. flake8
and coverage, but it's pretty rare to need those *plus* mypy. It does
happen though
Steven D'Aprano wrote:
>
> Brett may have meant
>
> https://mail.python.org/mailman/listinfo/code-quality
That definitely makes more sense. :)
-Barry
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/pyt
Gregory P. Smith wrote:
> fwiw, we're going to need the tool name in any pragma anyways so the
> existing thing that should be common is:
>
> # tool-name: meaningfultoken
>
> It seems like the only convention that makes sense to me.
One of the things that bother me about end-line comments is tha
Brett Cannon wrote:
> And possibly the easiest way to reach them is on the pyqa-dev mailing list.
What's that? I can't find it on python.org, Gmane, or the Googles.
-Barry
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org
I love many of the ancillary tools that help improve the quality of my
Python code, including flake8, coverage, and mypy. Each of these
usually produces some great diagnostics, but none of them are perfect,
so they also produce false positives that have to be suppressed.
Each of these tools suppo
Guido van Rossum wrote:
> This is beginning to sound like the most attractive solution. We could
> possibly do away with typing_extensions. Are there precedents of how to
> bundle a module in this way? Or is it going to be another special case like
> pip?
With my downstream consumer hat on, *if*
Nick Timkovich wrote:
> Alternative history question: if it was just 1.6
Guido's time machine strikes again. There was both a Python 1.6 and a
1.6.1.
https://www.python.org/download/releases/1.6/
https://www.python.org/download/releases/1.6.1/
The "Contractual Obligation" releases. (And anoth
M.-A. Lemburg wrote:
> The first ever major backwards incompatibility release switch we
> had in Python after the great renaming of the C APIs between
> Python 1.1 and 1.2 (which was only visible to C extensions and
> relatively easy to fix using a compatibility header file),
> was the transition
Nick Coghlan wrote:
> The open question will be what we call the release after that (in late
> 2022), with the main leading contenders being "4.0" (on the grounds
> that so many changes will have accumulated since 2008's 3.0 release by
> then that it makes sense to call them different major versio
We’ve made a small change to the PEP process which may affect readers of
python-list and python-ideas, so I’d like to inform you of it. This change was
made to PEP 1 and PEP 12.
PEPs must have a Post-History header which records the dates at which the PEP
is posted to mailing lists, in order t
Neil Schemenauer wrote:
> Introduce a lazy module import process that modules can opt-in to.
> The opt-in would either be with a __future__ statement or the
> compiler would statically analyze the module and determine if it is
> safe. E.g. if the module has no module level statements besides
> im
Jim J. Jewett wrote:
> I know I'm not the only one who is confused by at least some of the
> alternative terminology choices. I suspect I'm not the only one who
> sometimes missed part of the argument because I was distracted
> figuring out what the objects were, and forgot to verify what was
> be
Yury Selivanov wrote:
> This is a new PEP to implement Execution Contexts in Python.
It dawns on me that I might be able to use ECs to do a better job of
implementing flufl.i18n's translation contexts. I think this is another
example of what the PEP's abstract describes as "Context managers like
On Mar 08, 2017, at 05:49 PM, Eric V. Smith wrote:
>If we really want to make defaultdict feel more "builtin" (and I don't see
>any reason to do so), I'd suggest adding a factory function:
>
>dict.defaultdict(int)
>
>Similar in spirit to dict.fromkeys(), except of course returning a
>defauldict, n
On Mar 02, 2017, at 06:37 PM, Brett Cannon wrote:
>So to me, there's actually two things being discussed. Do we need another
>sentinel to handle the "None is valid" case, and do we want syntax to more
>clearly delineate optional arguments?
No, and no (IMHO).
-Barry
pgpULmSfZJDcd.pgp
Descriptio
On Mar 02, 2017, at 10:03 AM, Serhiy Storchaka wrote:
>Currently you need to use the sentinel idiom for implementing this:
>
>_sentinel = object()
>def get(store, key, default=_sentinel):
> if store.exists(key):
> return store.retrieve(key)
> if default is _sentinel:
> rais
On Mar 01, 2017, at 03:04 PM, Mathieu BEAL wrote:
>I was wondering why the PEP coding style (
>https://www.python.org/dev/peps/pep-0008/) is not natively included in python
>grammar ?
Well, the simple answer is that the grammar predates PEP 8 (or any PEP) by
many years.
Cheers,
-Barry
pgpGjysE
On Feb 16, 2017, at 03:20 PM, M.-A. Lemburg wrote:
>I know some people will disagree, but IMO using "assert" is the wrong
>approach in such situations - it's meant for development and testing
>only, not as short-cut to avoid having to write a proper error
>handler :-)
I use assertions for "things
On Feb 14, 2017, at 12:48 PM, Steven D'Aprano wrote:
>On Fri, Feb 10, 2017 at 09:05:49PM -0500, Terry Reedy wrote:
>> Saving about 10 keystrokes is close to trivial.
>
>The same argument can be made for @decorator syntax.
>
>And, if I understand correctly, the same argument *was* made against
>d
On Jan 13, 2017, at 11:20 AM, Greg Ewing wrote:
>Criticisms Frequently Levelled Against Python
Missteps Or Nonfeatures Guido Obviously Ordered, Saddling Everyone
(Yes, okay, I know python's aren't venomous, but never let facts get in the
way of a good, bad, tortured, or mentally mushed Friday-ev
On Jan 06, 2017, at 11:08 PM, Steve Dower wrote:
>Passing universal_newlines will use whatever locale.getdefaultencoding()
There is no locale.getdefaultencoding(); I think you mean
locale.getpreferredencoding(False). (See the "Changed in version 3.3" note in
$17.5.1.1 of the stdlib docs.)
>univ
On Jan 06, 2017, at 11:33 PM, Victor Stinner wrote:
>Barry: About chroot, why do you get a C locale? Is it because no
>locale is explicitly configured? Or because no locale is installed in
>the chroot?
For some reason it's not configured:
% schroot -u root -c sid-amd64
(sid-amd64)# locale
LANG=
On Jan 06, 2017, at 07:22 AM, Stephan Houben wrote:
>Because I have the impression that nowadays all Linux distributions are UTF-8
>by default and you have to show some bloody-mindedness to end up with a POSIX
>locale.
It can still happen in some corner cases, even on Debian and Ubuntu where
C.UT
On Jan 05, 2017, at 05:50 PM, Victor Stinner wrote:
>I guess that all users and most developers are more in the "UNIX mode"
>camp. *If* we want to change the default, I suggest to use the "UNIX
>mode" by default.
FWIW, it seems to be a general and widespread recommendation to always pass
universa
On Oct 28, 2016, at 03:24 PM, Gustavo Carneiro wrote:
>The main drawback of this type of approach is that code checking tools will
>hardly ever support checking expressions inside the string like that.
>Also, you don't get proper syntax highlighting, code completion, etc.
>
>You can do anything yo
On Oct 27, 2016, at 07:37 PM, Nick Badger wrote:
>The problem with doing that is that it's ambiguous. There's no way of
>telling which attribute is allowed to coalesce.
You could of course support exactly the same syntax being proposed as a
language change, e.g.
from operator import attrgett
On Oct 27, 2016, at 02:50 PM, James Pic wrote:
>Now I'm fully aware of distribution specific packaging solutions like
>dh-virtualenv shared by Spotify but here's my mental problem: I love to
>learn and to hack. I'm always trying now distributions and I rarely run the
>one that's in production in m
On Oct 27, 2016, at 06:27 PM, Joonas Liik wrote:
>perhaps just having a utility function can get us some of the way there..
>
>#may error
>r = a.b.x.z
>
># will default to None
>r = a?.b?.x?.z
>r = get_null_aware(a, "b.x.z") # long but no new syntax, can be
>implemented today.
You could probably
On Oct 15, 2016, at 04:10 PM, Nick Coghlan wrote:
>Having been previously somewhere between -1 and -0, I've been doing a
>lot more data mining and analysis work lately, which has been enough
>to shift me to at least +0 and potentially even higher when it comes
>to the utility of adding these opera
On Sep 12, 2016, at 03:12 PM, Senthil Kumaran wrote:
>I see PEP as the design document and docs as user-friendly documentation. It
>helps to keep both of them up to date and in sync. If an "Accepted" PEP is
>not updated, then folks landing on it will feel misguided or confused if the
>read the d
On Aug 30, 2016, at 02:16 PM, Guido van Rossum wrote:
>Given that something like this gets proposed from time to time, I
>wonder if it would make sense to actually write up (1) and (2) as a
>PEP that is immediately marked rejected. The PEP should make it clear
>*why* it is rejected. This would be
On Aug 14, 2016, at 02:01 PM, Chris Angelico wrote:
>The biggest problem I'm seeing is with digests. Can that feature be
>flagged off as "DO NOT USE THIS UNLESS YOU KNOW WHAT YOU ARE ASKING
>FOR"? So many people seem to select digest mode, then get extremely
>confused by it.
Yes, we can turn off
44 matches
Mail list logo
