On Thu, Aug 11, 2016 at 02:09:00PM +1000, Chris Angelico wrote:
> On Thu, Aug 11, 2016 at 1:14 PM, Steven D'Aprano <st...@pearwood.info> wrote:
> > The way I have done auto-detection based on BOMs is you start by reading
> > four bytes from the file in binary mode. (If ther
On Mon, Aug 15, 2016 at 01:05:47AM +0200, Xavier Combelle wrote:
> I have stumbled upon several time with the following problem.
> I delete a module and the .pyc stay around. and by "magic", python still
> use the .pyc
Upgrade to Python 3.2 or better, and the problem will go away.
In 3.2 and
ways a guess :-) Maybe I just happen to have a
Latin1 file that starts with "", or a Mac Roman file that starts with
"Ôªø". Either case will be wrongly detected as UTF-8. That's the risk
you take when using a heuristic.
And if you don't want to use that heuristic, then you
On Mon, Feb 06, 2017 at 11:29:17AM +0100, M.-A. Lemburg wrote:
> I'm not sure how useful this would be in the stdlib,
> since it's very much tied to whatever float type Python
> happens to use on a platform.
With the possible exception of µPy, are there any Python implementations
which don't
On Mon, Jan 23, 2017 at 12:49:19AM -0200, Soni L. wrote:
[...]
> You seem to be thinking of "immutable object builder". Not "the builder
> itself is immutable and operations on it create new builders".
Why would you make a builder class immutable?
That's not a rhetorical question -- I'm
On Mon, Jan 23, 2017 at 09:18:54PM +, João Matos wrote:
> Why should I repeat global if I can use the line separation character \
> (like I mentioned on my 1st email) or parentheses as I suggested?
That's the wrong question.
The right question is, why should the Python language be made
On Sat, Jan 28, 2017 at 03:16:27PM +0100, zmo via Python-ideas wrote:
> Hi list o/
>
> This idea sounds fun, so as a thought experiment why not imagine one
> way of integrating it in what I believe would be pythonic enough.
This idea is sometimes called "the Collection Pipeline" design pattern,
On Fri, Feb 17, 2017 at 04:02:01PM -0600, Abe Dillon wrote:
> I'm fairly novice, so I could be way off base here, but it seems like the
> inevitable conclusion to this problem is something like JIT compilation,
> right? (admittedly, I know very little about JIT compilation)
No.
JIT compilation
On Fri, Feb 17, 2017 at 06:31:19PM +0100, Mikhail V wrote:
> I have said I need the index, probably you've misread my last comment.
> Further more I explained why I think iteration over index should be the
> preferred way, it help with readability a lot.
Your concept of readability is clearly
On Thu, Feb 23, 2017 at 01:37:15PM +, Henk-Jaap Wagenaar wrote:
[...]
> Other solutions to another case of this 'problem' are discussed has been
> discussed on StackOverflow (
> http://stackoverflow.com/questions/6981717/pythonic-way-to-combine-for-loop-and-if-statement)
> where it is
On Fri, Feb 10, 2017 at 06:17:54PM +0200, Markus Meskanen wrote:
> Well yes, but I think you're a bit too fast on labeling it a mistake to use
> monkey patching...
More importantly, I think we're being a bit too quick to label this
technique "monkey-patching" at all. Monkey-patching (or MP for
On Fri, Feb 10, 2017 at 12:11:46PM -0600, Steve Dower wrote:
> When you apply the "what if everyone did this" rule, it looks like a
> bad idea (or alternatively, what if two people who weren't expecting
> anyone else to do this did it).
When you apply that rule, Python generally fails badly.
On Sat, Feb 11, 2017 at 06:33:39PM +1300, Greg Ewing wrote:
> Chris Angelico wrote:
> >Which is why these proposals always seem to gravitate to "anything you
> >can assign to",
>
> There might be some parsing difficulties with that, e.g.
>
>def foo(x)[5](y, z):
> ...
>
> That should
On Fri, Feb 10, 2017 at 09:05:49PM -0500, Terry Reedy wrote:
> >def foo(self):
> >pass
> >Foo.foo = foo
> >
> >Becomes:
> >
> >def Foo.foo(self):
> >pass
>
> Saving about 10 keystrokes is close to trivial.
The same argument can be made for @decorator syntax.
And, if
On Sun, Feb 12, 2017 at 10:29:10PM +0100, Nick Coghlan wrote:
[...]
> Method injection is most attractive to me as a potential alternative
> to mixin classes that has fewer runtime side effects by moving more of
> the work to class definition time.
>
> More philosophically though, it offends my
On Mon, Feb 13, 2017 at 06:14:34PM -0800, David Mertz wrote:
> On Mon, Feb 13, 2017 at 5:48 PM, Steven D'Aprano <st...@pearwood.info>
> wrote:
>
> > # the clean proposed way:
> > def instance.method(self): # or MyClass.method
> > ...
> >
> > B
On Tue, Feb 07, 2017 at 12:05:49AM -0600, C Anthony Risinger wrote:
> How do I redistribute and successfully install Python, dependencies, and an
> application with the least possible steps for the end user? For any
> platform or persona?
For Linux, Unix and Mac, where you can generally expect
On Tue, Feb 14, 2017 at 03:51:05PM +, Barry Scott wrote:
> A common pattern I use is to have logging calls for debug and information
> with my applications.
> The logging calls can be separately enabled and disabled.
[...]
> What would be nice is to be able to avoid evaluation the tuple of
Hello George, and welcome!
On Mon, Feb 13, 2017 at 01:23:22PM +0100, George Fischhof wrote:
> Hi There,
>
> I several times found that it is quite difficult to find an appropriate
> library in package index.
>
> I have two ides to improve the package index:
Thank you for your ideas, but I
On Tue, Feb 14, 2017 at 04:34:09PM -0500, Barry Warsaw wrote:
> 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
On Sun, Feb 12, 2017 at 05:01:58PM -0200, Joao S. O. Bueno wrote:
> You realize now that if we accept this change, and given your example,
> any "well behaved" Python code with markup will in a couple months
> required to be like
>
> class MyClass:
> """Docstring."""
>
> def
On Fri, Feb 10, 2017 at 11:13:47AM +0200, Markus Meskanen wrote:
> I'm suggesting the addition of support to using a dot notation when
> defining a function to be a method of a class, or a callback attribute. For
> example:
>
> def foo(self):
> pass
> Foo.foo = foo
>
> Becomes:
>
On Fri, Feb 10, 2017 at 10:05:30PM +1100, Chris Angelico wrote:
> * What would the __name__ be? In "def ham.spam():", is the name "spam"
> or "ham.spam"?
"spam" of course, just like it is now:
py> class Ham:
... def spam(self):
... ...
...
py>
py> Ham.spam.__name__
'spam'
You
On Fri, Feb 10, 2017 at 02:28:25PM +0200, Markus Meskanen wrote:
> I've started working on a PEP for this since most people seem to be for it.
I don't know how you get "most people" -- there's only been a handful of
responses in the few hours since the original post. And apart from one
On Sat, Feb 11, 2017 at 01:25:40AM +1100, Chris Angelico wrote:
> For what it's worth, my answers would be:
>
> __name__ would be the textual representation of exactly what you typed
> between "def" and the open parenthesis. __qualname__ would be built
> the exact same way it currently is, based
On Fri, Feb 17, 2017 at 12:24:53AM -0500, Joseph Hackman wrote:
> I propose a keyword to mark an expression for delayed/lazy execution, for
> the purposes of standardizing such behavior across the language.
>
> The proposed format is:
> delayed:
> i.e. log.info("info is %s", delayed:
On Wed, Jan 18, 2017 at 04:24:39AM -0600, Elizabeth Myers wrote:
> Hello,
>
> I've noticed a lot of binary protocols require variable length
> bytestrings (with or without a null terminator), but it is not easy to
> unpack these in Python without first reading the desired length, or
> reading
On Mon, Jan 16, 2017 at 11:01:23AM +0100, Stephan Houben wrote:
[...]
> So the following would not be a valid FMA fallback
>
> double bad_fma(double x, double y, double z) {
> return x*y + z;
> }
[...]
> Upshot: if we want to provide a software fallback in the Python code, we
> need to do
On Thu, Jan 19, 2017 at 08:31:03AM +, Mark Dickinson wrote:
> On Thu, Jan 19, 2017 at 1:27 AM, Steven D'Aprano <st...@pearwood.info> wrote:
> > [...] struct already supports
> > variable-width formats.
>
> Unfortunately, that's not really true: the Pascal string
On Fri, Jan 20, 2017 at 05:16:28AM +1100, Chris Angelico wrote:
> To be fair, the name "struct" implies a C-style structure, which
> _does_ have a fixed size, or at least fixed offsets for its members
Ah, the old "everyone thinks in C terms" fallacy raises its ugly head
agan :-)
The name
On Thu, Aug 18, 2016 at 12:26:26PM -0400, Random832 wrote:
> There's a precedent. "$()" works this way in bash - call it a recursive
> parser context or whatever you like, but the point is that "$(command
> "argument with spaces")" works fine, and humans don't seem to have any
> trouble with it.
On Thu, Aug 18, 2016 at 08:27:50PM -0400, Eric V. Smith wrote:
> Right. Because all strings (regardless of prefixes) are first parsed as
> strings, and then have their prefix "operator" applied, it's easy for a
> parser to ignore any sting prefix character.
Is that why raw strings can't end
On Tue, Feb 28, 2017 at 12:54:26PM +0100, Michel Desmoulin wrote:
> dict.get() is a very useful method, but for lists and tuples, we need to
> rely on try/except instead.
No you don't. You can use slicing.
alist = [1, 2, 3]
print(alist[99:100]) # get the item at position 99
In my experience,
On Tue, Feb 28, 2017 at 04:16:28PM +0100, Michel Desmoulin wrote:
>
>
> Le 28/02/2017 à 15:45, Steven D'Aprano a écrit :
> > On Tue, Feb 28, 2017 at 12:54:26PM +0100, Michel Desmoulin wrote:
> >> dict.get() is a very useful method, but for lists and tuples, we need to
On Wed, Mar 01, 2017 at 06:59:52AM +0800, 语言破碎处 wrote:
> solution:
> allow __repr__ to return
> str
> OR tuple: (args, kws)
>
> Better, isn't it?
No.
--
Steve
___
Python-ideas mailing list
Python-ideas@python.org
On Tue, Feb 28, 2017 at 09:30:37PM -0300, Soni L. wrote:
> Stateful functions?
What?
--
Steve
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct:
On Wed, Mar 01, 2017 at 02:56:44AM +0100, Michel Desmoulin wrote:
> > first_item = (alist[0:1] or ["ham"])[0]
>
> Come on, I've been doing Python for more than a decade and never saw
> anybody doing that. Even reading it in a code would make me scratch my
> head for a moment with a "what is it
On Tue, Feb 28, 2017 at 10:17:31PM +0100, Victor Stinner wrote:
> My question is: would it make sense to implement this feature
[positional only parameters]
> in Python directly?
+0 on positional-only parameters.
> If yes, what should be the syntax? Use "/" marker?
I think that / makes a
On Thu, Mar 02, 2017 at 04:23:08AM +0100, Jürgen A. Erhard wrote:
> > The OP seems to be proposing that we reflect this identity between
> > types and sets in Python by spelling "isinstance(obj, T)" as "obj in
> > T" and "issubclass(S, T)" as "S <= T". This proposal has some solid
> > theory
On Thu, Mar 02, 2017 at 01:08:42PM +0100, M.-A. Lemburg wrote:
> Sorry for the confusion. NoDefault would be usable just like
> any other singleton.
But that is exactly the trouble! We already have a singleton to indicate
"no default" -- that is spelled None.
Occasionally, we need to allow
On Thu, Mar 02, 2017 at 10:03:29AM +0200, Serhiy Storchaka wrote:
> I propose to add a new syntax for optional parameters. If the argument
> corresponding to the optional parameter without default value is not
> specified, the parameter takes no value. As well as the "*" prefix means
>
On Sun, Sep 04, 2016 at 12:26:58AM +0300, Koos Zevenhoven wrote:
> On Friday, while replying to a post on python-dev about PEP 526
> (variable annotations), I ended up mentioning things that I think a
> good type checker should do, which seem to differ from the general
> understanding. The
On Tue, Sep 06, 2016 at 03:59:10AM +0200, Arek Bulski wrote:
> Implementing this in pure python wont take a lot of work.
Great. Well, here's a tracker issue for it.
http://bugs.python.org/issue27964
Can you provide a patch? Don't forget the tests and documentation.
Providing a patch doesn't
On Tue, Sep 06, 2016 at 05:29:18PM +0200, Arek Bulski wrote:
[I think Arek is quoting me here]
> > One moderately stong piece of evidence would be if this function is widely
> > available in third-party libraries and other languages.
>
> Wrong. Python is NOT known for doing everything by how it
This thread is just going around and around in circles, so I will make
one final response and then I'm going to bow out.
On Thu, Sep 08, 2016 at 11:34:57AM +0200, Arek Bulski wrote:
> Needs to be shuffled().
>
> https://github.com/construct/construct/blob/master/tests/test_all.py
> See? No way
On Wed, Sep 07, 2016 at 11:43:59PM +0200, Sven R. Kunze wrote:
> BUT experienced devs also need to recognize and respect the fact that
> younger/unexperienced developers are just better in detecting
> inconsistencies and bloody work-arounds.
That is not a fact. It is the opposite of a fact --
On Thu, Sep 08, 2016 at 12:22:28AM +0200, Sven R. Kunze wrote:
> About the confusion of returning None. It's not confusing in the sense
> of "o my god, I did it wrong, I need to learn it", but more, like "I
> used shuffle, BECAUSE it's the only one I could find in a hurry"
Then don't be in
On Wed, Sep 07, 2016 at 11:47:49PM -0300, Danilo J. S. Bellini wrote:
> Though I agree with the argument that inexperienced developers are
> [usually] worse, that's not the case here, unless anyone here is really
> trying to say the ones arguing for or against "shuffled" are inexperienced.
> These
On Wed, Sep 14, 2016 at 09:51:32PM +1000, Chris Angelico wrote:
> Perhaps the advice needs to be along the lines of: Decide what the
> purpose of the enum is, and follow a naming convention accordingly.
> Uppercase if you're basically making constants; lowercase if you're
> not; etcetera.
I
On Fri, Sep 16, 2016 at 03:54:18AM +1000, Chris Angelico wrote:
> On Fri, Sep 16, 2016 at 3:03 AM, Steven D'Aprano <st...@pearwood.info> wrote:
> > On Wed, Sep 14, 2016 at 09:51:32PM +1000, Chris Angelico wrote:
> >
> >> Perhaps the advice needs to be a
On Fri, Sep 16, 2016 at 12:10:22AM +, אלעזר wrote:
[...]
> Benefits of putting such a collection in stdlib (instead of as an external
> package) include:
Slow down! Before getting all excited about adding these typing hints(?)
into typing.modifiers, you first have to convince people that
On Fri, Sep 09, 2016 at 10:01:44PM +0200, Arek Bulski wrote:
> Sometimes I find myself in need of this nice operator that I used back in
> the days when I was programming in .NET, essentially an expression
>
> >>> expr ?? instead
>
> should return expr when it `is not None` and `instead`
On Sun, Sep 25, 2016 at 01:55:09AM +, אלעזר wrote:
> 1. Please consider disallowing the use of side effects of any kind in
> annotations,
That is *simply not possible* in Python.
Actually, no, that's not quite correct. One way to prohibit side-effects
would be to make all annotations
On Tue, Oct 04, 2016 at 09:09:40PM -0700, Ken Kundert wrote:
> On Wed, Oct 05, 2016 at 03:07:42AM +1100, Steven D'Aprano wrote:
> >
> > Extra newlines are cheap. Writing
> >
>
> The cost is paid in newlines *and* extra levels of indentation.
You've quoted me out of
On Sat, Oct 08, 2016 at 09:26:13PM +0200, Jelte Fennema wrote:
> I have an idea to improve indenting guidelines for dictionaries for better
> readability: If a value in a dictionary literal is placed on a new line, it
> should have (or at least be allowed to have) a n additional hanging indent.
>
On Tue, Oct 04, 2016 at 01:31:22PM +1000, Nick Coghlan wrote:
> By contrast, eliminating the vertical whitespace without actually
> reducing the level of nesting is merely hiding the readability problem
> without actually addressing it.
+1
Extra newlines are cheap. Writing
for x in
On Mon, Sep 19, 2016 at 06:38:00PM +1000, Chris Angelico wrote:
> Sounds good to me. This is definitely sounding complicated and messy
> enough to justify (a) writing a function to clear the screen, and (b)
> testing that function thoroughly as a PyPI module before pushing
> anything into the
On Mon, Sep 19, 2016 at 06:18:38AM -0400, Terry Reedy wrote:
> On 9/19/2016 4:31 AM, Paul Moore wrote:
>
> >shutil.get_terminal_size() is available on all platforms.
>
> On windows, it works with Command Prompt and PowerShell but fails in
> IDLE, as it must.
Why "must" it fail?
What is it
On Sat, Sep 17, 2016 at 09:01:53AM +, Spencer Brown wrote:
> Currently, calling divmod() on a class with __floordiv__ and __mod__
> defined, but not __divmod__ raises a TypeError. Is there any reason
> why it doesn't fallback to (self // x, self % x)?
Because things get really complex,
On Sat, Sep 17, 2016 at 11:51:16AM +0100, João Matos wrote:
> Hello,
>
> I would like to suggest adding a clear command (not function) to Python.
While technically "clear" could be a command, I think it should not be.
First off, making clear a reserved keyword, and a statement, like print
in
On Mon, Sep 19, 2016 at 01:35:53PM -0700, João Matos wrote:
> Hello,
>
> I don't see why creating a clear command would interfere with dict.clear()
> which is a function/method.
For the same reason that you can't have a method called foo.while or
foo.if or foo.raise. If clear is a "command" (a
On Mon, Sep 19, 2016 at 11:35:39PM +, אלעזר wrote:
> Xavier, how is connecting and installing different from a windows popup
> "this software requires changes to your firewall settings" or "requires
> elevated privileges" which already happens. I am all for a two-step
> process, but I think it
On Mon, Sep 19, 2016 at 05:06:50PM -0700, Ethan Furman wrote:
> On 09/19/2016 04:38 PM, אלעזר wrote:
>
> >I was talking specifically about advanced courses, in which an assignment
> > is "implement a side-channel attack using data" and you can use whatever
> > library you like.
>
> Am I
On Tue, Sep 20, 2016 at 09:56:48AM +, אלעזר wrote:
> foo.__call__.partial() solves most of the problem I think.
There are two problems with that, one obvious and one subtle.
The obvious one is that __call__ is a dunder method, which means that
accessing it directly from outside of the
On Thu, Sep 22, 2016 at 09:33:58PM +, אלעזר wrote:
> On Fri, Sep 23, 2016 at 12:18 AM Chris Angelico wrote:
>
> > # Recursion in functions
> > def spam():
> > return spam()
> >
>
> I just note that it *is* surprising, for most users, that you can't be sure
> that this
On Thu, Sep 22, 2016 at 07:21:18PM +, אלעזר wrote:
> On Thu, Sep 22, 2016 at 9:43 PM Steven D'Aprano <st...@pearwood.info> wrote:
>
> > On Thu, Sep 22, 2016 at 05:19:12PM +, אלעזר wrote:
> > > Hi all,
> > >
> > > Annotations of functio
On Fri, Sep 23, 2016 at 10:17:15AM +, אלעזר wrote:
> On Fri, Sep 23, 2016 at 6:06 AM Steven D'Aprano <st...@pearwood.info> wrote:
> > On Thu, Sep 22, 2016 at 07:21:18PM +, אלעזר wrote:
> > > On Thu, Sep 22, 2016 at 9:43 PM Steven D'Aprano wrote:
> > > >
On Sun, Sep 18, 2016 at 02:52:31AM +0200, Arek Bulski wrote:
> I am using declarative testing a lot and I found out why unit tests are so
> clunky.
I don't think unit tests are clunky.
> The reason why assertEquals(a,b) is used is because if we put
> `assert a==b` then nose can catch the
Folks,
There are pros and cons of partial over lambda over classes, and which
you prefer may be at least in part a matter of subjective taste. But
Guido has spoken that he is virulently against making partial a builtin.
It really isn't hard to put "from functools import partial" at the top
On Tue, Sep 20, 2016 at 09:34:12AM +1000, Chris Angelico wrote:
> It's more than that, though. When a student is given an assignment,
> it's usually to help said student to learn to *write code*, not to
> learn how to walk into the plumbing store of PyPI and look for
> something that approximates
On Mon, Sep 19, 2016 at 04:55:26PM +, אלעזר wrote:
> A library in PyPi still requires installing it, which undermine many of
> the benefits. It won't help me with my gist/activestate recipe, code that I
> send to a friend, etc. I want to lower the barrier of inexperienced users.
When you say
On Fri, Aug 26, 2016 at 03:23:24PM -0700, Ken Kundert wrote:
> Steven,
> This keeps coming up, so let me address it again.
>
> First, I concede that you are correct that my proposal does not provide
> dimensional analysis, so any dimensional errors that exist in this new code
> will
> not
On Sun, Aug 28, 2016 at 11:37:00AM +0100, Paul Moore wrote:
> And if you're concerned about larger numbers, such as 160, and
> the need to count zeroes, I'd argue that you should name such a
> constant - and Python 3.6 will allow you to write it as 16_000_000_000
> in any case, making
On Thu, Aug 25, 2016 at 11:34:23PM -0400, Random832 wrote:
> On Thu, Aug 25, 2016, at 19:50, Steven D'Aprano wrote:
> > Historically, there are *three* different meanings for "MB", only one of
> > which is an official standard:
> >
> > http://physics.nist.go
Ken has made what I consider a very reasonable suggestion, to introduce
SI prefixes to Python syntax for numbers. For example, typing 1K will be
equivalent to 1000.
However, there are some complexities that have been glossed over.
(1) Are the results floats, ints, or something else?
I would
On Fri, Aug 26, 2016 at 07:35:36AM +0200, Pavol Lisy wrote:
> On 8/25/16, Ken Kundert wrote:
>
> [...]
>
> > Just allowing the units to be present, even it not
> >
> > retained, is a big advantage because it can bring a great deal of clarity to
> > the
> > meaning
On Fri, Aug 26, 2016 at 02:49:51PM +0300, Ivan Levkivskyi wrote:
> 1. By defining __mul__ and __truediv__ on m, s, and other units one can
> achieve the desirable semantics
I'm not entirely sure about that. I'm not even close to an expert on the
theory of types, so I welcome correction, but it
On Thu, Aug 25, 2016 at 11:02:11AM -0700, Ken Kundert wrote:
> Once you
> allow SI scale factors on numbers, the natural tendency is for people to want
> to
> add units, which is a good thing because it gives important information about
> the number. We should allow it because it improves the
On Thu, Aug 25, 2016 at 09:03:32PM +0100, Paul Moore wrote:
> That's not to say there's no room for debate here - the proposal is
> interesting, and not without precedent (for example Windows Powershell
> supports constants of the form 1MB, 1GB
That's great! I know a few command line tools and
On Thu, Aug 25, 2016 at 08:46:54PM -0700, Ken Kundert wrote:
> This idea is new to general purpose languages,
For the record, at least some HP calculators include a "units" data type
as part of the programming language "RPL", e.g. the HP-28 and HP-48
series. I've been using those for 20+
On Tue, Sep 27, 2016 at 10:05:16AM -0700, João Matos wrote:
> Hello,
>
>
> It doesn't work in Windows.
What is "it"? Are you talking about Ctrl-L to clear the screen?
Perhaps we should start by adding Ctrl-L as a standard way to clear the
Python REPL, in the same way that Ctrl-C is the
Let's talk about lazy evaluation in a broader sense that just function
annotations.
If we had syntax for lazy annotation -- let's call them thunks, after
Algol's thunks -- then we could use them in annotations as well as
elsewhere. But if we special case annotations only, the Zen has
On Mon, Sep 26, 2016 at 10:46:57PM +1000, Steven D'Aprano wrote:
> Let's talk about lazy evaluation in a broader sense that just function
> annotations.
>
> If we had syntax for lazy annotation -- let's call them thunks, after
> Algol's thunks
Er, that should be lazy evaluati
On Wed, Oct 26, 2016 at 03:37:54AM +0200, Mikhail V wrote:
> Extended ASCII
There are over 200 different, mutually incompatible, so-called
"extended ASCII" code pages and encodings.
And of course it is ludicruous to think that you can fit all the world's
characters into only 8-bits. There are
On Wed, Oct 26, 2016 at 02:40:36PM -0700, Nikolaus Rath wrote:
> It also imposes a significant burden on scripting.
"It" being a configurable REPL.
> I often have elements like this in shell scripts:
>
> output=$(python < import h5py
> with h5py.File('foo', 'r') as fh:
> print((fh['bla']
On Wed, Oct 26, 2016 at 08:59:20AM +1100, Chris Angelico wrote:
> So should French programmers write string literals «like this»?
Not unless they want to get in trouble from the Académie française. They
should write them « like this ».
*wink*
--
Steve
On Tue, Oct 25, 2016 at 10:13:54PM +0100, Paul Moore wrote:
> I've seen a lot of syntax proposals recently that are based around
> providing better ways of writing "one liner" styles of code.
[...]
> However, looking at them from the point of view of someone working at
> the interactive prompt,
On Tue, Oct 25, 2016 at 05:15:58PM +0200, Mikhail V wrote:
[...]
> >Or it can take a mapping (usually a dict) that maps either characters or
> >ordinal numbers to a new string (not just a single character, but an
> >arbitrary string) or ordinal numbers.
> >
> >str.maketrans({'a': 'A', 98: 66,
On Thu, Oct 27, 2016 at 10:35:32AM +0100, Paul Moore wrote:
> The Windows default command line editing experience is a lot better
> (IMO) than the (non-readline) Unix default, and it's common throughout
> all interactive prompts (Python's REPL included). As a result, when
> readline is installed
On Thu, Oct 27, 2016 at 02:50:52PM +0200, James Pic wrote:
> And I'm always facing the same problem: I have to either build runtime
> dependencies on the server, either package my thing in the platform
> specific way. I feel like I've spent a really huge amount of time doing
> this king of thing.
On Tue, Oct 25, 2016 at 12:17:56PM -0700, Nathaniel Smith wrote:
> I get that this list's default is to push
> back on proposed changes, and it's a good principle in general, but
> "improved error messages" are *really* cheap. The bar should be pretty
> low, IMO.
I think its even lower than
On Tue, Oct 25, 2016 at 04:55:21PM -0500, Ryan Gonzalez wrote:
> Also, as an extension of this idea, would it be possible to improve errors
> like this:
>
>
> class X: pass
> X() # object() takes no parameters
>
>
> to show the actual type instead of just 'object'?
My wild guess is that the
On Fri, Oct 28, 2016 at 06:30:05PM +1000, Nick Coghlan wrote:
[...]
> 1. Do we collectively agree that "existence checking" is a useful
> general concept that exists in software development and is distinct
> from the concept of "truth checking"?
Not speaking for "we", only for myself: of course.
On Sat, Nov 05, 2016 at 07:50:44PM +1000, Nick Coghlan wrote:
> Hi folks,
>
> As promised, here's a follow-up to the withdrawn PEP 531 that focuses
> on coming up with a common protocol driven solution to conditional
> evaluation of subexpressions that also addresses the element-wise
> comparison
On Sun, Nov 06, 2016 at 06:46:40AM +0200, Ram Rachum wrote:
> Hi everyone,
>
> Here is a simplification of a problem that's been happening in my code:
>
> import contextlib
>
> @contextlib.contextmanager
> def f():
> print('1')
> try:
> yield
> finally:
> print('2')
On Mon, Nov 07, 2016 at 02:21:04AM -0200, Danilo J. S. Bellini wrote:
> 2016-11-06 23:55 GMT-02:00 Steven D'Aprano <st...@pearwood.info>:
>
> > On Sun, Nov 06, 2016 at 04:46:42PM -0200, Danilo J. S. Bellini wrote:
> >
> > > 1.2. Sub-expressions in an expression
On Sun, Nov 06, 2016 at 09:31:06AM -0500, Eric V. Smith wrote:
> The point remains: do we want to be able to create unevaluated
> expressions that can be evaluated at a different point?
I sometimes think that such unevaluated expressions (which I usually
call "thunks") would be cool to have.
On Sun, Nov 06, 2016 at 01:28:34AM -0500, Nathan Dunn wrote:
> Python has very intuitive and clear syntax, except when it comes to method
> definitions, particularly dunder methods.
I disagree with your premise here. Python's method definitions are just
as intuitive and clear as the rest of
Hello Adil, and welcome!
But...
you've converted the ENTIRE Python tutorial AND documentation into PDF
files, stuck them into zip files with a non-standard file extension
(.okular) that most people won't be able to deal with, and expect us to
read the whole thing -- over 200 pages -- looking
On Wed, Oct 19, 2016 at 03:08:21PM -0400, Todd wrote:
[taking your later comment out of the order it was written]
> If this sort of thing doesn't interest you I won't be offended if you stop
> reading now, and I apologize if it is considered off-topic for this ML.
No problem Todd, we shouldn't
1 - 100 of 2842 matches
Mail list logo