were bullying.
The behavior on the list the past few days has been unforgivably
toxic, and that has nothing to do with the behavior of Bart et al.
-- Devin
--
https://mail.python.org/mailman/listinfo/python-list
g someone. Even if you think it is
justified, consider how it looks to others. I am afraid of ever
getting on your "bad side", and I bet the same is true of other
non-Bart people, too.
-- Devin
--
https://mail.python.org/mailman/listinfo/python-list
ety a couple of years ago (to help with
things like GIL-less python projects), but I guess nothing ever came
of it.
-- Devin
--
https://mail.python.org/mailman/listinfo/python-list
possibility, and there's no rule that says "just because this will
always raise an exception, we can fail at compile-time instead". Maybe
a particular UnboundLocalError was on purpose, after all. Python
doesn't know. So probably this can't ever sensibly be a compile
error, even if it's a fantastically useful lint warning.
-- Devin
--
https://mail.python.org/mailman/listinfo/python-list
raise UnboundLocalError if not x
-- Devin
--
https://mail.python.org/mailman/listinfo/python-list
ean function f. But
> what is the easiest (fool-proof) way to print out a diagram of g ?
Python doesn't come with support for (ro)bdds built-in. You're
probably thinking of this library, which includes visualization
instructions:
http://pyeda.readthedocs.io/en/latest/bdd.html
an? (if a platform supports
using the fd instead, use that, otherwise use f.name).
.. *:
http://stackoverflow.com/questions/17127522/create-a-hard-link-from-a-file-handle-on-unix/18644492#18644492
-- Devin
--
https://mail.python.org/mailman/listinfo/python-list
Sadly, no. :( Consoles (and stdout) are just text, not hypertext. The way to
make an URL clickable is to use a terminal that makes URLs clickable, and print
the URL:
print("%s: %s" % (description, url))
-- Devin
On Tue, Jan 3, 2017 at 11:46 AM, Deborah Swanson
wrote:
> Excel
Sadly, no. :( Consoles (and stdout) are just text, not hypertext. The way
to make an URL clickable is to use a terminal that makes URLs clickable,
and print the URL:
print("%s: %s" % (description, url))
-- Devin
On Tue, Jan 3, 2017 at 11:46 AM, Deborah Swanson
wrote:
> Excel
Documentation is all you can do.
-- Devin
On Thu, Nov 26, 2015 at 5:35 AM, Chris Lalancette wrote:
> On Thu, Nov 26, 2015 at 7:46 AM, Devin Jeanpierre
> wrote:
>> Why not take ownership of the file object, instead of requiring users
>> to manage lifetimes?
>
> Yeah, I&#
Why not take ownership of the file object, instead of requiring users
to manage lifetimes?
-- Devin
On Wed, Nov 25, 2015 at 12:52 PM, Chris Lalancette
wrote:
> Hello,
> I'm currently developing a library called pyiso (
> https://github.com/clalancette/pyiso), used for manipul
I think you're missing the line where I said all the relevant
conversation happened in IRC, and that you should refer to logs.
On Sun, Jul 19, 2015 at 11:25 PM, Terry Reedy wrote:
> On 7/19/2015 9:20 PM, Devin Jeanpierre wrote:
>
>> Search your logs for https://bugs.python.org/i
On Sun, Jul 19, 2015 at 8:05 PM, Steven D'Aprano wrote:
> On Mon, 20 Jul 2015 11:20 am, Devin Jeanpierre wrote:
>> I was most frustrated by the first case -- the patch was (informally)
>> rejected in favor of the "right" fix, and the "right" fix was
>
tes or context thrown at you. The rhetoric almost
always shies _just_ short of ceasing bugfixes (until 2020, when that
abruptly becomes a cracking good idea). e.g. in "2.7 is here until
2020, please don't call it a waste".
I don't want to argue over who said what. I am sure e
e review).
That is not how I have experienced contribution to CPython. No, the
patches are *not* guaranteed, and in my experience they are not likely
to be accepted.
If the issue was closed as fixed before I contributed the backported
patch, does anyone even see it?
-- Devin
--
https://mail.python.org/mailman/listinfo/python-list
world. Fixing bugs and making performance
improvements can sometimes significantly help the >1B people who use
the software written in Python 2.7.
-- Devin
On Sat, Jul 18, 2015 at 4:36 PM, Terry Reedy wrote:
> I asked the following as an off-topic aside in a reply on another thread. I
> go
On Sat, Jun 27, 2015 at 6:18 PM, Steven D'Aprano wrote:
> On Sun, 28 Jun 2015 06:30 am, Devin Jeanpierre wrote:
>
>> On Fri, Jun 26, 2015 at 11:16 PM, Steven D'Aprano
>> wrote:
>>> On Sat, 27 Jun 2015 02:05 pm, Devin Jeanpierre wrote:
>>>
>>
On Fri, Jun 26, 2015 at 11:16 PM, Steven D'Aprano wrote:
> On Sat, 27 Jun 2015 02:05 pm, Devin Jeanpierre wrote:
>
>> On Fri, Jun 26, 2015 at 8:38 PM, Steven D'Aprano
>> wrote:
>>> Now you say that the application encrypts the data, except that the user
>&
ta, and the receiver cannot read the data.
> That's two problems solved.
No, because another application could pretend to be the file-sending
application, but send unencrypted data instead of encrypted data.
-- Devin
--
https://mail.python.org/mailman/listinfo/python-list
Johannes, I agree with a lot of what you say, but can you please have
less of a mean attitude?
-- Devin
On Fri, Jun 26, 2015 at 3:42 PM, Johannes Bauer wrote:
> On 26.06.2015 23:29, Jon Ribbens wrote:
>
>>> While you seem to think that Steven is rampaging about nothing, he does
On Thu, Jun 25, 2015 at 2:57 AM, Chris Angelico wrote:
> On Thu, Jun 25, 2015 at 7:41 PM, Devin Jeanpierre
> wrote:
>>> I know that the OP doesn't propose using ROT-13, but a classical
>>> substitution cipher isn't that much stronger.
>>
>> Yes, it
On Thu, Jun 25, 2015 at 2:25 AM, Steven D'Aprano
wrote:
> On Thursday 25 June 2015 14:27, Devin Jeanpierre wrote:
>> The original post said that the sender will usually send files they
>> encrypted, unless they are malicious. So if the sender wants them to
>> be e
sually very oppositional when it comes to rolling your own
crypto, but am I alone here in thinking the OP very clearly laid out
their case?
-- Devin
--
https://mail.python.org/mailman/listinfo/python-list
How about a random substitution cipher? This will be ultra-weak, but
fast (using bytes.translate/bytes.maketrans) and seems to be the kind
of thing you're asking for.
-- Devin
On Tue, Jun 23, 2015 at 12:02 PM, Randall Smith wrote:
> Chunks of data (about 2MB) are to be stored on machin
Snipped aplenty.
On Wed, Jun 10, 2015 at 8:21 PM, Steven D'Aprano wrote:
> On Thu, 11 Jun 2015 08:10 am, Devin Jeanpierre wrote:
> [...]
>> I could spend a bunch of time writing yet another config file format,
>> or I could use text format protocol buffers, YAML, or TO
On Wed, Jun 10, 2015 at 4:46 PM, Terry Reedy wrote:
> On 6/10/2015 7:39 PM, Devin Jeanpierre wrote:
>>
>> On Wed, Jun 10, 2015 at 4:25 PM, Terry Reedy wrote:
>>>
>>> On 6/10/2015 6:10 PM, Devin Jeanpierre wrote:
>>>
>>>> The problem is
On Wed, Jun 10, 2015 at 4:39 PM, Devin Jeanpierre
wrote:
> On Wed, Jun 10, 2015 at 4:25 PM, Terry Reedy wrote:
>> On 6/10/2015 6:10 PM, Devin Jeanpierre wrote:
>>
>>> The problem is that there are two different ways repr might write out
>>> a dict equal to {&#x
On Wed, Jun 10, 2015 at 4:25 PM, Terry Reedy wrote:
> On 6/10/2015 6:10 PM, Devin Jeanpierre wrote:
>
>> The problem is that there are two different ways repr might write out
>> a dict equal to {'a': 1, 'b': 2}. This can make tests brittle
>
>
>
AM, Steven D'Aprano
wrote:
> On Wednesday 10 June 2015 14:48, Devin Jeanpierre wrote:
>
> [...]
>> and literal_eval is not a great idea.
>>
>> * the common serializer (repr) does not output a canonical form, and
>> can serialize things in a way that they can't
On Tue, Jun 9, 2015 at 8:52 PM, Steven D'Aprano
wrote:
> On Wednesday 10 June 2015 10:47, Devin Jeanpierre wrote:
>
>> Passing around data that can be put into ast.literal_eval is
>> synonymous with passing around data taht can be put into eval. It
>> sounds lik
underrated. (Relatedly: underdocumented, too.)
/me lifts head out of kool-aid and gasps for air
-- Devin
On Tue, Jun 9, 2015 at 5:17 PM, Irmen de Jong wrote:
> On 10-6-2015 1:06, Chris Angelico wrote:
>> On Wed, Jun 10, 2015 at 6:07 AM, Devin Jeanpierre
>> wrote:
>>> There&
better compatibility properties and are a bit more testable to boot
(since text format protobufs are always output in a canonical (sorted)
form.)
-- Devin
On Tue, Jun 9, 2015 at 11:35 AM, Chris Warrick wrote:
> On Tue, Jun 9, 2015 at 8:08 PM, Neal Becker wrote:
>> One of the most
The operation A opens an external file, reads data out of it and writes
> it in Watershed object. Is it a bad idea to multiprocess this? (I guess it
> is, since the file might be read twice at the same time)
That does sound like a bad idea, for the reason you gave. It might be
pos
27;s a one-time cost per project at most, whereas all
the other issues (potentially) rear their head with every single bug
report.
-- Devin
--
https://mail.python.org/mailman/listinfo/python-list
es for callbacks are broken.
-- Devin
--
https://mail.python.org/mailman/listinfo/python-list
)
> Prelude> (x,y,z)
> (1,2,3)
Yeah, but Haskell is ludicrous.
Prelude> let (x, 2) = (1, 3)
Prelude>
Only non-falsifiable patterns really make sense as the left hand side
of an assignment in a language without exceptions, IMO. Otherwise you
should use a match/case statement. (Of course, Python does have
exceptions...)
-- Devin
--
https://mail.python.org/mailman/listinfo/python-list
On Thu, Feb 5, 2015 at 8:08 AM, Ian Kelly wrote:
> On Thu, Feb 5, 2015 at 2:40 AM, Steven D'Aprano
> wrote:
>> Devin Jeanpierre wrote:
>>> On Wed, Feb 4, 2015 at 1:18 PM, Chris Angelico wrote:
>>>>>>>> [result] = f()
>>>>>>>
e C's pointers or C++'s references. There's nothing that you
> could put into the list that would have this behaviour.
C pointers don't do that either. It's really just references. (C
pointers aren't any more action-at-a-distance than Python attributes.)
Anyway, it
On Mon, Feb 2, 2015 at 6:20 AM, Steven D'Aprano
wrote:
> Devin Jeanpierre wrote:
>> Oops, I just realized why such a claim might be made: the
>> documentation probably wants to be able to say that any method can use
>> super(). So that's why it claims that it isn&#x
:
> ... def f(self): pass # f defined inside the class
> ...
> py> def f(self): pass # f defined outside the class
> ...
> py> f, Q.f = Q.f, f # Swap the "inside" f and the "outside" f.
> py> instance = Q()
> py> instance.f # Uses "outside" f, so not a real method!
> >
> py> MethodType(f, instance) # Uses "inside" f, so is a real method!
> >
You are really missing the point, if you think that surprises me.
-- Devin
--
https://mail.python.org/mailman/listinfo/python-list
On Mon, Feb 2, 2015 at 5:00 AM, Devin Jeanpierre wrote:
> On Mon, Feb 2, 2015 at 4:06 AM, Steven D'Aprano
> wrote:
>>> On Sun, Feb 1, 2015 at 11:15 PM, Steven D'Aprano
>>> wrote:
>> Both K.f and K.g are methods, even though only one meets the definition
&
iterable
class MyIterable(object):
def __getitem__(self, i): return i
The docs are not "wrong", they are just making a distinction for
humans that is separate from the python types involved. This is OK.
-- Devin
--
https://mail.python.org/mailman/listinfo/python-list
-- Devin
On Sun, Feb 1, 2015 at 11:15 PM, Steven D'Aprano
wrote:
> Gregory Ewing wrote:
>
>> Steven D'Aprano wrote:
>>> [quote]
>>> If the object has a method named __dir__(), this method will
>>> be called and must return the list of
On Sun, Feb 1, 2015 at 2:27 PM, Paul Rubin wrote:
> Devin Jeanpierre writes:
>> That said, Haskell (and the rest) do have a sort of type coercion, of
>> literals at compile time (e.g. 3 can be an Integer or a Double
>> depending on how you use it.)
>
> That's poly
print x
case x of
Nothing -> putStrLn "Not found"
Some y -> putStrLn (show y)
Both of these work whenever x is something that can be null and can be
shown -- in Haskell, that's anything of type Maybe T, where you have
access to a Show implementation for T. In Python
On Sun, Feb 1, 2015 at 8:34 AM, Steven D'Aprano
wrote:
> Devin Jeanpierre wrote:
>
>> It's really only dynamically typed languages that have a single null
>> value of a single type. Maybe I misunderstand the original statement.
>
> Pascal is statically t
rom, say, Java?
It's really only dynamically typed languages that have a single null
value of a single type. Maybe I misunderstand the original statement.
-- Devin
--
https://mail.python.org/mailman/listinfo/python-list
oks nearly exactly like the original
(bad) Python approach, except it uses unique_ptr to store the file,
and isn't broken. ("Modern") C++ makes this easy to get right. But
then, this isn't the common case.
-- Devin
--
https://mail.python.org/mailman/listinfo/python-list
On Wed, Jan 28, 2015 at 4:34 PM, Steven D'Aprano
wrote:
> Devin Jeanpierre wrote:
>> Git doesn't help if you lose your files in between commits,
>
> Sure it does? You just lose the changes made since the previous commit, but
> that's no different from restoring
I distrust any backup strategy that requires explicit action by the
user. I've seen users fail too often. (Including myself.)
-- Devin
On Wed, Jan 28, 2015 at 2:02 PM, Chris Angelico wrote:
> On Thu, Jan 29, 2015 at 8:52 AM, Devin Jeanpierre
> wrote:
>> Git doesn't help
n between commits, or if you
lose the entire directory between pushes.
-- Devin
--
https://mail.python.org/mailman/listinfo/python-list
pawn", that
lets you fork+exec instead of just forking.
I too would be interested in such a backport. I considered writing
one, but haven't had a strong enough need yet.
-- Devin
--
https://mail.python.org/mailman/listinfo/python-list
mit, and I think Google
Drive has a trash bin, as well as a 29 day recovery for emptied trash
items.
That said, hindsight is easier than foresight. I'm glad you were able
to recover your files!
-- Devin
On Wed, Jan 28, 2015 at 10:09 AM, wrote:
> Last night I accidentally deleted a g
ub
instance" would avoid this confusion for everyone.
I think the only reason to avoid "instance" in the past would have
been the old-style object confusion, as Ben Finney pointed out. (BTW I
agree with literally every single thing he said in this thread, it's
really amazing.)
-- Devin
--
https://mail.python.org/mailman/listinfo/python-list
The def statement populates a few items, __name__
> being one of them. One of the reasons lambda
> is not encouraged is because its name is always '', which just ain't
> helpful when the smelly becomes air borne! ;)
Actually, in this case you'd probably want the funct
happy until you can do:
def call(*a, **kw): return lambda f: f(*a, **kw)
@call()
def x, y ():
yield 1
yield 2
Actually, maybe not even then.
-- Devin
--
https://mail.python.org/mailman/listinfo/python-list
ce is good.
-- Devin
On Tue, Jan 20, 2015 at 12:15 PM, Ken Seehart wrote:
> Exactly. There are over 23,000 different kinds of trees. There's no way you
> could get all of them to fit in a library, especially a standard one.
> Instead, we prefer to provide people with the tools they
inear scan, which gets a little slow pretty
quickly. You can make insertion slow (usually OK) by sorting on
insertion, but if you ever forget to resort your list you will get a
subtle bug you might not notice for a while. And so on. It's better in
every way to use the third-party blist mod
laced. But stdout itself, file
> descriptor 1, is not available:
It surprises me that IDLE, and most other shells, don't dup2
stdout/err/in so that those FDs talk to IDLE.
-- Devin
--
https://mail.python.org/mailman/listinfo/python-list
ee wholeheartedly. That said, I do think reduce(operator.mul, [1,
2, 3, 4]) actually _is_ a better example, since it cuts right to the
point.
-- Devin
--
https://mail.python.org/mailman/listinfo/python-list
course if you choose not to have the full associativity rule for
empty products, then anything is possible.)
-- Devin
--
https://mail.python.org/mailman/listinfo/python-list
er* 0**0 could be zero, on the basis that you can't take
>>> limits of integer-valued quantities, and zero times itself zero times
>>> surely has to be zero.
>>
>> No. No no no. On natural numbers no other thing makes sense than 1.
>
> On the basis that m**n means m multiplied by itself n times:
>
> 5**4 = 5*5*5*5 = 625
>
> that gives us:
>
> 0**0 = zero multiplied by itself zero times.
>
> You can multiply 0 by any number you like, and the answer will always be 0,
> not 1. Even if that other number is 0, the answer is still 0.
If you are performing no multiplications, you never multiplied 0 by
any number at all, so what you get from 0*X is irrelevant.
-- Devin
--
https://mail.python.org/mailman/listinfo/python-list
On Fri, Jan 9, 2015 at 12:58 AM, Devin Jeanpierre
wrote:
>> Arguably, *integer* 0**0 could be zero, on the basis that you can't take
>> limits of integer-valued quantities, and zero times itself zero times
>> surely has to be zero.
I should have responded in more deta
On Fri, Jan 9, 2015 at 12:49 AM, Steven D'Aprano
wrote:
> Devin Jeanpierre wrote:
>
>> On Thu, Jan 8, 2015 at 6:43 PM, Dave Angel wrote:
>>> What you don't say is which behavior you actually expected. Since 0**0
>>> is undefined mathematically, I'd e
from which we derive its
behavior on the reals.
-- Devin
On Thu, Jan 8, 2015 at 11:28 PM, Marko Rauhamaa wrote:
> Devin Jeanpierre :
>
>> If 0**0 is defined, it must be 1.
>
> You can "justify" any value a within [0, 1]. For example, choose
>
>y(a, x) = log(a
Thanks Ben, with your encouragement I have filed
http://bugs.python.org/issue23201
-- Devin
On Thu, Jan 8, 2015 at 7:03 PM, Ben Finney wrote:
> Dave Angel writes:
>
>> What you don't say is which behavior you actually expected. Since
>> 0**0 is undefined mathematicall
BTW, Ben, you linked to a file on your hard drive. You meant
https://docs.python.org/2/library/decimal.html#decimal.InvalidOperation
-- Devin
--
https://mail.python.org/mailman/listinfo/python-list
0 ** 0
I'd file a bug report but I'm anticipating some rational (heh)
explanation. Any ideas?
Python 3.4 also raises this exception, but the error message is less
informative. ("decimal.InvalidOperation: []").
-- Devin
--
https://mail.python.org/mailman/listinfo/python-list
r not grep
succeeded -- so you can redirect stdout and stderr to os.devnull and
avoid using .communicate(). Also, if you can't use .communicate(),
but need to access stdout, this is the most common reason to need
threads with subprocess.
-- Devin
On Wed, Jan 7, 2015 at 8:00 PM, Ganesh P
em as
my_svr.blahblah, then only the second set of imports are necessary.
P.S. don't use import *, and if you do use import *, don't use more
than one per file -- it makes it really hard to figure out where a
given global came from (was it defined here? was it defined in model?
was it defined in sampling?)
I hope that resolves all your questions!
-- Devin
--
https://mail.python.org/mailman/listinfo/python-list
On Mon, Dec 15, 2014 at 4:42 PM, Ben Finney wrote:
> Devin Jeanpierre writes:
>
>> On Sun, Dec 14, 2014 at 11:29 PM, Ben Finney
>> wrote:
>> > from __future__ import unicode_literals
>>
>> Ordinarily, for 2.x/3.3+ code I would suggest not doing
in benefit
of the u'...' syntax addition.
For 3.2, you'll have to do b'...' for bytes, '...' for unicode, and
str('...') for platform-specific strings (bytes on 2.x, unicode on
3.x). It is in good taste to make an alias of str so it's less
confusin
ersus “non-callable attribute”?
Obviously, yes.
-- Devin
--
https://mail.python.org/mailman/listinfo/python-list
On Sun, Aug 10, 2014 at 7:22 PM, Steven D'Aprano
wrote:
> Devin Jeanpierre wrote:
>
>> On Sun, Aug 10, 2014 at 9:31 AM, Steven D'Aprano
>> wrote:
>
>>> I don't think that using a good, but not cryptographically-strong, random
>>> number gene
oose the seed, so it's useless
for deterministic password generation. There are also lots of small
libraries some person wrote at some time, but that sounds shady. ;)
-- Devin
--
https://mail.python.org/mailman/listinfo/python-list
and a wrapper
> around the standard library. I specifically did not want to try to write
> better cryptographic routines.
The fallback is what worries me. Falling back from a secure thing to
an insecure thing doesn't sound good.
-- Devin
--
https://mail.python.org/mailman/listinfo/python-list
aphically weak. Isn't the normal thing to do to
use a cryptographic hash function to generate a pseudorandom sequence?
Someone should write a cryptographically secure pseudorandom number
generator library for Python. :(
(I think OpenSSL comes with one, but then you can't choose the seed.)
-- Devin
--
https://mail.python.org/mailman/listinfo/python-list
ot;).
Teaching a beginner a new programming language, but pretending it's
Python, doesn't sound like a fantastic idea.
-- Devin
--
https://mail.python.org/mailman/listinfo/python-list
ng around here. It was tongue in cheek, wasn't it?
What isn't "true" about Python 2.x's unicode support? The only feature
I ever missed was case folding. (Not that 3.x does much better at that... :)
The stdlib had poor unicode support, if that's what you mean. That
could've been fixed without introducing backwards-incompatible
changes, though.
-- Devin
--
https://mail.python.org/mailman/listinfo/python-list
llow that a Python
implementation may choose to do this (e.g. small integers are cached),
but it isn't so hard to guarantee it. (You don't even have to cache
anything. PyPy makes things is-identical even when they are behind the
scenes different objects in memory, IIRC.)
See also http://
t;> re.fullmatch(r'.', '')
>>>
>>> re.fullmatch(r'.*', 'a')
<_sre.SRE_Match object; span=(0, 1), match='a'>
>>> re.fullmatch(r'.*', 'ab')
<_sre.SRE_Match object; span=(0, 2), match='ab'>
>>> re.fullmatch(r'.*', '')
<_sre.SRE_Match object; span=(0, 0), match=''>
-- Devin
--
https://mail.python.org/mailman/listinfo/python-list
The reason I did not use \d\d* or \d+ or ^\d+$ or any number of
more-correct things was because the OP was new to regexps.
-- Devin
On Sun, Jul 6, 2014 at 3:49 PM, MRAB wrote:
> On 2014-07-06 18:41, Albert-Jan Roskam wrote:
>>
>>
>>
>>
>>> In article ,
>
In related news, the regexp I gave for numbers will match "1a".
-- Devin
On Sun, Jul 6, 2014 at 8:32 AM, MRAB wrote:
> On 2014-07-06 13:09, Devin Jeanpierre wrote:
>>
>> On Sun, Jul 6, 2014 at 4:51 AM, wrote:
>>>
>>> Hi,
>>>
>>>
][0-9]*, which matches the
strings "1", "12", and "007", but not "" or "Jeffrey".
Another useful one is `.*` -- `.` matches exactly one character, no
matter what that character is. So, `.*` matches any string at all.
The power of regexps stems from t
tly
> parses nested tokens, and named groups can definitely be nested.
Nesting isn't inherently a problem. Since nesting doesn't change the
way they parse, you can ignore nesting for the purposes of pulling out
named groups. Find each unescaped "(?P<...>".
(Making
Please don't be unnecessarily cruel and antagonistic.
-- Devin
On Tue, Jun 10, 2014 at 4:16 PM, Mark Lawrence wrote:
> On 10/06/2014 20:43, alister wrote:
>>
>> On Tue, 10 Jun 2014 12:27:26 -0700, wxjmfauth wrote:
>>
>
> [snip the garbage]
>
>
>>>
ertainly suboptimal. Subprocesses are better in every way.
-- Devin
--
https://mail.python.org/mailman/listinfo/python-list
In unix shells you can literally use a new line. Or is that only bash?
-- Devin
On Fri, May 30, 2014 at 2:11 PM, Duncan Booth
wrote:
> Chris Angelico wrote:
>
>> Problem: Translate this into a shell one-liner:
>>
>> import os
>> for root, dirs, files in os.walk(&q
e not safe in a daemon thread at shutdown.
-- Devin
On Wed, May 28, 2014 at 6:20 PM, Carl Banks wrote:
> Ok, so I have an issue with cleaning up threads upon a unexpected exit. I
> came up with a solution but I wanted to ask if anyone has any advice or
> warnings.
>
> Basically I
way of putting it, Mark. Could
you be less dismissive of the hard work others put into improving the
Python world?
-- Devin
--
https://mail.python.org/mailman/listinfo/python-list
orth it, most of the time. If you want
to migrate to Python 3, help that library forward, rather than trying
to make some bespoke replacement you think will be a killer app.
-- Devin
--
https://mail.python.org/mailman/listinfo/python-list
etail.
> And if you don't like that argument (although it is a perfectly sound and
> correct argument), think of the module name space:
>
>
> ret = spam
> spam = 23
>
> will net you a simple NameError, because spam has not yet been created.
Because module level variables work differently from local variables.
-- Devin
--
https://mail.python.org/mailman/listinfo/python-list
characters is annoying. I just use
words. The only downside to using words is, how do you specify capital
versus lowercase letters? "Gamma = ..." violates the style guide! :(
-- Devin
--
https://mail.python.org/mailman/listinfo/python-list
eason was that warnings
are annoying -- so they broke everything instead of giving warnings. [2]
[1] http://legacy.python.org/dev/peps/pep-0394/
[2] https://mail.python.org/pipermail/python-dev/2010-November/105299.html
-- Devin
--
https://mail.python.org/mailman/listinfo/python-list
On Sun, Apr 6, 2014 at 1:25 AM, Chris Angelico wrote:
> On Sun, Apr 6, 2014 at 5:55 PM, Devin Jeanpierre
> wrote:
>> Agreed. Putting mutable objects inside tuples is common and totally OK.
>
> There are many programming habits that can cause problems, even though
> they w
ity that way, but in many contexts
you'll find that definition not very useful.
c is such that you could have another variable d, where the following
interpreter session fragment is easily possible:
>>> c == d
True
>>> foo(c)
>>> c == d
False
-- Devin
>>
to add better
support for enumerations while ignoring the broader use case.
If a switch statement gets added to Python and I still need to examine
ASTs by a long chain of if-elif and isinstance and so on I will cry.
-- Devin
On Wed, Apr 2, 2014 at 7:53 AM, Lucas Malor <3kywjyd...@snkmail.com> wrote:
am
trying. Is there a good website that contains maybe a more correct version
of the SPEC file for CentOS 6.x? Any help would be greatly appreciated.
Devin Acosta
--
https://mail.python.org/mailman/listinfo/python-list
tence or nonexistence is apparently meaningful; so your code does
something different than the original problem statement.
Also, if that weren't the case, I'd really replace that try-except
with getattr(sys, 'executable', __file__)
-- Devin
--
https://mail.python.org/mailman/listinfo/python-list
d learn Haskell.
Otherwise you will likely be confused when you overhear functional
programmers talking, whether it's about Hindley-Milner or sum types or
eta conversion.
-- Devin
--
https://mail.python.org/mailman/listinfo/python-list
1 - 100 of 373 matches
Mail list logo
