On Monday 22 August 2016 16:03, Stefan Behnel wrote:
> Steven D'Aprano schrieb am 22.08.2016 um 07:35:
>> if sys.version < '3':
>> import mymodule2 as mymodule
>> else:
>> import mymodule3 as mymodule
>
> This condition is going to fail when Python 30.0 comes out.
That will be sometime
On Mon, Aug 22, 2016 at 3:35 PM, Steven D'Aprano
wrote:
> Could somebody (the OP?) please explain what is the purpose of this proposal,
> what it does, how it works, and when would people use it?
My theory: A directive is actually parsed by the compiler, not
executed at run-time. So you could hav
Stefan Behnel schrieb am 22.08.2016 um 08:03:
> Steven D'Aprano schrieb am 22.08.2016 um 07:35:
>> if sys.version < '3':
>> import mymodule2 as mymodule
>> else:
>> import mymodule3 as mymodule
>
> This condition is going to fail when Python 30.0 comes out.
Oh, sorry - make that Python 10
On Mon, Aug 22, 2016, at 02:03, Stefan Behnel wrote:
> Steven D'Aprano schrieb am 22.08.2016 um 07:35:
> > if sys.version < '3':
> > import mymodule2 as mymodule
> > else:
> > import mymodule3 as mymodule
>
> This condition is going to fail when Python 30.0 comes out.
Er, won't it rather
On Mon, Aug 22, 2016, at 01:35, Steven D'Aprano wrote:
> Could somebody (the OP?) please explain what is the purpose of this
> proposal, what it does, how it works, and when would people use it?
I think what he wants is a way for a module which uses features
(syntactic or otherwise, but I suppose
Steven D'Aprano schrieb am 22.08.2016 um 07:35:
> if sys.version < '3':
> import mymodule2 as mymodule
> else:
> import mymodule3 as mymodule
This condition is going to fail when Python 30.0 comes out.
Stefan
--
https://mail.python.org/mailman/listinfo/python-list
On Monday 22 August 2016 14:33, Chris Angelico wrote:
> On Mon, Aug 22, 2016 at 1:37 PM, rocky wrote:
>> Sorry should have been:
>>
>> assert sys.version_info >= (3,0)
>
> The next question is: How common is code like this? I don't put
> version checks in any of my modules. Adding magic comment
On Mon, Aug 22, 2016 at 1:37 PM, rocky wrote:
> Sorry should have been:
>
> assert sys.version_info >= (3,0)
The next question is: How common is code like this? I don't put
version checks in any of my modules. Adding magic comments would be of
value only if this sort of thing is common enough to
On Mon, Aug 22, 2016 at 1:26 AM, Chris Angelico wrote:
> They're specifically documented as not touching any file system, which
> means that they are cross-platform and cannot be guaranteed to be
> perfect. If you know you're running on Windows, use WindowsPath
> instead (trying to do so on a non-
Sorry should have been:
assert sys.version_info >= (3,0)
On Sunday, August 21, 2016 at 11:30:11 PM UTC-4, Ben Finney wrote:
> rocky writes:
>
> > The assertion should have been
> >
> > assert sys.version >= (3, 0)
>
> Perhaps you haven't tried any of these examples before presenting th
On Monday, August 22, 2016 at 12:24:30 AM UTC+5:30, Tim Chase wrote:
> On 2016-08-21 04:53, Rustom Mody wrote:
> > 2. Basic computing theory shows that re-s and dfas are equivalent.
> > Which would one prefer to write/debug? [Thats not a rhetorical
> > question]
>
> I'm curious where REs and DFAs
rocky writes:
> The assertion should have been
>
> assert sys.version >= (3, 0)
Perhaps you haven't tried any of these examples before presenting them?
>>> import sys
>>> assert sys.version >= (3, 0)
Traceback (most recent call last):
File "", line 1, in
TypeError: uno
The assertion should have been
assert sys.version >= (3, 0)
If we want to indicate the Python program supports language versions 3.0 and
greater.
On Sunday, August 21, 2016 at 3:59:48 PM UTC-4, Vincent Vande Vyvre wrote:
> Le 21/08/2016 à 20:28, rocky a écrit :
> > The problem:
> >
> > 1. th
On 8/21/2016 9:08 PM, eryk sun wrote:
On Mon, Aug 22, 2016 at 12:44 AM, Chris Angelico wrote:
"Trying to be" cross-platform? The point of these path modules is to
*be* cross-platform. I can't call Windows APIs on my Linux box (short
of messing around with VMs or Wine or something, which are
dep
On Monday, August 22, 2016 at 3:48:49 AM UTC+5:30, Marko Rauhamaa wrote:
> Lawrence D’Oliveiro :
>
> > On Monday, August 22, 2016 at 2:20:39 AM UTC+12, Marko Rauhamaa wrote:
> >> ... can heartily recommend SCons.
> >
> > It’s Python 2 only, not Python 3.
>
> And? SCons is very good, definitely be
On Mon, Aug 22, 2016 at 11:08 AM, eryk sun wrote:
> On Mon, Aug 22, 2016 at 12:44 AM, Chris Angelico wrote:
>> "Trying to be" cross-platform? The point of these path modules is to
>> *be* cross-platform. I can't call Windows APIs on my Linux box (short
>> of messing around with VMs or Wine or som
On Mon, 22 Aug 2016 10:38 am, eryk sun wrote:
> To me it's scary that this check misses cases because it's trying to
> be cross-platform instead of simply relying on GetFullPathName to do
> the work. For example, it misses at least the following cases:
Instead of shaking in your boots over a simp
On Mon, Aug 22, 2016 at 12:44 AM, Chris Angelico wrote:
> "Trying to be" cross-platform? The point of these path modules is to
> *be* cross-platform. I can't call Windows APIs on my Linux box (short
> of messing around with VMs or Wine or something, which are
> dependencies that Python doesn't nee
On Mon, Aug 22, 2016 at 10:38 AM, eryk sun wrote:
> To me it's scary that this check misses cases because it's trying to
> be cross-platform instead of simply relying on GetFullPathName to do
> the work.
"Trying to be" cross-platform? The point of these path modules is to
*be* cross-platform. I c
On Sun, Aug 21, 2016 at 8:03 PM, Michael Torrie wrote:
> On 08/19/2016 05:42 PM, Lawrence D’Oliveiro wrote:
>> Python 3.5.2+ (default, Aug 5 2016, 08:07:14)
>> [GCC 6.1.1 20160724] on linux
>> Type "help", "copyright", "credits" or "license" for more information.
>> >>> from pathl
On Sunday, August 21, 2016 at 11:18:49 PM UTC+1, Marko Rauhamaa wrote:
> Lawrence D’Oliveiro :
>
> > On Monday, August 22, 2016 at 2:20:39 AM UTC+12, Marko Rauhamaa wrote:
> >> ... can heartily recommend SCons.
> >
> > It’s Python 2 only, not Python 3.
>
> And? SCons is very good, definitely beat
Lawrence D’Oliveiro :
> On Monday, August 22, 2016 at 2:20:39 AM UTC+12, Marko Rauhamaa wrote:
>> ... can heartily recommend SCons.
>
> It’s Python 2 only, not Python 3.
And? SCons is very good, definitely beats make. It also illustrates the
use of a real programming language for special applicat
On Sunday, August 21, 2016 at 7:19:49 PM UTC+12, Michael Selik wrote:
>
> On Sun, Aug 21, 2016, 3:06 AM Lawrence D’Oliveiro wrote:
>
>> On Sunday, August 21, 2016 at 6:49:19 PM UTC+12, Michael Selik wrote:
>>
>>> Indeed it is, not sure why.
>>
>> Moral: It helps to understand the code you’re criti
Lawrence D’Oliveiro :
> On Monday, August 22, 2016 at 2:20:39 AM UTC+12, Marko Rauhamaa wrote:
>> Lisp's "data is code and code is data" is a good principle. I have
>> successfully used it with Python as well.
>
> You think self-modifying code is a good idea?
Why change topics?
Marko
--
https:
On Monday, August 22, 2016 at 2:20:39 AM UTC+12, Marko Rauhamaa wrote:
> ... can heartily recommend SCons.
It’s Python 2 only, not Python 3.
--
https://mail.python.org/mailman/listinfo/python-list
On Monday, August 22, 2016 at 2:20:39 AM UTC+12, Marko Rauhamaa wrote:
> Lisp's "data is code and code is data" is a good principle. I have
> successfully used it with Python as well.
You think self-modifying code is a good idea?
--
https://mail.python.org/mailman/listinfo/python-list
On Monday, August 22, 2016 at 12:21:36 AM UTC+12, Chris Angelico wrote:
> The issues with makefiles are mainly to do with metaprogramming (plus
> a few specific issues with the format itself, which don't apply to the
> more general concept). There's a ton of magic to cope with makefiles
> that try
On Sunday, August 21, 2016 at 11:53:52 PM UTC+12, Rustom Mody wrote:
> However seeing that list together like that I cant help wondering:
> Is the philosophy of data-driven-ness itself somehow ill-conceived?
I don’t understand why. They are all examples of the success of the technique,
and I can
On 2016-08-19, Larry Martell wrote:
> fd.write(request.POST[key])
You could try:
request.encoding = "iso-8859-1"
fd.write(request.POST[key].encode("iso-8859-1"))
It's hacky and nasty and there might be a better "official" method
but I think it should work.
--
https://mail.python.org/mailma
Tim Chase writes:
> On 2016-08-21 04:53, Rustom Mody wrote:
>> 2. Basic computing theory shows that re-s and dfas are equivalent.
>> Which would one prefer to write/debug? [Thats not a rhetorical
>> question]
>
> I'm curious where REs and DFAs are shown to be equivalent (serious,
> not trying to
On 08/19/2016 05:42 PM, Lawrence D’Oliveiro wrote:
> Python 3.5.2+ (default, Aug 5 2016, 08:07:14)
> [GCC 6.1.1 20160724] on linux
> Type "help", "copyright", "credits" or "license" for more information.
> >>> from pathlib import PureWindowsPath
> >>> PureWindowsPath("prn").is
Le 21/08/2016 à 20:28, rocky a écrit :
The problem:
1. there are various code inspection tools that parse Python programs looking
for style issues or whatnot. The deeper ones have to do a full parse of the
python program. It would be helpful if there were a uniform way to indicate the
Python
Rustom Mody :
> On Sunday, August 21, 2016 at 7:50:39 PM UTC+5:30, Marko Rauhamaa wrote:
>> Don't know jam, but can heartily recommend SCons.
>
> Likely true at some point
> Probably not now: http://stackoverflow.com/questions/2847730/c-build-systems
> [ tup seems to be the rage; scons seems to ha
On 2016-08-21 04:53, Rustom Mody wrote:
> 2. Basic computing theory shows that re-s and dfas are equivalent.
> Which would one prefer to write/debug? [Thats not a rhetorical
> question]
I'm curious where REs and DFAs are shown to be equivalent (serious,
not trying to be snarky). I can see with no
The problem:
1. there are various code inspection tools that parse Python programs looking
for style issues or whatnot. The deeper ones have to do a full parse of the
python program. It would be helpful if there were a uniform way to indicate the
Python language level used in Python source code
On Sunday, August 21, 2016 at 7:50:39 PM UTC+5:30, Marko Rauhamaa wrote:
> Rustom Mody :
> >> > All I can say is that I've encountered numerous bad cases of rule
> >> > systems, eg:
> >> >
> >> > - iptables
> >> >
> >> > - selinux policies
> >> >
> >> > - systemd unit files
> >> >
> >> > -
Rustom Mody :
>> > All I can say is that I've encountered numerous bad cases of rule
>> > systems, eg:
>> >
>> > - iptables
>> >
>> > - selinux policies
>> >
>> > - systemd unit files
>> >
>> > - asterisk
>> >
>> > - sendmail
> [...]
> Some other examples:
> 1.
> Aren’t makefiles data-dri
On Sunday, August 21, 2016 at 5:51:36 PM UTC+5:30, Chris Angelico wrote:
> On Sun, Aug 21, 2016 at 9:53 PM, Rustom Mody wrote:
> > Some other examples:
> > 1.
> > Aren’t makefiles data-driven? And if so should not much more declarative
> > attempts like jam have been correspondingly more successfu
On Sun, Aug 21, 2016 at 9:53 PM, Rustom Mody wrote:
> Some other examples:
> 1.
> Aren’t makefiles data-driven? And if so should not much more declarative
> attempts like jam have been correspondingly more successful?
> https://www.perforce.com/resources/documentation/jam
>
> [Personally Ive alway
On Sunday, August 21, 2016 at 5:13:28 AM UTC+5:30, Lawrence D’Oliveiro wrote:
> On Saturday, August 20, 2016 at 8:08:24 PM UTC+12, Marko Rauhamaa wrote:
> >
> > Lawrence D’Oliveiro:
> >
> >> On Thursday, August 18, 2016 at 4:47:28 PM UTC+12, Marko Rauhamaa wrote:
> >>>
> >>> ... as a rule, I disli
On Sun, Aug 21, 2016, 3:06 AM Lawrence D’Oliveiro
wrote:
> On Sunday, August 21, 2016 at 6:49:19 PM UTC+12, Michael Selik wrote:
>
> > Indeed it is, not sure why.
>
> Moral: It helps to understand the code you’re criticizing, before you
> start criticizing, not after.
>
A true statement, but not
On Sunday, August 21, 2016 at 6:49:19 PM UTC+12, Michael Selik wrote:
> Indeed it is, not sure why.
Moral: It helps to understand the code you’re criticizing, before you start
criticizing, not after.
--
https://mail.python.org/mailman/listinfo/python-list
42 matches
Mail list logo
