On Sun, Jun 24, 2018 at 05:24:12PM +0300, Ivan Pozdeev via Python-Dev wrote:
> An expression is intuitively thought to be self-contained i.e. without
> side effects.
> if I write `a=b+1`, I'm not expecting it to do anything except assigning
> `a'.
a = d.pop(1)
a = d.setdefault(key, 0)
chars_wri
On Sun, Jun 24, 2018 at 04:33:38PM +1000, Nick Coghlan wrote:
[...]
> > Making the intentional choice to use an assignment expression is not
> > really "implicit" in any meaningful sense.
>
> No, it's actually implicit: there's an extra "global NAME" or
> "nonlocal NAME" in the equivalent code for
On Sun, Jun 24, 2018 at 09:24:39AM -0700, Guido van Rossum wrote:
> A quick follow-up: PEP 572 currently has two ideas: (a) introduce := for
> inline assignment, (b) when := is used in a comprehension, set the scope
> for the target as if the assignment occurred outside any comprehensions. It
> see
On Mon, Jun 25, 2018 at 11:30:24AM +1200, Greg Ewing wrote:
> Guido van Rossum wrote:
> >Greg seem to be +0 or better for (a)
>
> Actually, I'm closer to -1 on (a) as well. I don't like := as a
> way of getting assignment in an expression. The only thing I would
> give a non-negative rating is som
On Tue, Jun 26, 2018 at 05:42:43AM +1000, Chris Angelico wrote:
> So. sublocal scopes, like in the earliest versions of PEP 572?
>
> The wheel turns round and round, and the same spokes come up.
It isn't as if comprehensions (and generator expressions) run in a
proper separate scope. It is
On Tue, Jun 26, 2018 at 10:54:12AM +1200, Greg Ewing wrote:
> A decision still needs to be made about whether we *want*
> semantics that leak some things but not others.
My sense (or bias, if you prefer) is that the answer to that depends
on how you word the question. If you talk about "leaking"
On Wed, Jun 27, 2018 at 08:30:00AM +0100, Paul Moore wrote:
> On 27 June 2018 at 07:54, Steven D'Aprano wrote:
> > Comprehensions already run partly in the surrounding scope.
[...]
> > Given the code shown:
> >
> > def test():
> > a = 1
> > b =
On Wed, Jun 27, 2018 at 05:52:16PM +1000, Chris Angelico wrote:
> def test():
> a = 1
> b = 2
> vars = {key: locals()[key] for key in locals()}
> return vars
>
> What would your intuition say? Should this be equivalent to dict(locals()) ?
That example is so elegant it makes me wa
On Wed, Jun 27, 2018 at 08:00:20AM -0400, Eric V. Smith wrote:
> On 6/27/2018 7:08 AM, Chris Angelico wrote:
> >It gets funnier with nested loops. Or scarier. I've lost the ability
> >to distinguish those two.
> >
> >def test():
> > spam = 1
> > ham = 2
> > vars = [key1+key2 for key1 in
On Wed, Jun 27, 2018 at 03:41:23PM +0200, Antoine Pitrou wrote:
>
> Why is this discussion talking about comprehensions at all?
> Is there a decent use case for using assignments in comprehensions (as
> opposed to language lawyering or deliberate obfuscation)?
Yes. The *very first* motivating exa
On Wed, Jun 27, 2018 at 05:52:16PM +0300, Ivan Pozdeev via Python-Dev wrote:
> >What this means in practice is that assignments will go to different
> >scopes depending on *where* they are in the comprehension:
> >
> > [ expr for x in iter1 for y in iter2 if cond ...]
> > [ BB fo
On Thu, May 28, 2015 at 05:38:49PM +0100, Paul Moore wrote:
> I suspect "single file executables" just aren't viewed as a desirable
> solution on Unix.
More of an anti-pattern than a pattern. A single file executable means
that when you have a security update, instead of patching one library,
On Thu, May 28, 2015 at 01:20:06PM -0400, Donald Stufft wrote:
> I think it’s an issue for all platforms, even when there is a system Python
> that can be used.
>
> Here’s why:
>
> * Even on Linux systems Python isn’t always a guaranteed thing to be
> installed,
> for instance Debian works ju
On Fri, May 29, 2015 at 07:08:43AM +1000, Nick Coghlan wrote:
> On 29 May 2015 05:25, "Chris Barker" wrote:
> >
> > OK, I'm really confused here:
> >
> > 1) what the heck is so special about go all of a sudden? People have been
> > writing and deploying single file executables built with C and ++,
Hi Françai,
This list is for the development of the Python programming language, not
Fortran, assembly, or discussions about the early history of
programming. Possibly Stackoverflow or one of their related sites might
be a better place to ask. Or you could ask on the python-l...@python.org
mai
On Thu, Jun 18, 2015 at 08:34:14PM +0100, MRAB wrote:
> On 2015-06-18 19:33, Larry Hastings wrote:
> >On 06/18/2015 11:27 AM, Terry Reedy wrote:
> >>Unicode 8.0 was just released. Can we have unicodedata updated to
> >>match in 3.5?
> >>
> >
> >What does this entail? Data changes, code changes, b
On Fri, Jun 19, 2015 at 01:55:07AM +0100, MRAB wrote:
> On 2015-06-19 00:56, Steven D'Aprano wrote:
> >At the very least, there is a change to the casefolding algorithm.
> >Cherokee was classified as unicameral but is now considered bicameral
> >(two cases, like English
On Wed, Jun 24, 2015 at 11:21:54PM +0200, Sven R. Kunze wrote:
> Thanks, Yury, for you quick response.
>
> On 24.06.2015 22:16, Yury Selivanov wrote:
> >Sven, if we don't have 'async def', and instead say that "a function
> >is a *coroutine function* when it has at least one 'await'
> >expressio
On Thu, Jun 25, 2015 at 05:55:53PM +0200, Sven R. Kunze wrote:
>
> On 25.06.2015 04:16, Steven D'Aprano wrote:
> >On Wed, Jun 24, 2015 at 11:21:54PM +0200, Sven R. Kunze wrote:
[...]
> >>What is the difference of a function (no awaits) or an awaitable (> 1
&
aks most loudly of all, but at the
very least you will need to stick to concrete arguments, not analogies.
Are you aware of any other languages which have eliminated the
distinction between regular and concurrent functions? If it has already
been done, that would make a good
On Tue, Jul 14, 2015 at 02:06:14PM +0200, Dima Tisnek wrote:
> https://bugs.python.org/issue21238 introduces detection of
> missing/misspelt mock.assert_xxx() calls on getattr level in Python
> 3.5
>
> Michael and Kushal are of the opinion that "assret" is a common typo
> of "assert" and should be
On Tue, Jul 14, 2015 at 11:09:50PM +1000, Nick Coghlan wrote:
> Dima's right that the main defence against this kind of error is
> actually linters and IDEs, but detecting this particular one at
> runtime is harmless, so there's no particular reason *not* to do it
> when it's possible to construct
On Wed, Jul 15, 2015 at 10:59:50AM +1000, Nick Coghlan wrote:
> Remember folks, "Why wasn't I consulted?!?!?!?" is one of the more
> obnoxious behavours we can inflict on fellow open source maintainers
> giving us the gift of their time and energy.
Nick makes a good point, but it's more complicat
On Fri, Jul 17, 2015 at 04:37:04PM +1000, Nick Coghlan wrote:
> The specific typo that is checked is the only one that changes the
> spelling without also changing the overall length and shape of the
> word.
I don't think your comment above is correct.
assert => aasert aseert azzert essert a
On Mon, Jul 27, 2015 at 10:54:02AM +0200, Lennart Regebro wrote:
> On Mon, Jul 27, 2015 at 10:47 AM, Paul Moore wrote:
> > I'm confused by your position. If it's 7am on the clock behind me,
> > right now, then how (under the model proposed by the PEP) do I find
> > the datetime value where it will
On Wed, Aug 05, 2015 at 06:25:07PM +0300, John Doe wrote:
> To pass by reference or by copy of - that is the question from hamlet.
> ("hamlet" - a community of people smaller than a village python3.4-linux64)
[snip question]
John, you have already posted this same question to the tutor list,
whe
On Sun, Aug 09, 2015 at 06:14:18PM -0700, David Mertz wrote:
[...]
> That said, there *is* one small corner where I believe f-strings add
> something helpful to the language. There is no really concise way to spell:
>
> collections.ChainMap(locals(), globals(), __builtins__.__dict__).
I think
On Sun, Aug 09, 2015 at 06:54:38PM -0700, David Mertz wrote:
> Which brought to mind a certain thought. While I don't like:
>
> f'My name is {name}, my age next year is {age+1}'
>
> I wouldn't have any similar objection to:
>
>'My name is {name}, my age next year is {age+1}'.scope_form
On Mon, Aug 10, 2015 at 09:23:15PM +0200, Guido van Rossum wrote:
[...]
> Anyway, this generalization from print() is why I want arbitrary
> expressions. Wouldn't it be silly if we introduced print() today and said
> "we don't really like to encourage printing complicated expressions, but
> maybe
On Tue, Aug 11, 2015 at 09:51:56PM +1000, Chris Angelico wrote:
> On Tue, Aug 11, 2015 at 5:08 PM, Cameron Simpson wrote:
> > On 11Aug2015 18:07, Greg Ewing wrote:
> >>
> >> Cameron Simpson wrote:
> >>>
> >>> To illustrate, there's a consumer rights TV snow here with a segment
> >>> called "F.U.
On Sun, Aug 16, 2015 at 02:17:09PM +0100, Paul Moore wrote:
> Sorry I'm late to this, but I would very much like to see wheel
> installed with ensurepip on at least Windows.
I seem to be missing something critical to this entire discussion.
As I understand it, ensurepip is *only* intended to boo
On Sun, Aug 16, 2015 at 10:52:00AM -0400, Donald Stufft wrote:
> > So what is the benefit of including wheel with ensurepip?
>
> pip has an optional dependency on wheel, if you install that optional
> dependency than you’ll get the implicit wheel cache enabled by default
> which can drastically
On Tue, Oct 13, 2015 at 11:26:09AM -0400, Random832 wrote:
> "R. David Murray" writes:
>
> > On Tue, 13 Oct 2015 14:59:56 +0300, Stefan Mihaila
> > wrote:
> >> Maybe it's just python2 habits, but I assume I'm not the only one
> >> carelessly thinking that "iterating over an input a second time w
On Tue, Oct 13, 2015 at 04:37:43PM -0700, Raymond Hettinger wrote:
> We could have (and still could) make the choice to always coerce to
> decimal (every float is exactly representable in decimal). Further,
> any decimal float or binary float could be losslessly coerced to a
> Fraction, but th
Hi,
As extensively discussed on Python-Ideas, the secrets module and PEP 506
is (I hope) ready for pronouncement.
https://www.python.org/dev/peps/pep-0506/
There is code and tests here:
https://bitbucket.org/sdaprano/secrets
or you can run
hg clone https://sdapr...@bitbucket.org/sdaprano/se
On Fri, Oct 16, 2015 at 08:57:24AM +0200, Victor Stinner wrote:
> Hi,
>
> I like the PEP. IMHO it's a better solution than using a CPRNG for
> random by default.
>
> I suggest to raise an error if token_bytes(n) if calls with n < 16
> bytes (128 bits). Well, I'm not sure that 16 is the good compr
On Fri, Oct 16, 2015 at 06:35:14PM +0300, Serhiy Storchaka wrote:
> I suggest to add only randrange(). randint() is historical artefact, we
> shouldn't repeat this mistake in new module. The secrets module is not
> good way to generate dice rolls. In most other cases you need to
> generate inte
On Sat, Oct 17, 2015 at 03:26:46AM +1100, Steven D'Aprano wrote:
> On Fri, Oct 16, 2015 at 06:35:14PM +0300, Serhiy Storchaka wrote:
>
> > I suggest to add only randrange(). randint() is historical artefact, we
> > shouldn't repeat this mistake in new module. The sec
On Sat, Oct 17, 2015 at 03:45:19PM -0600, Eric Snow wrote:
> In a recent tracker issue about OrderedDict [1] we've had some
> discussion about the use of type(od) as a replacement for
> od.__class__.
[...]
> The more general question of when we use type(obj) vs. obj.__class__
> applies to both th
On Sun, Oct 18, 2015 at 05:35:14PM -0700, David Mertz wrote:
> In any case, redefining a method in a certain situation feels a lot less
> magic to me than redefining .__class__
That surprises me greatly. As published in the Python Cookbook[1], there
is a one-to-one correspondence between the met
On Mon, Oct 19, 2015 at 11:41:44AM +1100, Chris Angelico wrote:
> What does this provide that collections.deque(maxlen=size_max)
> doesn't? I'm a little lost.
The Ringbuffer recipe predates deque by quite a few years. These days I
would consider it only useful in a pedagogical context, giving a
On Wed, Oct 21, 2015 at 10:10:56AM -0700, Ethan Furman wrote:
> On 10/21/2015 08:53 AM, Random832 wrote:
>
> >If a pure python class can cause a reference leak, doesn't that mean it
> >is only a symptom rather than the real cause? Or is it that the use of
> >@object.__new__ is considered "too clev
CC'ing Python-Ideas. Follow-ups to Python-Ideas please.
On Thu, Oct 29, 2015 at 09:22:15PM -0400, Terry Reedy wrote:
> Leaving IDLE aside, the reason '' is added to sys.path is so that people
> can import their own modules. This is very useful. Shadowing is the
> result of putting it at the f
On Wed, Nov 04, 2015 at 09:50:33AM +0100, Victor Stinner wrote:
> Hi,
>
> I'm writing a new "FAT Python" project to try to implement optimizations in
> CPython (inlining, constant folding, move invariants out of loops, etc.)
> using a "static" optimizer (not a JIT). For the background, see the thr
On Sat, Nov 14, 2015 at 09:19:37PM +0200, Serhiy Storchaka wrote:
> If the support of UTF-16 and UTF-32 is planned, I'll take this to
> attention during refactoring. But in many places besides the tokenizer
> the ASCII compatible encoding of source files is expected.
Perhaps another way of look
On Thu, Dec 03, 2015 at 09:25:53AM -0800, Andrew Barnert via Python-Dev wrote:
> > On Dec 3, 2015, at 08:15, MRAB wrote:
> >
> >>> On 2015-12-03 15:09, Random832 wrote:
> >>> On 2015-12-03, Laura Creighton wrote:
> >>> Who came up with the word 'display' and what does it have going for
> >>> it
On Thu, Dec 17, 2015 at 12:53:13PM +0100, Victor Stinner quoted:
> 2015-12-17 11:54 GMT+01:00 Franklin? Lee :
> > Each function keeps an indirect, automagically updated
> > reference to the current value of the names they use,
Isn't that a description of globals()? If you want to look up a name
On Thu, Dec 17, 2015 at 09:30:24AM -0800, Andrew Barnert via Python-Dev wrote:
> On Dec 17, 2015, at 07:38, Franklin? Lee
> wrote:
> >
> > The nested dictionaries are only for nested scopes (and inner
> > functions don't create nested scopes). Nested scopes will already
> > require multiple look
On Wed, Jan 27, 2016 at 01:25:27PM -0500, Yury Selivanov wrote:
> Hi,
>
>
> tl;dr The summary is that I have a patch that improves CPython
> performance up to 5-10% on macro benchmarks. Benchmarks results on
> Macbook Pro/Mac OS X, desktop CPU/Linux, server CPU/Linux are available
> at [1].
On Sun, Jan 31, 2016 at 08:23:00PM +, Brett Cannon wrote:
> So freezing the stdlib helps on UNIX and not on OS X (if my old testing is
> still accurate). I guess the next question is what it does on Windows and
> if we would want to ever consider freezing the stdlib as part of the build
> proce
On Thu, Feb 04, 2016 at 07:58:30PM -0500, Terry Reedy wrote:
> >>For folks that *do* know how to use the terminal:
> >>
> >>$ python3 -m inspect --details inspect
> >>Target: inspect
> >>Origin: /usr/lib64/python3.4/inspect.py
> >>Cached: /usr/lib64/python3.4/__pycache__/inspect.cpython-34.pyc
> >
On Mon, Feb 08, 2016 at 05:43:25PM -0500, Yury Selivanov wrote:
>
>
> On 2016-02-08 5:19 PM, Terry Reedy wrote:
> >On 2/8/2016 4:51 PM, Victor Stinner wrote:
> >>2016-02-08 22:28 GMT+01:00 Alexander Walters :
> >>>What incantation do you need to do to make that behavior apparent?
> >>
> >>I didn'
On Wed, Feb 10, 2016 at 12:41:08PM +1100, Chris Angelico wrote:
> On Wed, Feb 10, 2016 at 12:37 PM, Steve Dower wrote:
> > I really don't like the idea of not being able to use bytes in cross
> > platform code. Unless it's become feasible to use Unicode for lossless
> > filenames on Linux - last I
On Wed, Feb 10, 2016 at 10:59:18PM +0100, Luca Sangiacomo wrote:
> Hi,
> I hope the question is not too silly, but why I would like to understand
> the advantages of having both re.match() and re.search(). Wouldn't be
> more clear to have just one function with one additional parameters like
> t
On Wed, Feb 10, 2016 at 10:53:09PM +, Paul Moore wrote:
> On 10 February 2016 at 22:20, Georg Brandl wrote:
> > This came up in python-ideas, and has met mostly positive comments,
> > although the exact syntax rules are up for discussion.
>
> +1 on the PEP. Is there any value in allowing unde
On Wed, Feb 10, 2016 at 11:20:38PM +0100, Georg Brandl wrote:
> This came up in python-ideas, and has met mostly positive comments,
> although the exact syntax rules are up for discussion.
Nicely done. But I would change the restrictions to a simpler version.
Instead of five rules to learn:
> T
On Wed, Feb 10, 2016 at 03:45:48PM -0800, Andrew Barnert via Python-Dev wrote:
> On Feb 10, 2016, at 14:20, Georg Brandl wrote:
>
> First, general questions: should the PEP mention the Decimal constructor?
> What about int and float (I'd assume int(s) continues to work as always,
> while int(s,
On Thu, Feb 11, 2016 at 01:08:41PM +1300, Greg Ewing wrote:
> The Mersenne Twister is no longer regarded as quite state-of-the art
> because it can get into states that produce long sequences that are
> not very random.
>
> There is a variation on MT called WELL that has better properties
> in thi
On Wed, Feb 10, 2016 at 08:41:27PM -0800, Andrew Barnert wrote:
> And honestly, are you really claiming that in your opinion, "123_456_"
> is worse than all of their other examples, like "1_23__4"?
Yes I am, because 123_456_ looks like you've forgotten to finish typing
the last group of digits,
On Thu, Feb 11, 2016 at 08:07:56PM +1000, Nick Coghlan wrote:
> Given that str.format supports a thousands separator:
>
> >>> "{:,d}".format(1)
> '100,000,000'
>
> it might be reasonable to permit "_" in place of "," in the format specifier.
+1
> However, I'm not sure when you'd use i
On Thu, Feb 11, 2016 at 08:50:09PM +0200, Serhiy Storchaka wrote:
> I have strong preference for more strict and simpler rule, used by most
> other languages -- "only between two digits". Main arguments:
>
> 1. Simple rule is easier to understand, remember and recognize. I care
> not about the
On Thu, Feb 11, 2016 at 06:03:34PM +, Brett Cannon wrote:
> On Thu, 11 Feb 2016 at 02:13 Steven D'Aprano wrote:
>
> > On Wed, Feb 10, 2016 at 08:41:27PM -0800, Andrew Barnert wrote:
> >
> > > And honestly, are you really claiming that in your opinion, "
On Sat, Feb 13, 2016 at 09:48:49AM +0100, Georg Brandl wrote:
> Hi all,
>
> after talking to Guido and Serhiy we present the next revision
> of this PEP. It is a compromise that we are all happy with,
> and a relatively restricted rule that makes additions to PEP 8
> basically unnecessary.
>
> I
On Tue, Feb 16, 2016 at 11:56:55AM -0800, Glenn Linderman wrote:
> On 2/16/2016 1:48 AM, Christoph Groth wrote:
> >Hello,
> >
> >Recent Python versions randomize the hashes of str, bytes and datetime
> >objects. I suppose that the choice of these three types is the result
> >of a compromise. Ha
I haven't really been following this discussion, but a couple of
comments...
On Tue, Apr 05, 2016 at 11:47:32PM +, Brett Cannon wrote:
> http://www.snarky.ca/why-pathlib-path-doesn-t-inherit-from-str
Nice write-up, thanks.
[...]
> To me it seems to basically be a question of whether peopl
On Wed, Apr 06, 2016 at 10:02:30AM +1000, Chris Angelico wrote:
> My personal view on the text/bytes debate is that a path is
> fundamentally a human concept, and consists therefore of text. The
> fact that some file systems store (at the low level) bytes and some
> store (I think) UTF-16 code uni
On Tue, Apr 05, 2016 at 11:53:05PM -0700, Nathaniel Smith wrote:
> This makes me twitch slightly, because NumPy has had a whole set of
> problems due to the ancient and minimally-considered decision to
> assume a bunch of ad hoc non-namespaced method names fulfilled some
> protocol -- like all .su
On Wed, Apr 06, 2016 at 11:30:32AM +0200, Petr Viktorin wrote:
> Python was in a similar situation with the .next method on iterators,
> which changed to __next__ in Python 3. PEP 3114 (which explains this
> change) says:
>
> > Code that nowhere contains an explicit call to a next method can
> >
almost happy to approve it in the current
> state. My only quibble is with some naming -- I'm not sure that a
> super-generic name like 'equal' is better than the original
> ('compare_digest'),
Changed.
> and I would have picked a different name for token_
On Sun, Apr 10, 2016 at 08:12:30PM -0400, Jonathan Goble wrote:
> On Sun, Apr 10, 2016 at 7:02 PM, Oscar Benjamin
> wrote:
> > I haven't looked at your sandbox but for a different approach try this one:
> >
> > L = [None]
> > L.extend(iter(L))
> >
> > On my Linux machine that doesn't just cras
On Sun, Apr 10, 2016 at 11:43:08AM -0700, Guido van Rossum wrote:
> Hi Steven,
>
> No probIem with the delay -- it's still before 3.6.0. I do think it's
> just about a record gap in the PEP review process. :-)
>
> I will approve the PEP as soon as you've update
I haven't been following this thread in detail, so perhaps I have
missed something, but I have a question...
On Tue, Apr 12, 2016 at 02:05:06PM +0200, Victor Stinner wrote:
> You don't understand that even if the visible "Python scope", "Python
> namespace", or call it as you want (the code tha
Now that PEP 506 has been approved, I've checked in the secrets module,
but an implementation question has come up regarding compare_digest.
Currently, the module tries to import hmac.compare_digest, and if that
fails, then it falls back to a Python version. But since compare_digest
has been av
On Fri, Apr 15, 2016 at 10:26:31AM +0200, Victor Stinner wrote:
> It's easy to implement this function (in the native language of your Python
> implemenation), it's short. I'm not sure that a Python version is really
> safe.
>
> The secrets module is for Python 3.6, in this version the hmac alread
On Thu, Apr 21, 2016 at 04:00:29AM -0700, Burkhard Meier wrote:
> Well,
>
> Just a thought.
I'm afraid I have no idea what you are referring to.
--
Steve
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/pytho
On Tue, Apr 26, 2016 at 08:45:20AM -0400, Franklin? Lee wrote:
> On Apr 26, 2016 4:02 AM, "Paul Moore" wrote:
> >
> > On 25 April 2016 at 23:55, Franklin? Lee
> wrote:
> > > FWIW, Gmail's policies require:
> > [...]
> > > That link is currently the only obvious way to unsubscribe.
> >
> > I'm not
On Sun, May 01, 2016 at 08:08:22AM -0500, Ryan Gonzalez wrote:
> Well, I put this in Google Translate...and got this:
>
> The disk clatters
> the Spontie giggles
> ~
> hopefully
> alliance insures ...
>
> Not sure if this a useless post or Translate just being weird. Leaning
> towards the latter.
On Thu, May 05, 2016 at 05:23:02PM +0100, MRAB wrote:
> On 2016-05-05 16:26, Ryan Gonzalez wrote:
> >On Thu, May 5, 2016 at 3:24 AM, Deepak Srivastava
[ ... about three or four pages of quoting ... ]
> >Questions like this are better suited for python-list. [...]
> It looks to me that it's the u
On Sat, May 07, 2016 at 04:06:51PM -0700, Ethan Furman wrote:
> I just reviewed an issue on the tracker, and found that many, if not
> all, of my comments made at the time I completely disagree with (both
> now, and before -- I'm going to claim sleep deprivation).
>
> Obviously I should post a n
On Thu, May 12, 2016 at 07:22:25PM +0200, Sjoerd Job Postmus wrote:
> The whole point of adding `os.fspath` is to make it easier to use Path
> objects. This is in an effort to gain greater adoption of pathlib in
> libraries. Now, this is an excellent idea.
>
> However, if it were to reject bytes,
On Thu, May 12, 2016 at 08:53:12PM +, Brett Cannon wrote:
> Second draft that takes Guido's comments into consideration. The biggest
> change is os.fspath() now returns whatever path.__fspath__() returns
> instead of restricting it to only str.
Counter suggestion:
- __fspath__() method may r
On Fri, May 13, 2016 at 03:43:29PM +, Brett Cannon wrote:
> On Fri, 13 May 2016 at 04:00 Steven D'Aprano wrote:
[...]
> > - but os.fspath() will only return str;
> > - and os.fspathb() will only return bytes;
> I prefer what's in the PEP. I get where you coming
On Fri, May 27, 2016 at 04:01:11PM -0700, Guido van Rossum wrote:
> Also -- the most important thing. :-) What to call these things? We're
> pretty much settled on the semantics and how to create them (A =
> NewType('A', int)) but what should we call types like A when we're
> talking about them? "N
On Fri, May 27, 2016 at 09:26:29PM -0700, Guido van Rossum wrote:
> We discussed this over dinner at PyCon, some ideas we came up with:
>
> - Dependent types, harking back to a similar concept in Ada
> (https://en.wikibooks.org/wiki/Ada_Programming/Type_System#Derived_types)
> which in that langu
On Thu, May 26, 2016 at 10:19:05AM +, Artyom Skrobov wrote:
[...]
> The motivation for this patch was to enable a memory footprint
> optimization, discussed at http://bugs.python.org/issue26415 My
> proposed optimization reduces the memory footprint by up to 30% on the
> standard benchmarks,
ass in
the MRO of the instance doing the calling", and in all cases, the
"real-calling instance" is c, and the "real calling class" is the class
of c, namely C.
Extended discussion of this should go to python-list, but I think I have
the basics right.
--
Steven
__
email), if you cannot support NANs on VAXen, you should modify float to
raise a ValueError exception. Pure Python code like float('nan') should
never dump core, it should raise:
ValueError: could not convert string to float: 'nan'
--
Steven
_
On Tue, Nov 05, 2013 at 08:38:09PM -0800, Ethan Furman wrote:
> http://bugs.python.org/issue19332
Duplicate of this: http://bugs.python.org/issue6017
The conclusion on that also was that it is not worth guarding against
such an unusual circumstance.
--
Ste
name is used, why keep a reference to the type
instead of just type.__name__?
> AttributeError.args would be (type, attr) instead of (message,).
> ImportError was also modified to add a new "name "attribute".
I don't like changing the signature of AttributeError. I
create an independent Python
compiler, designed with sandboxing in mind from the beginning?
--
Steven
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/p
e them). Exception repr is explicitly *not* part of
> any backward-compatibility guarantees in Python.
Do you have a link for that explicit non-guarantee from the docs please?
--
Steven
___
Python-Dev mailing list
Python-Dev@python.org
https
oduction.
--
Steven
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
o do if printing the exception raises. If
str(exception.message) raises, suppressing the message seems like a
perfectly reasonable approach to me.
--
Steven
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-
I don't
think there's any good solution to the general problem, and I'm not
convinced that treating Unicode strings as a special case is justified.
It's been at least four, and possibly six (back to 2.2) point releases
with this behaviour, and until now apparently nobody h
quot; menu, where you can
specify the codec used for text. That's hard in Python, since you
can't retrieve a list of known codecs.
--
Steven
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
rm("base64")
Yes, that's quite nice. Although it need not be a method, a built-in
function works for me too:
# either of these:
transform(transform(b, "zlib"), "base64")
encode(encode(b, "zlib"), "base64"
up, but I assume that was some benefit. (I know,
premature optimization and all that...)
--
Steven
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
trated by the number of times people propose removing -O
(apparently) just because they personally don't use it. I personally
have never got any benefit from the tarfile or multiprocessing modules,
but I don't ask for them to be removed :-)
--
Steven
_
urage good use of
assertions in Python.
--
Steven
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
On Sun, Nov 17, 2013 at 11:00:50AM +0100, Antoine Pitrou wrote:
> On Sun, 17 Nov 2013 18:04:43 +1100
> Steven D'Aprano wrote:
> > On Sat, Nov 16, 2013 at 04:46:00PM +0100, Antoine Pitrou wrote:
> >
> > > I agree that conflating the two doesn't help the discus
201 - 300 of 1900 matches
Mail list logo
